Self-hosting & deploy#

Tollan can run on your own infrastructure instead of the managed service. This page covers the deployment shapes and their trade-offs at a high level. The concrete setup — configuration templates, service definitions, and secret handling — ships with the deployment package and is not reproduced here.

Two deployment shapes#

All-in-one — the control plane and the relay run together on a single host. Simplest to stand up; good for evaluation, development, and small single-operator setups.

Split — the control plane and the relay run on separate hosts. This is the recommended production shape, because it keeps their responsibilities (and their trust boundaries) apart:

• The control plane holds the database, the console, and the certificate authority. It is the sensitive core.
• The relay only pumps traffic. It holds no database, no CA, and no operator UI — so a relay host, which is by nature the most exposed component, carries none of the crown jewels.

The two communicate over an authenticated, private channel that carries routing updates, metrics, and certificate-status checks. That channel is meant to stay on trusted infrastructure, not the public internet.

Why the split matters#

Separating the planes means the component with the largest public attack surface (the relay) is also the one with the least to steal. Even if a relay host were fully compromised:

• there is no customer database or CA key on it to exfiltrate;
• it still cannot reach internal LAN targets that operators haven't authorized (the target allowlist lives on the agents);
• and for passthrough routes it never held the keys to your traffic in the first place (zero-knowledge passthrough).

Independent upgrades#

Because the planes are decoupled, you can maintain them independently:

• Restart the control plane and existing tunnels keep carrying traffic — the relay re-syncs configuration when the control plane returns.
• Restart the relay and agents reconnect automatically on their backoff, while management stays available.

Neither operation requires a coordinated downtime window.

Configuration & secrets#

Deployment configuration (database, mail, billing, platform domains) and the platform's secrets are managed through the environment templates that ship with the runbooks. Treat every secret as sensitive:

• keep them out of version control and out of shared chat;
• rotate them if they may have been exposed;
• restrict who and what can read them.

The docs deliberately don't list secret names or generation commands — those belong with your operators, not on a public page.

Observability#

The relay exports operational metrics and reports periodic traffic summaries to the control plane, which surfaces them as device metrics and organization usage. Operator actions are recorded in the audit log. Wire your metrics into whatever monitoring you already run.

For the security properties behind all of this, see the Security model.