Operating

Start the same program again on shared storage. File locks are all that coordinates the copies: no orchestrator, no consensus, no node registry.

What the shared storage must provide

• The flow endpoints, the WSDL, the health check, the queue workers, the schedule runner and the management UI all run in the same process. The UI is not a second binary and has no port of its own.
• The gRPC door listens on a separate port, in the same process, and only when asked for at start-up.
• One runtime owner per process, and a platform at capacity refuses loudly, leaving a trace in the journal.
• An installation comes up knowing only the operations manual: the first flow runs with the gate closed and configuration from the environment, inside the shipped image.

TLS terminates at your reverse proxy, in front of the platform.

Back it up as a unit. A database taken without its queues describes an installation that never existed.

The audit chain in nexus-audit.db can be verified at any time — nexus audit --tenant <t> --verify, or the button on the audit page. A break verdict names the sequence number of the entry that was touched. A chain nobody asked about is not verified on its own, and a listing says nothing about integrity. The command takes one tenant, so an installation with several is verified one at a time.

A flow declares the environment configuration it needs, and a declared key the installation does not supply stops the boot, naming the key. At start-up, not at the first message.

The same question can be asked without starting anything: nexus config check gives the same verdict as start-up and exits non-zero when a key is missing. One verdict, two moments — not a second implementation that would go stale in exactly the copy the operator runs.

And a boot scan cannot stay silent: a registry that cannot be listed stops the boot rather than letting it look checked.

• Environment configuration is captured once, at start-up. Changing it requires a restart — if the values were re-read along the way, the gate at start-up would have checked values other than the ones the platform is running on.
• Adding, changing or removing a schedule requires a restart. Changing the steps of an already scheduled flow does not: the next tick picks up the new version.
• The gRPC routing table is built at start-up. A flow published after that is not routed until a restart, and a withdrawn one answers like a flow that does not exist.
• Rate ceilings live in process memory. A restart empties them, and two engines keep two counters: a key configured at r requests per second can spend up to N × r across N engines. Size the ceiling for the engine, not for the installation.

• Order is kept on first delivery only. A retry takes its place in the order its turn came up in, not the order the message arrived in.
• The worker ceiling is not a rate: it is the number of distinct queues that can drain on this server at all. Count your queues, not your traffic.
• After a restart, a queue’s unprocessed messages sit on disk until something is submitted to that flow again. The worker starts on the first submission, not on process start.
• A drained queue reclaims its bytes while the worker keeps consuming, and a dead letter discarded is really gone from disk, at the next drain.

Declare deduplication in the flow, and a second delivery of the same key does not run it again.

A flow can carry a six-field schedule, and a tick leaves the same pair in the journal — a receipt plus a verdict — as a request through the front door, on the cron channel. A schedule that failed is not invisible.

And in the same breath, because an operator has to learn this beforehand rather than at three in the morning: the scheduling lock makes a single engine carry the schedules, so nothing fires twice — but if the engine holding the lock stops, a surviving engine takes the seat within 10 seconds of a process dying, or the NFS lease plus 10 seconds of a host dying. Cron ticks that fall in the gap are missed, not replayed.

The journal has two sinks — rows in a database and files on disk. One retention window governs both, in a single pass, wired into the serving process.

That window does not reach beyond the journal: it does not touch the queues, the registry, the audit chain or flow state. Planning an installation’s disk means planning four things, not one.

• ObservabilityWhat stays written after a delivery, and for how long.