Install requirements
One virtual machine. One database. A browser.
EMMa runs on one server or virtual machine inside the factory network. Users only need a web browser — nothing is installed on office computers, tablets or shop-floor terminals. The base application can run without internet. AI is optional. The factory can use SQL Server or PostgreSQL.
/ 01 — The short answers
Where does it run?
On one server or virtual machine inside the factory network. Hosting it in the cloud is possible, but running it inside the plant is what we recommend.
Which operating system?
Linux or Windows Server. The plant chooses.
Which database?
Microsoft SQL Server or PostgreSQL. The plant chooses.
What does a user need?
A modern web browser. Nothing else.
Minimum application VM
4 CPU cores · 8 GB RAM · 100 GB disk
Recommended application VM
8 CPU cores · 16 GB RAM · 250 GB SSD
Does the base application need internet?
No. It can run fully inside the plant network. Internet is required only for an optional cloud AI service.
Does it need AI?
No. AI is optional, and every operational feature works without it.
The base application is small enough to run on server capacity most plants already have. The only significant extra hardware decision is the optional local AI, covered further down.
/ 02 — Deployment shape
Three machines at most, inside your network.
Required
Application VM
8–16 GB RAM
One virtual machine running EMMa Operations. Users reach it over HTTPS on an internal DNS name.
Required
Database
SQL Server or PostgreSQL
A dedicated instance, or a database on the plant’s existing infrastructure. It never needs to be exposed to user devices or the internet.
Optional
AI host
GPU machine
Only if the plant runs the assistant locally. Never put the model on the application VM — inference and application workloads compete for CPU, RAM and I/O.
The database may share the application VM for a pilot or small installation. In that arrangement 16 GB RAM becomes the minimum, not the recommendation.
/ 03 — For plant IT: the application server
Resource
Minimum
Recommended
Notes
CPU
4 cores
8 cores
Background KPI calculations, overdue checks and shift-related jobs run continuously.
RAM
8 GB
16 GB
8 GB is the base requirement; 16 GB gives headroom for reporting peaks and shift-change load.
Disk
100 GB
250 GB SSD
Application, logs, generated documents and local storage. SSD strongly preferred.
Operating system
Ubuntu LTS, RHEL/Rocky, or Windows Server 2019+
—
Linux and Windows are both supported deployment platforms.
Network
1 Gbit, static address
—
Inside the plant network, with a stable DNS name.
Certificate
HTTPS for the chosen hostname
—
A certificate from the plant’s internal certificate authority is acceptable.
Time
Synchronised system time
—
Use the plant’s normal NTP or domain time source.
Growth planning
The database grows mainly with events that occur every shift: production declarations, downtime, scrap, quality checks, material movements, kanban calls and KPI checkpoints.
Sizing depends on how much happens each shift, so the figures below are an example rather than a specification. For a plant of roughly 200 employees, two production areas and three shifts, plan initially for 20–40 GB of database growth per year, then review after six months against real data.
Documents and attachments are stored separately from transactional data. They must be in the backup plan too — restoring only the relational database is not sufficient if the evidence files are lost.
Database platform
Both are first-class supported providers and the application exposes the same business functionality on either. The plant chooses at installation.
SQL Server
2019 or later. Standard or Enterprise for production; Express only for a pilot within its edition limits.
PostgreSQL
16 or later recommended for new installations. Any supported standard distribution.
Restore testing
Mandatory. A backup is not operationally complete until a restore has been tested.
/ 04 — User devices and technical platform
What a user needs
Office computer
Any current browser — Edge, Chrome, Firefox or Safari. No plug-in, installed client or Java runtime.
Shop-floor terminal
Wall-mounted or workstation touch screen with a current browser. Production screens use large targets and high contrast.
Handheld / tablet
Any modern Android or iOS device with a current browser.
Screen size
Responsive from handheld devices to widescreen displays.
Local installation
None. Nothing is deployed to a normal user device.
On supported shop-floor screens, when live data is unavailable the terminal shows the last known good data with a generation timestamp, read-only, rather than an indefinite loading state. A spinner on a shop-floor terminal is a stopped line.
Technology stack
Runtime
.NET 10
Web framework
ASP.NET Core, hosted as a single web application
User interface
Blazor, with server and browser rendering modes. Authorization and security-sensitive validation are enforced on the server.
Data access
Entity Framework Core 10
Database
Microsoft SQL Server and PostgreSQL, both first-class
Platform
CodingWithEase 0.25.1 — security, permissions, localization, notifications, documents, health checks and the AI subsystem
Authentication
ASP.NET Core Identity, with roles and fine-grained permission keys
Localization
Database-backed and administrable at runtime; users select their own language
Documents
Server-side PDF and Excel generation, attributed to the user who produced them
Monitoring
Standard /health and /health/ready endpoints for monitoring tools or orchestrators
In short: a standard .NET web application. Any IT department, hosting provider or partner that works with .NET can run it. It installs as a Windows service, a Linux service, or a container.
/ 05 — AI, Level 1
The assistant is optional. EMMa runs fully without it.
EMMa works completely without AI. If the plant wants it, a user can ask the built-in assistant to find information, explain a field, open a function or prepare a record in normal language. Three things matter more than which model is used.
Bounded by the user’s own permissions
A user who cannot read a protected record manually cannot use the assistant to bypass that permission. Authorization is enforced by the application, not by asking the language model to behave.
It stages controlled actions
When the assistant prepares a change requiring approval, the user confirms it first. The resulting operation passes through the same validation, permissions and audit as the manual equivalent.
It is entirely optional
AI can remain disabled. A plant can operate EMMa Operations without it and retain the full operational functionality described across this site.
Sizing a local model host
For initial planning, assume around 20% of office employees using the assistant concurrently. Shop-floor operators are not normally included, because their workflows are structured declarations and checks rather than extended conversations.
Office staff
Concurrent
Model class
GPU memory
Hardware class
Up to 25
~5
8–14 billion parameters
24 GB
One workstation-class GPU
Up to 50
~10
24–32 billion parameters
48 GB
One professional GPU
Up to 100
~20
24–32 billion parameters
80 GB
One data-centre-class GPU, or 2 × 48 GB
Up to 200
~40
32–70 billion parameters
2 × 80 GB
Multi-GPU server configuration
As an example, for a plant of roughly 200 employees with 50–60 office users, budget initially for one professional GPU with around 48 GB of memory. That is a planning baseline for a pilot, not a contractual performance specification — measure real EMMa workloads before buying production hardware.
Why local is recommended
The AI model runs on a separate computer inside the factory. Questions, the factory information sent with them, and the answers can all stay inside the factory network. No cloud provider, no usage charges, and no dependence on an internet connection.
Cloud Level 1 is supported
The factory does not need to buy an AI computer, but there are usage charges, it depends on the internet connection, and the questions plus the factory information sent with them go to the chosen cloud provider. What EMMa can do is identical — this is a purchasing and policy decision.
The second, smaller model
Searching by meaning uses a second, much smaller model. It can normally share the same AI computer and may run without a GPU. It does not need its own hardware.
/ 06 — AI, Level 2
Voice can join the conversation. It never joins the application.
Voice is optional. It lets a supervisor walking the floor, or a technician whose hands are busy, speak to EMMa and hear a spoken answer. Spoken audio and the conversation are sent to the chosen cloud voice provider.
What the cloud voice service can and cannot access
Person
Speaks and listens.
Realtime voice (cloud)
Converts speech to words and speaks the answer back. A conversation layer, nothing more.
In-app assistant
Permission-checked. Every EMMa capability stays behind it.
EMMa Operations
Authorization lives here, and only here.
The voice service is never trusted to enforce EMMa permissions, because it never receives the ability to do anything in EMMa in the first place. It only turns speech into words and speaks the answer back.
What leaves the plant, by level
Level 1 · local
Level 1 · cloud
Level 2 · cloud voice
Direct database access
No external access
No direct provider access
No direct provider access
Business tools
Local assistant only, permission-controlled
Through the assistant architecture and permission controls
None for the voice provider
Prompts and conversation
Stay inside plant infrastructure
Sent to the Level 1 cloud provider
Sent to the voice provider
Spoken audio
Not applicable
Not applicable
Sent to the voice provider
Production and employee information
Stays on-premise unless another cloud feature is deliberately enabled
Information included in the model request is sent to the provider
Anything spoken or returned in the conversation is transmitted
Voice remains a cloud conversation service. Audio, transcribed words and any business information spoken in the conversation may leave the plant — so it requires explicit approval from IT security, legal, works council and data protection as applicable. Voice can remain disabled without affecting anything else.
/ 07 — Checklist
Fourteen steps, four of them optional.
01
Provision the application virtual machine — 8 GB minimum, 16 GB recommended, 100 GB disk
Plant IT
02
Choose and provision SQL Server or PostgreSQL to the supported production baseline
Plant IT
03
Create the internal DNS name and issue the HTTPS certificate
Plant IT
04
Configure the required firewall and network paths
Plant IT
05
Store the database connection string and other secrets using the approved secret-management method
Plant IT
06
Install and start EMMa Operations under a dedicated service identity, with the correct application directory
Plant IT
07
Confirm /health and /health/ready report the expected state
Plant IT
08
Configure database and document backup — and test a restore
Plant IT
09
Create the administrator account and provision the first users
Plant IT + HR
10
Configure the plant model, calendar, shift systems and reference catalogues
Implementation
11
Connect the built-in standard roles to the plant’s real departments and job titles
Implementation
12
Optional — provision the local AI host and register the chat and embedding connections
Plant IT
13
Optional — approve and register a cloud Level 1 AI provider
IT + Security / DPO
14
Optional — approve and register the cloud realtime voice provider
IT + Security / DPO
The checklist below is for the IT team that installs EMMa. The hands-on technical effort for the base infrastructure is normally modest for an IT department used to deploying web applications. Corporate lead time can be much longer, because VM provisioning, firewall approvals, DNS, certificates, service accounts and change management follow the plant’s own processes.
/ 08 — Summary for IT and management
What EMMa Operations does not require.
No client installation
Not on office PCs, shop-floor terminals or handhelds.
No internet for the base application
The base deployment runs inside the plant network.
No cloud AI dependency
Local Level 1 AI is supported; cloud chat and voice are optional.
No cloud subscription
A provider account is needed only for cloud services the plant chooses to enable.
No per-device licence
User licensing is not tied to the number of browsers or terminals.
No proprietary database
SQL Server or PostgreSQL, according to the plant’s choice.
No specialist hardware
Dedicated GPU hardware is needed only for local AI at production scale.
No AI requirement
Operational functionality remains available with AI disabled.
No internet-exposed database
Users reach EMMa over HTTPS; the database stays an internal service.
The core application is a conventional web application that can run entirely inside the factory network.
Ask about your infrastructure