We install it. This page is not a manual, it is what the machine has to be and what the install actually does, so you can judge whether this is an engineered process or bespoke consulting.
The machine
| Enforced minimum | 2 GB memory, 10 GB disk. The installer refuses to run below this |
| Recommended | 4 GB memory, 20 GB disk, 2 cores |
| Operating system | Debian 12. The installer targets Debian and Ubuntu and exits on anything else |
| Observed after a fresh install | 9.6 GB on disk, around 600 MB memory at rest |
The recommendation is higher than the minimum for an honest reason: at 2 GB a fresh node fits but starts using swap before anyone has asked it anything.
What the install does
Staged, in a fixed order, unattended. Around eleven minutes on the machines we have measured, and longer on a slow link, since most of that time is spent pulling packages and images.
- Provision and preflight: check the machine, install system dependencies.
- Base stages: database cluster, reverse proxy, authentication, core services.
- Twelve companion services in a fixed order: registry, documents, memory, planner, panel, gateway, dispatcher, runner, communication and the rest.
- Validation: 160 checks. The install is not considered done until they pass.
Afterwards the owner gets a one-time link to set their own credentials, and configuration continues in the panel.
Network
No channel needs a port opened toward the machine. Mail is polled over IMAP and sent over SMTP. Telegram is long-polled. Slack runs over an outbound socket. Each of them dials out, so none of them is waiting to be dialled.
What that buys you is a choice, and the choice is yours rather than ours. A node can live entirely inside your network with nothing published, and mail, Telegram and Slack keep working. Publish 443 and you additionally get the panel reachable from outside and a chat widget you can put on your website. A stock install publishes 80, 443 and a WireGuard port; anything narrower than that is a firewall decision on your machine, on the day, like any other server you run.
The firewall denies incoming by default, and everything the node runs for itself sits behind it: the database, the gateway, the registry API, the panel backend, the memory and document services. None of them is something you publish.
What leaves the machine
The model call, and whatever the channels you turned on have to reach in order to send. In full: the model provider, your mail server, and any chat platform you connected. If you connect Google, the access is scoped when you connect it, and that scope is worth reading before you approve it.
Customer records, configuration, the message history and the audit log stay on the machine.
What the install does not do
- No update command. Moving to a newer version is a manual operation today.
- No migration runner. The schema is installed, not migrated.
- Not offline. The install pulls packages and images, and the search index fetches its model the first time it runs.
- No backup tool. There is a written manual procedure. The product does not ship one.
- No degraded mode. If the machine loses internet, outbound sending fails. Nothing is queued for later.
Who installs it
We do. Setup is part of the pilot, on your machine or one we provision for you, and it is a paid one-off. There is no subscription.
There is no step-by-step install guide on this site, and that is deliberate. A procedure goes stale the moment a step changes, and this one changes often, so publishing one here would mean publishing something wrong. What is on this page instead is what the machine has to be and what the install actually does, which is what you need in order to judge whether this is an engineered process or bespoke consulting.