On-premises
The data stays. So does the software.
Four containers and one data directory, on your own server.
Web service
The API and the single-page application from one image. Put your own reverse proxy and TLS in front of it.
Background worker
Document reading, transcription and every other long job runs here — never inside a web request.
PostgreSQL 16
The system of record. Migrations run at startup and are tested against both supported engines.
The stack
What actually gets installed
Web service
The API and the single-page application from one image. Put your own reverse proxy and TLS in front of it.
Background worker
Document reading, transcription and every other long job runs here — never inside a web request.
PostgreSQL 16
The system of record. Migrations run at startup and are tested against both supported engines.
Redis
The job queue. Durable, with the worker recovering in-flight jobs after a restart.
One data directory
Uploads, outputs, the database and the queue all live under a single path. Back it up the way you back up everything else.
A configurable model endpoint
Point it at a hosted vision-language model, your own gateway, or a model on your own GPU. It is a URL and a key.
Installation
What the first day looks like
Provision
A Linux host with a container runtime. Modest resources are enough to start; sizing depends on document volume and whether a model runs locally.
Configure
One environment file: database password, model endpoint and key, base URL, cookie settings. Non-secret tuning stays in configuration files.
Start
Bring up the stack. Migrations apply, the bootstrap administrator is created from your environment file, and the app answers.
Hand over
You create the first workspace, author the catalogue and invite your people. We stay on the call until a real document has been read end to end.
Operating it
What your operations team should know
- Every persistent byte is under one directory — no state is written anywhere else at runtime
- Upgrades are a pull and a rebuild; database migrations are applied automatically at startup
- Backups are a database dump plus that directory; a nightly script is provided
- Request identifiers are attached to every response and log line for tracing
- Structured JSON logging can be switched on with one variable
- Error reporting to your own error-tracking service is supported and off by default
- The queue is durable: a worker restart resumes rather than dropping jobs
- TLS, reverse proxying and network policy stay yours — the app makes no assumptions
Air-gapped and restricted networks
The only outbound dependency is the model
Reading documents needs a vision-language model. That is the single external dependency, and it is a configured URL — so a model served inside your network makes the deployment fully self-contained.
Everything else — the database, the queue, storage, search, the interface — runs locally with no call home, no licence server and no telemetry you did not switch on.
- No licence check phoning home
- Error reporting off unless you configure it
- Fonts and interface assets bundled, not fetched from a CDN
- Works behind a corporate proxy
About on-premises
What hardware do we need?
For a team-sized deployment, a small Linux VM is enough — the reference production stack runs comfortably on modest resources because heavy reading happens at the model endpoint. If you host the model too, size for the model, not for us.Can we run it on Windows?
Through a container runtime, yes. We test on Linux and that is what we support.Who applies security updates?
You do, by pulling a new tagged release when we publish one. We tell you what changed, and migrations are tested on both engines before release.
Talk to us about your deployment
Bring your security questionnaire, your network constraints and your timetable. We would rather answer the hard questions before a pilot than after one.