Hardened deployments

The all-in-one appliance is the right start. When your security posture demands smaller exposure surfaces, the server is already split along the right seams.

The three surface classes

Every route the server exposes belongs to exactly one class, and each class has its own listener behind the web server, so firewalling follows a fixed table rather than guesswork:

Your install kit's NEXT-STEPS.txt prints this table with your actual hostnames. The principle is that nothing but activation and payments needs internet exposure; the console is an internal tool.

The separated topology

Choosing separated at setup emits a hardened compose file that runs one container per role (public, payments, console), each serving only its class's routes (a role answers nothing for the other classes, fail-closed), against a database container or your external database. Scheduled jobs run on the console role only. This is the shape for DMZ splits: the public role in the exposed segment, the console role inside.

External database

Supplying an external MongoDB URI (at setup, or later in config.json) automatically parks the embedded engine and runs the appliance app-only. Use it when the database must live under existing operational management: replica sets, existing backup regimes, database-team ownership. Note that sws-backup still matters in this shape: your database team backs up the data, but the PKI keys and config are on the appliance side and remain your archive's job.

Sizing note

The appliance reserves about 4 GB in the generated launch command; the separated roles are individually smaller. Licensing traffic is bursty but light: activation is one round-trip per device per lease or renewal, and validation happens locally on the devices. Scale conservatism should go into availability (restart policy, health checks, backups), not fleet size.