Production differs from trial mode in exactly three ways: real identity configuration, an external PostgreSQL, and running the worker as its own process. Add Milvus and object storage if you need them.
| Item | Trial mode | Production |
|---|---|---|
| Identity | Injected administrative identity | Real role tokens, access control enabled |
| Database | PostgreSQL inside a container | External PostgreSQL, easier to back up and scale |
| Worker | Same process as the API | Separate process, scaled independently |
| Model | Simulated model | Real model services |
| Vector search | Not required | Milvus, if you need retrieval |
| Object storage | Not required | S3 or MinIO, if you need it |
| HTTPS | Self-signed certificate included | Your own certificate |
Do not run trial mode in production. It injects an administrative identity when a request carries no credentials — a deliberate convenience for local evaluation, and unsuitable for anything serving real traffic or holding real data.
Provision a PostgreSQL instance and create the database and role NexusDesk will use. The schema is managed by migrations and runs on first start. Version requirements and initialisation details are in the deployment guide in the repository.
The template lists every required value and placeholder. At minimum you need the database connection and role tokens.
# first deployment only
cp deploy/production/.env.example deploy/production/.env
# then edit deploy/production/.env and replace the placeholders# first deployment only
Copy-Item deploy/production/.env.example deploy/production/.env
# then edit deploy/production/.env and replace the placeholders
Milvus: add it when you need vector retrieval. If you do not need knowledge
retrieval yet, skip it.
Object storage (S3 / MinIO): stores the original knowledge-base files. Also optional.
The repository includes Compose files for the middleware, usable as-is or as a reference.
sh nexusdesk deploy.\nexusdesk.ps1 deployUseful if your target environment has no internet access, forbids certain middleware, or has to pass a security review.
Postgres carries data storage, the task queue and the cross-process message channel. In a security review, one fewer middleware usually means one fewer component inventory and one fewer failure point.
The application server needs no GPU. Models are called as external services and business tools are integrated over API.
Knowledge bases and business data live in your own database and object storage. Conversation history, run events and audit records all stay in your database.
Any OpenAI-compatible service works. Connections, profiles and versions are managed in the console, so switching models requires no code change.
Images can be exported and imported offline. Nothing in the deployment flow needs internet access from the target environment.
Operator actions, run events, model call metering and tool call records are all queryable.
The schema is managed by Alembic migrations, applied in order and not rolled back. Back up first, and read the migration notes in the target release.
Three things need backing up: the PostgreSQL database, the knowledge-base files in object storage, and the production configuration. Vector indexes can be rebuilt.
On the current state: backup and recovery, and capacity testing, are still being completed. We have not published validated capacity or performance figures for large production deployments. If your scenario has firm availability requirements, talk to us before going live, or validate it first in a small internal environment.
Intranet adaptation, middleware selection, domestic-stack validation, deployment and upgrades — if you would like someone alongside you, get in touch. Or run it yourself in a test environment first and decide afterwards.