Kismet

Kismet is a single binary that makes running processes publicly reachable over HTTPS. An application says "I am flowershop.com, I listen on port 3000." Kismet gets the certificate, accepts the public traffic and routes it to the application.

Run one copy and it works. Run several and they find each other, share the work and cover for each other's failures.

At a glance

• One binary, about 26 MiB, written in Rust. Version 0.2.0, build 5.
• Reverse proxy, certificate automation, load balancing, service discovery, encrypted cross-machine relay and secret store, all in one process.
• No configuration files, service definitions or templates.
• Clustered members keep their state in memory and write nothing to disk, private keys included.
• Joining a cluster takes one command and one credential.
• Made by Frogfish. Official binaries are licensed under the Frogfish Binary License 1.0.

Who it is for

Someone who rents a cloud server and wants flowershop.com to work. They install one thing, point their domain at it, and they are done.

When the shop grows they add a second server, then a third, with the same binary. There is no new component to run, and no migration to a "real" setup.

Larger operators get the same properties: no key material at rest in a cluster, no external dependencies, and failure behaviour that fits in a table.

Why it matters

Putting an application on the internet with automatic TLS, health-aware routing and failover usually means running several systems at once. Most of the configuration those systems need is not anyone expressing intent. It is separately built systems agreeing on what one sentence meant, with the operator carrying messages between them.

When one component owns the whole path from public address to local port, that negotiation goes away, and the configuration goes with it. So do the monthly load balancer bill, the storage to back up and the extra systems to keep running.

What it does

Reverse proxy. HTTP and HTTPS to local or remote application instances, with hostname routing, health checks and WebSocket support. Bodies stream rather than being held whole. Forwarded client identity comes from Kismet itself, whichever member a request arrives at.

Automatic certificates. A registered hostname gets a publicly trusted certificate through ACME HTTP-01. Certificates renew before they expire, the new one is served without a restart, and renewals are paced and jittered so a fleet never stampedes a certificate authority.

Load balancing across machines. Every member is an entry point and can reach every healthy instance in the cluster: a local one if there is one, otherwise over the encrypted relay to the member beside the application. Applications never need to be reachable from the public network.

Failover. If an instance refuses a connection, the request goes to another instance. A member that dies is routed around and its registrations are withdrawn.

A public address that follows a living member. A cluster can hold one of its provider's addresses itself. If the member holding it dies, another claims it through the provider's API, and the provider decides any dispute. DigitalOcean reserved IPs are built in, and any other provider works through an endpoint of your own.

Keys held in memory. In a cluster, each certificate's private key is held in memory by three members and sealed to each one individually, so other members cannot read it. They pass TLS connections to a holder unopened. When a holder dies, the key is held by three live members again without reissuing the certificate.

Secrets. A cluster keeps a service's secrets sealed in memory on three members and gives them only to callers whose token names that service. Membership of the cluster grants nothing.

Graceful stops. A member told to stop finishes the requests in flight, over HTTP and HTTPS, within a bounded grace.

Built-in PKI. The binary issues its own credentials. Applications register over a control API with mutual TLS and scoped tokens, and a fresh machine is claimed with one command over SSH.

Answers about itself. kismet explain says whether a hostname routes and whether it can be served over HTTPS right now, with the certificate's expiry and its last failure.

How you run it

kismet serve --standalone
kismet expose accounts --domain accounts.example.com --target 127.0.0.1:3000

Adding a machine to a cluster:

kismet pki issue --subject prod --join > join.json
KISMET_JOIN=join.json kismet join 10.0.0.1

kismet run registers an application for as long as a child process runs.

Durability is a dial

In a cluster there is no storage layer. Durability comes from how many copies are running, and the operator chooses that number. With two or three members, one can die and the survivors hold the state; when it returns, it rejoins and catches up.

What it replaces

Compared to others

nginx and certbot. Two tools and a configuration file per site, on each server, with nothing shared between servers. With Kismet the application registers once and every member can serve it.

Caddy. The closest on one machine: also a single binary with automatic HTTPS. Caddy's routes come from its configuration, and a Caddy cluster shares certificates through a storage backend. In Kismet applications announce themselves, and members share certificates in memory with no shared storage.

Traefik. Discovers services from a platform such as Docker, Kubernetes or Consul, which you run alongside it. Kismet does its own discovery and needs no platform underneath.

Kubernetes ingress and cert-manager. These assume a Kubernetes cluster and the people to run one. Kismet gives one rented server, or three, the same result with one binary.

Cloud load balancers. A monthly bill, an extra hop and another thing to configure, in front of an ingress that already knows which instances are healthy. In Kismet the cluster is the load balancer.

Consul and Vault. Each is its own cluster with its own durable storage to run. Kismet builds in the discovery and secret delivery this job needs, with memory replicated between members and nothing to back up.

Cloudflare Tunnel and ngrok. Your traffic passes through someone else's network, which typically terminates TLS there. Kismet runs on your own machines, with your own addresses, and holds your own keys.

What it costs to run

Measured on a fast desktop limited to 1 CPU and 500 MiB, with a stand-in application on the same CPU:

On a real 1 vCPU machine, one request at a time, Kismet added about 0.5 ms at p50: 6.8 ms through Kismet against 6.3 ms straight to the application.

Tens of millions of bad or abandoned requests cost effectively no memory.

How it is proven

Each capability has a test that runs through the shipping binary:

• real certificate issuance against a local ACME server;
• three members in containers, with a real partition and heal;
• four members sharing certificates against an ACME server;
• three members moving an address through a stand-in provider;
• four members, reading a secret through a member that does not hold it.

It has also run on real infrastructure: DigitalOcean machines, a real reserved IP, a real Let's Encrypt certificate and a real network.

Works with

Gump schedules and supervises applications, and can announce them to Kismet on their behalf over the Hiccup protocol. Kismet needs no scheduler: an application with a credential and a port needs nothing else.

Meerkat, the Frogfish control panel, has a Kismet plugin. Operators see the cluster, every hostname and certificate, and can withdraw an instance, on a separate operator API that shares no authority with the control API.