Reverse proxy for Docker Swarm
Apiary routes HTTP, TCP and UDP to your Swarm services, renews HTTPS certificates on its own, and keeps its state replicated between its replicas. No database to run, no Docker socket to hand over.
The admin interface
Every change tells you how many replicas applied it. Every risky action tells you what keeps working and what stops. Light and dark, keyboard first, designed for WCAG 2.2 AA.
Replicas agree on every change with the Raft consensus algorithm and keep their own encrypted copy of the state. No etcd, Consul, Redis or Postgres next to it.
Lose most of the cluster and every surviving replica keeps routing with the last routes and certificates. Only changes pause, and the interface says so in plain words: “Changes are paused.”
docker stack deploy.Create the root key once. Replica certificates, the cluster’s certificate authority and the data keys rotate by themselves. Deploying, upgrading and scaling is a stack file and docker stack deploy.
Access to the Docker API is root on your hosts, so Apiary doesn’t ask for it. Routes come from the interface, its API, your AI agents, or your stack files through your pipeline.
Declare routes as labels in the stack file. apiary apply sends them from your pipeline in one all-or-nothing write, with a dry run for merge requests. Fields set by labels are locked in the interface.
A built-in MCP server, with Apiary as its own OAuth authorisation server. Agents sign in as you and get your role. Private keys and backups never pass through them.
Loopback, link-local and cloud metadata addresses, and Apiary’s own ports, are refused. It checks the address each connection actually reaches, so DNS rebinding doesn’t get through either.
A change and its audit entry are written in the same Raft entry, so nothing changes unrecorded: who, from where, through the interface, an agent or a pipeline.
If most replicas are lost for good, a forced recovery picks the most recent survivor, shows what may be lost before it starts, and signs everyone out, so a lost revocation can’t give access back.
High availability
Apiary runs as one replica per edge node. Some vote on changes and the rest follow, serving traffic without slowing writes down. Here is what happens when things go wrong, with three replicas.
| What happens | Traffic | Changes |
|---|---|---|
| A rolling update | Keeps flowing | Brief pauses |
| One node fails | Keeps flowing | Accepted |
| The leader fails | Keeps flowing | Wait 2–3 seconds for a new leader |
| Most replicas fail | Keeps flowing, with the last routes | Paused until they return |
| The network splits | Keeps flowing, maybe with older routes on one side | Accepted on the majority side |
Certificates renew weeks before they expire, so a cluster that can’t take changes for a while still has time to recover. Read the failure modes
Features
Beyond routing: the things you would otherwise script, bolt on or remember to do.
Certificates from Let’s Encrypt, requested by one replica at a time and answered by any of them, so a lagging node never fails a check. Failures back off to stay inside Let’s Encrypt’s rate limits, and the renewal log says what went wrong. Upload your own for wildcards or an internal CA.
Split a route between versions by weight, send testers to the new one with a header or cookie, and keep each visitor on the version they first reached with sticky sessions.
curl -H 'X-Canary: true' https://shop.example.com/
Labels on each service declare its routes, redirects and stream routes. Your pipeline runs apiary apply right after docker stack deploy, and Apiary shows each apply with its commit and pipeline.
services: web: image: registry.example.com/shop/web:2.4.0 networks: [apiary] deploy: labels: apiary.project: Shop apiary.route.site.host: shop.example.com apiary.route.site.port: "8080" apiary.route.api.host: shop.example.com apiary.route.api.path: /api apiary.route.api.port: "8081"Connect Claude Code with one command, or any MCP client with an address. The agent signs in through your browser and acts with your role, and every action it takes is in the audit log with its name.
Sign in with OpenID Connect providers such as Entra ID or Keycloak, with roles mapped from groups. Local accounts stay as a break-glass way in, with an authenticator app required for every one.
List your trusted proxies, and allowlists, rate limits and logs use the visitor’s real address. Try a request on the page to see exactly which address and scheme Apiary will use.
When Apiary answers instead of a site, for maintenance, a password or a missing route, it shows a small page in your brand, with no scripts. Protect previews with a shared password or a sign-in link.
Rotating the root key is a new Swarm secret and one docker stack deploy. Replicas move over one by one, the interface shows the progress, and Apiary forgets the old key by itself.
And the rest
With HTTP to HTTPS redirects.
Databases, MQTT, SMTP. Several TLS services on one port, chosen by SNI without decrypting.
A hostname or a path, 308 by default. Loops and redirects that would hide a route are refused.
Scheduled per route, in UTC, with your own message.
Per route, IPv4 and IPv6. Everyone else gets a 403.
Per visitor, with IPv6 counted per /64 network, so rotating addresses doesn’t help.
30 MB by default, up to 100 GB, or none. Uploads are streamed, never buffered.
Off by default and turned on deliberately, because each has a way to hurt you.
Checked every 15 seconds by every replica. A wrong verdict never takes a site offline on its own.
Metrics and traces over OTLP, and a /metrics endpoint on the admin port.
JSON lines, query strings left out, and an option to shorten IP addresses.
On demand, from the interface. Restore into a new cluster.
Group routes, redirects and certificates, each project with its own brand.
Viewer, Operator and Administrator, for people and agents alike.
Get started
On a Swarm manager, with three nodes that face the internet. The full guide covers firewalls, DNS and the stack file. Read the deployment guide
Apiary runs one replica on each labelled node.
docker node update --label-add apiary.edge=true <node>Then copy it into your secret store and delete the file. It’s the only secret you’ll manage.
(umask 077 && docker run --rm datapointsoftware/apiary:1.0.0-beta.4 secrets init > apiary_root_key_1)docker secret create apiary_root_key_1 apiary_root_key_1Start from the stack file in the repository and set your admin network and Let’s Encrypt email.
APIARY_VERSION=1.0.0-beta.4 docker stack deploy -c stack.yaml apiaryFrom your admin network only, on port 9443. The first visit creates the first administrator, with an authenticator app.
https://<edge-node>:9443Just looking? Try it on your laptop with Docker Compose:
git clone https://github.com/datapoint-software/apiary.git && cd apiarydocker compose -f deploy/compose.yaml up --buildApiary is in beta. It’s feature-complete, and some behaviour may still change before 1.0.0. Try it on a development Swarm before relying on it. Since 1.0.0-beta.1, each version upgrades the one before it in place.
Licence
AGPL-3.0
Use, change and share Apiary at no cost. Offer a modified version to others, over a network included, and you offer them its source under the same licence.
On request
For organisations that build Apiary into their own product or service, or would rather not take on the AGPL’s obligations.
or write to hello@datapoint.software
Apiary is in beta and feature-complete. Decisions made while building it are still being reviewed, so some behaviour may change before 1.0.0. Since 1.0.0-beta.1, each version upgrades the state of the one before it in place.
For high availability, yes: three or more replicas on a Swarm. The same image also runs on a one-node Swarm, which can grow to three replicas later without moving data, or with Docker Compose on a single machine.
Changes need a majority of voters. Two replicas tolerate no more failures than one, and changes stop if either is down. Three tolerate one failure, five tolerate two.
Yes. Apiary publishes its ports in Swarm’s host mode, so it sees real client addresses, and sends them on in X-Forwarded-For. Behind a load balancer or CDN, list it as a trusted proxy.
On port 9443 of every edge node, which must never be reachable from the internet. It’s protected by your network firewall, an allowlist inside Apiary, and sign-in with a second factor.
.NET 10 and Microsoft’s YARP for proxying, DotNext’s Raft for replication, and Angular for the interface. One image, datapointsoftware/apiary, on Docker Hub.
Datapoint Software, a software company in the Azores, Portugal, since 2017. We run Apiary in front of our own sites.
Questions about the commercial licence, support or a deployment? We’re happy to talk.