Projects
Apiary: the front door to your systems, without a single point of failure
Datapoint has released Apiary, a free, open-source reverse proxy for Docker Swarm. It sends traffic to the right service, renews HTTPS certificates by itself and keeps running when a server fails, with no extra database to look after.
Every website and application on the Internet has a front door: a component that receives each visitor's request, decides which service should answer it and takes care of the secure connection (HTTPS). Hardly anyone notices it, until the day it fails. When the front door goes down, every site behind it goes down with it.
So that this door is never the weak spot, Datapoint has released Apiary, a free, open-source reverse proxy for Docker Swarm. It sends traffic to the right service, obtains and renews HTTPS certificates by itself and keeps running when a server fails, with no extra database to look after. Apiary is in beta (1.0.0-beta.1), and anyone can read, use and improve the code in the repository at github.com/datapoint-software/apiary.
The building's receptionist
Picture an office building shared by several companies. Visitors do not go straight up to the floors: they stop at reception, which checks who they are, confirms which company they are visiting and points them to the right lift. If a company moves to another floor, only reception needs to know. Visitors keep coming in through the same door.
A reverse proxy does the same job for information systems. It receives every request that reaches shop.example.com, shop.example.com/api or payments.example.com and hands each one to the service that should answer it. It is also where the certificates that keep the connection secure are handled, where abuse is limited and where a maintenance page is shown when needed.
Why the front door cannot fail
Many organisations already run their applications in containers, with Docker Swarm spreading them across several servers. If a server fails, Swarm starts the applications again on another one. But spreading the applications across several servers achieves little if all the traffic goes through a single door that can fall over.
A front door that depends on a single server turns that server into the single point of failure for every site.
The usual answer combines several parts: a proxy, a separate store for its configuration, a tool for the certificates and scripts that keep everything in sync between servers. Each part is one more thing to install, update, back up and keep available. Apiary puts all of this in a single image, made for Swarm.
What Apiary does
Routing. A route connects a hostname and path, such as
shop.example.com/api, to a service. Apiary reaches services by their name on Swarm's network, so there are no IP addresses to keep up to date. It supports HTTP/1.1, HTTP/2, HTTP/3 and WebSockets, and also forwards TCP and UDP traffic for things that are not websites, such as databases, MQTT messages or system logs.Automatic HTTPS. It obtains certificates from Let's Encrypt and renews them before they expire, without manual steps. Every server shares the same certificates. You can also upload your own certificates, for example for wildcard names or from an internal certificate authority.
Everyday operations. Redirects, disabling routes, IP allowlists, rate limits, password-protected previews, scheduled maintenance windows with a custom message and pages for visitors with each project's own logo and colours.
Observability. The overview shows requests per minute, latency, error rates, the health of every target and certificates that are about to expire. Metrics and traces are available for monitoring tools.
Access and accountability. Users sign in with an authenticator app or the organisation's single sign-on (OpenID Connect). Roles limit who can change what, and the audit log records every change, who made it and from where.
AI assistants. Apiary can be managed by artificial intelligence assistants through MCP (the Model Context Protocol), with its own sign-in, so an assistant can only do what its user is allowed to do.
In English and Portuguese. The interface is available in English and European Portuguese.
New versions without the jitters
Releasing a new version of an application to every visitor at once is risky: if something goes wrong, it goes wrong for everyone. With Apiary, a route can split traffic by weight, for example 90% to the current version and 10% to the new one. This is known as a canary release. If the new version behaves well, its share goes up. If not, you roll back, and only a small share of visitors was affected.
Testers can reach the new version on purpose with a header or a cookie, and sticky sessions keep each visitor on the same version for an hour, so nobody jumps from one to the other halfway through a purchase.
A hive of replicas
Apiary runs as several copies (replicas) on different servers, which keep each other up to date using Raft, a well-known agreement algorithm. One replica is the leader and the others vote. If a server fails, the rest keep serving traffic and no certificates are lost. When Swarm starts a new replica, it joins the others by itself.
High availability needs at least three replicas. Two are not supported, because they tolerate no more failures than one. And if too many replicas are lost for them to agree, Apiary pauses changes, says so clearly in the interface and keeps serving visitors with the last known configuration. Apiary also runs on a single server, or on a laptop with Docker Compose, but without high availability. It is a good way to try it.
Every situation, one answer
| Situation | What Apiary does |
|---|---|
| A server fails | The other replicas keep serving traffic, with the same certificates. |
| Too many replicas are lost | It pauses changes, says so in the interface and keeps serving with the last known configuration. |
| A certificate is about to expire | It renews it by itself and, if renewal fails, warns you and shows the log of what went wrong. |
| A new version of an application arrives | It splits traffic by weight and lets testers reach the new version on purpose. |
| The team releases a change | It applies the routes declared in the stack file and records what was added, changed and removed. |
| Apiary itself needs upgrading | It replaces one replica at a time and rolls back by itself if something fails. |
Configuration next to the code
Teams can describe their routes as labels in the same stack file that deploys their services. After each deploy, their continuous integration and delivery (CI/CD) pipeline sends that file to Apiary, so routes change in the same commit as the code. Fields that come from the file are locked in the interface, so nobody overwrites them by accident, while disabling a route and scheduling maintenance stay available.
There is an important security choice here: Apiary never touches Docker. Many Swarm proxies need access to the Docker socket, which in practice grants control of the whole server. With Apiary, the pipeline reads the stack file and sends Apiary only what it declares.
Deliberate choices
No external database. Apiary keeps its configuration and certificates itself, replicated between its replicas. There is nothing else to install, back up or keep available.
Deployed like any other Swarm application. After creating one secret key, installing, upgrading and scaling Apiary is a single
docker stack deploy.Safe defaults. Compression is off by default, because on some pages it can leak secrets; passwords and certificates cannot be put in stack files, where anyone who can inspect a service could read them; and routes that would point back at Apiary's own admin interface are refused.
An interface written for people. Error messages say what to do next, dangerous actions name exactly what they affect, and every time is shown in UTC, so teams in different time zones read the same thing.
For technical teams
This section is more technical. Apiary's server is written in .NET 10 and uses YARP, Microsoft's reverse proxy library; replication uses Raft and the interface is built with Angular. The image is datapointsoftware/apiary, on Docker Hub. Using automatic certificates means accepting the Let's Encrypt Subscriber Agreement, as Let's Encrypt is a third-party service.
Apiary is in beta: it is feature-complete and can be upgraded in place from 1.0.0-beta.1, but some behaviour may still change before 1.0.0. It is free software, under the GNU AGPL version 3 with additional terms: anyone can use, change and share it, and modified versions that are shared or offered over a network must make their source code available. The documentation, installation instructions and code are in the repository, where we welcome suggestions and bug reports.
How we work
At Datapoint, we develop, deploy and maintain information systems, and we know that a system is only available if its front door is too. We have published Apiary as open source so that any team can use, study and improve it. If you want your systems' infrastructure to stop depending on a single server, get in touch.