For organizations
Messaging infrastructure you actually own
Run the complete Etoki stack on your own hosts: the metadata privacy of the public network, under your policy, with an admin plane and an audit trail that cannot be quietly rewritten.
Infrastructure you own
Every component — onion routers, file relay, @username directory, push relay, camouflage gateway, bot relay — is one statically linked binary. Two VPSes are a complete, redundant organization deployment; there is no vendor to lock you in.
Role-scoped admin plane
A port-separated admin API with Viewer, Operator, Admin and Auditor roles tunes PoW difficulty, rate limits and retention at runtime — with constant-time token checks and every change audited.
Tamper-evident audit
A BLAKE3 hash-chained audit log, anchored with Ed25519 signatures at least every 64 entries and hourly, with an offline verifier. It records server events only — never message content, never queue IDs, nothing that could reconstruct a conversation.
The admin plane and audit layer ship as a tested component of the server codebase; the hard rule is that they only ever touch server events and never weaken end-to-end encryption or metadata privacy.
Reference topology
Two VPSes, one organization
Redundancy comes from separating the onion roles across hosts — not from piling on infrastructure.
Routers ×2
Onion entry + destination on separate hosts, so no single machine links both ends. Journal or SQLite persistence, PoW on queue creation, per-IP and per-sender rate limits.
File relay
Chunked, size-bucketed uploads with a retention sweeper. Content is end-to-end encrypted; the relay stores padding.
Directory
Your organization's own @username space, with reserved-name policy and PoW on registration.
Camouflage gateway
One :443 front door with a real certificate; splices each secret path to the right local relay and answers everything else with a decoy page.
TURN / push
coturn for E2EE calls, and an optional content-free push relay (APNs/FCM) for deployments that accept a notification ping.
Policy & audit
Retention with hard bounds
Operators tune retention within a normative envelope — the server refuses out-of-bounds configuration rather than silently accepting it.
| Knob | Default | Allowed range |
|---|---|---|
| Undelivered message TTL | 21 days | 1 hour – 90 days |
| Per-queue quota | 128 messages | 16 – 4096 |
| File chunk TTL | 48 hours | 1 hour – 30 days |
| Audit log retention | 400 days | minimum 90 days |
The admin plane
# The admin plane listens on its own port, separate from user traffic.
GET /v1/healthz liveness (unauthenticated)
PUT /v1/policy/pow proof-of-work difficulty
PUT /v1/policy/limits per-IP / per-sender rate limits
PUT /v1/policy/retention retention policy (bounds enforced)
GET /v1/audit/entries audit chain (auditor/admin role only)
# The audit log verifies offline — deletion, reorder or edit breaks it:
# hash_n = BLAKE3(hash_{n-1} || entry_n)
# anchor = Ed25519 signature every 64 entries and at least hourlyStand it up this afternoon
The configurator generates install scripts for a fresh Ubuntu VPS — router, file relay, directory, gateway with a real certificate, and TURN — pinned to the binaries on the download page.