Engineering notes Licensing

Why Taxiway isn't open source yet

Lloyd Owen

4 September 2026 · 8 min read

Taxiway is free, it runs on hardware you own, and it is closed source. That last one is the part people push back on, and they are right to. This is the actual reasoning rather than a principled-sounding version of it, including the argument I am deliberately not going to make.

The argument I am not making

Closed source is not more secure than open source. That idea has a name, security through obscurity, and it has been the wrong answer since Kerckhoffs wrote it down in 1883. A system whose safety depends on nobody reading it is a system that is one leaked repository away from being unsafe. If my defence were “you cannot see the bugs”, the bugs would still be there, and the people who look hardest for them would find them anyway.

So I am not claiming Taxiway is safer for being closed. It is not.

What I am claiming is narrower, and it is about who is on the other end when something is found.

What the agent actually is

The Taxiway agent runs on your server and talks to the Docker socket. That is not a detail. Access to the Docker socket is root-equivalent on the host: anything that can talk to it can start a container that mounts your filesystem.

That is the job, and there is no version of this product where the agent has less power than that. But it means a vulnerability in Taxiway is not a defaced marketing page. It is somebody else’s production database, on a machine I have never seen, belonging to a person who trusted a free tool.

I take that seriously enough to be conservative about the pace at which I widen the attack surface.

What AI actually changed

Here is where I have to be careful, because “AI” has become a way to end an argument rather than make one.

The specific thing that changed is the cost of a first pass over an unfamiliar codebase. Reading two hundred thousand lines of Go you have never seen, building a mental model, and producing a list of places where input reaches something dangerous used to be days of skilled work. It is now cheap, fast and available to anyone.

That is genuinely wonderful, and I use it constantly. But note who it is symmetrical for and who it is not:

  • It is symmetrical in finding. An attacker and a maintainer can both run it.
  • It is wildly asymmetrical in fixing. Ten people can generate a hundred plausible findings against a new public repository in an afternoon. One person has to triage all hundred, work out which three are real, fix them, cut a release, and get every self-hosted agent in the world updated.

The traditional answer is Linus’s law: given enough eyeballs, all bugs are shallow. I believe that. But it is a statement about enough eyeballs, and the eyeballs are not evenly distributed. A new project with a handful of stars is scanned by automation long before it is read by a reviewer who cares. You get the disclosure volume of a popular project years before you get the review capacity of one.

The part that is really about me

Strip out the security framing and there is a plainer version underneath.

Publishing a repository is not publishing a repository. It is committing to issue triage, pull request review, a security disclosure address that is answered in hours rather than whenever I next open my laptop, a backport policy, and a release process I cannot quietly skip because someone is depending on the fix. That is a job. It is a real one, and people who do it well do it full time.

I build Taxiway alone, mostly in evenings. I can do that job or I can make the product work. I cannot currently do both, and a public project maintained badly is worse than no public project at all: it looks like a promise of scrutiny and support that nobody is actually providing.

I would rather say that out loud than open the repo, let the issue tracker rot, and let you infer it.

What this costs you, plainly

Two things, and they are not small.

You cannot audit it. You are trusting me and my judgement about a binary with root access to your server. That is a real ask, and if your answer is no, that is a completely reasonable answer.

You cannot fork it. If I lose interest, get hit by a bus, or make a decision you hate, you have no path to carrying on. With Coolify or Dokku you do.

I am not going to dress those up. What I can do is make the blast radius small, and that is a design decision rather than a promise.

So here is exactly what happens to your setup if I stop showing up tomorrow.

Keeps working

  • Keeps working: Your containers: yes Your containers Still running, still serving traffic.
  • Keeps working: Traefik routing: yes Traefik routing The labels are already on your host.
  • Keeps working: Your databases: yes Your databases The volumes never left the machine.
  • Keeps working: Backups you have taken: yes Backups you have taken Already in your bucket as .sql.gz and .tar.gz.
  • Keeps working: The images you built: yes The images you built Still on the host's disk.

Stops working

  • Stops working: The dashboard: no The dashboard Nothing left to sign in to.
  • Stops working: New deploys: no New deploys Nothing builds or ships a new image.
  • Stops working: Logs and metrics: no Logs and metrics Collection stops, history goes with it.
  • Stops working: Certificate renewal: no Certificate renewal ACME runs on our side, so certs expire in 90 days.
  • Stops working: New databases: no New databases No one-click provisioning.

Your containers do not phone home to run. Traefik has its routing on your host already. Your database volumes are yours. Your backups are already sitting in your own S3 bucket as ordinary gzipped SQL dumps and tar archives, restorable with psql and tar and no software of mine involved.

The honest entry on the other side of that drawing is certificate renewal. ACME runs on our gateway, so certificates already issued keep working, and renewing them does not. A Let’s Encrypt certificate lasts ninety days, so that is your outside window to move, not an indefinite grace period. I would rather you knew that today than found out in month three.

What has to be true before it opens

I am not going to give you a date, because a date I invent is worth nothing. I can give you the conditions, which are the things I would actually be waiting for:

  1. A second pair of hands. Someone other than me who can triage a security report while I am asleep. This is the big one, and it is mostly a funding question.
  2. A funded security review. Not a scan. A real one, by someone who does this for a living, before the code is in front of everybody rather than after.
  3. A disclosure process I can staff. A published policy with a response time I can actually meet, rather than one copied off another project’s README.
  4. A stable agent protocol. Right now the wire format between agent and gateway still moves. Opening it mid-churn hands people a contract I would then break.

If I had to guess at the order it opens in, the agent goes first. It is the piece that runs on your machine, with your data, holding the socket that matters, and it is the piece you have the strongest claim to be able to read. The control plane can follow.

Meanwhile

If open source is a hard requirement, it is a hard requirement, and you should use something else. Coolify is Apache 2.0, Dokploy is Apache 2.0, and Dokku is MIT. All three are good, all three are free, and each of those pages says where they beat Taxiway. I would rather send you to one of them than have you choose Taxiway on a misunderstanding.

And if you are willing to live with the trade for now, the trade is at least written down here, in specifics, with the uncomfortable parts left in.


If you think I have this wrong, or you want to be the second pair of hands, I would like to hear from you: support@taxiway.cloud.

Start deploying in minutes.

Point Taxiway at a server you own, connect your repo, and push. That's the whole setup, and it costs nothing.