Self-hosting

Server setup

In development

Keylane Server is the relay that carries sealed envelopes between devices. It is built to be run by anyone, not only by us. Installation documentation lands with the self-hosting release — this page describes what is coming and how far along it is.

Status

The server powers the public network today, and the admin console shown below is a working product. What is not ready is a packaged, documented, supportable release you can deploy yourself. We would rather ship that late than ship a security-critical service with incomplete hardening guidance.

What the server does

A Keylane relay accepts sealed envelopes from devices and holds them until the destination device collects them. It does not encrypt, decrypt, or interpret anything it carries — the whole design goal is to be a component that is not worth attacking. The security properties are documented in server security.

Running your own relay changes one thing: who operates the infrastructure your traffic passes through. It does not change the encryption, which is end-to-end between devices either way.

Why you might want your own

Regulatory or contractual requirements that data transit stays within infrastructure you control — common for law firms, healthcare, and public-sector work.
Air-gapped or restricted networks where reaching a public relay is not an option.
Organizational control over retention, rate limits, federation policy, and abuse handling.
You simply prefer not to trust us — which is a legitimate position, and the reason federation exists.

The admin console

Every Keylane server ships with a web console for operating it: health, queues, identity, federation policy, and abuse handling. It is built to the same constraint as the server itself — there is no view, export, or log path in it that yields plaintext.

Keylane server console transport overview, showing a health verdict panel, live throughput chart, and server totals — Transport overview — health, load, and queue pressure at a glance. All values shown are seeded demonstration data.

Keylane server console spool and queues screen, with payloads rendered as sealed lattice glyphs alongside byte counts — Spool & queues. Payloads render as sealed glyphs with byte counts — the operator sees that an envelope exists and how large it is, never what it contains.

Keylane server console federation screen showing routing policy, the well-known discovery descriptor, and peer queue health — Federation policy, the live discovery descriptor, and peer health. Open, whitelist, or blacklist routing modes.

Keylane server console abuse reports queue with categories and per-case note counts — Abuse reports. User-submitted reports are handled as unverified testimony — the server cannot independently read the conversation being reported.

Keylane server console connection screen listing several server environments, with the production instance flagged — One console, many servers. Environments are colour-coded and production is flagged, so destructive actions are hard to perform by accident.

What the console can and cannot do

An admin console for an encrypted messenger is a place where a zero-knowledge claim either holds or quietly collapses. Ours is constrained deliberately:

Operators can see envelope counts, sizes, ages, destination device identifiers, queue depth, delivery state, and server health.
Operators cannot see message content, sender identities, or conversation history. There is no plaintext view, no plaintext export, and no debug logging path that produces one.
Abuse reports arrive as material submitted voluntarily by a participant in the conversation. The server cannot verify them by reading the exchange itself, and the console presents them as testimony rather than as evidence pulled from the transport. This is covered in the acceptable use policy.

Federation

A self-hosted relay is not an island. Instances exchange sealed envelopes server to server, so your users reach the public network and other private instances without anyone needing to trust anyone else with readable data.

Each instance publishes a discovery descriptor at /.well-known/keylane-server, with /.well-known/keylane served identically as a legacy alias. The public network’s descriptor is live at keylane.app/.well-known/keylane-server:

{
  "server": {
    "name": "Keylane Transport",
    "public_url": "https://router.keylane.app",
    "federation_enabled": true
  },
  "endpoints": {
    "api_base": "https://router.keylane.app/api",
    "federation_base": "https://router.keylane.app/api/federation",
    "files_base": "https://router.keylane.app/api/files"
  }
}

Routing policy is per instance. Open mode federates with anyone, whitelist mode routes only to named domains, blacklist mode routes to everyone except named domains. Peers become known on first handshake; in whitelist mode unlisted peers are counted and rate-limited, and their envelopes refused.

Planned deployment targets

Planned Keylane server deployment targets and their status
Target	Intended for	Status
Container image	Standard self-hosting on your own infrastructure	In development
On-premises deployment	Organizations with data-residency requirements	In development
Managed private instance	Teams that want their own relay without operating it	Planned
Small-appliance build	Households and small groups on low-power hardware	Exploratory

Timelines and current progress are tracked on the roadmap. We publish target sequence rather than dates, because dates on infrastructure work are usually fiction.

What this page will contain at release

System requirements and sizing guidance
Installation and first-run configuration
TLS, reverse proxy, and network hardening
Database setup, backup, and the retention model
Push credential configuration for APNs and FCM
Federation policy configuration
Monitoring, upgrades, and operational runbooks

Get told when it ships

If you intend to run your own relay, tell us what for. Deployment scenarios from people who actually plan to use this shape what gets built and what gets documented first.