Dora NodaA developer shipped a self-hosted serverless runtime on Hacker News in July 2026, and the headline number is a cold start of about 30 milliseconds — not the 1.2-to-2.8-second p95 you'd budget for a cold Node.js function on AWS Lambda, and not the several-hundred-millisecond-to-multi-second wait for a stopped Docker container to spin back up on a Coolify or Dokploy box either. Cygnus is a single Rust binary that runs Bun and Node apps inside kernel-sandboxed "cages" instead of containers, and one commenter on the Show HN thread immediately asked the right skeptical question: namespaces, cgroups, mounts, and seccomp setup only account for about 3 of those 30 milliseconds — so what's actually happening in the other 27?
That question is worth answering, because it's the whole story. Cygnus isn't "Docker but faster" — it's a genuinely different isolation primitive, and that's exactly what lets it scale an idle app to zero and revive it fast enough that a request never notices. That's also exactly what the container-per-app single-box tools this category has produced all year — Coolify, Dokploy, CapRover, and July's own Mist — don't do and structurally can't, because a resident Docker container is the unit they orchestrate, not a function that can vanish between requests. Here's what the serverless framing buys, concretely, and what it still leaves unsolved.
What 30 Milliseconds Actually Buys
The 27 milliseconds the HN commenter was asking about isn't mystery overhead — it's Node/Bun runtime boot: parsing and executing the app's own code up to its first listener, the same cost any process start pays. What Cygnus's architecture removes is everything around that boot: no image pull, no container runtime handshake, no daemon-to-daemon RPC. A "cage" is a kernel namespace (userns, mntns, pidns, netns), a cgroups v2 group, and a roughly 80-syscall seccomp allowlist, assembled directly by a privileged Rust daemon that also terminates TLS and routes by SNI/Host through a lock-free table. There's no container image to pull because there's no container — the app's code is already sitting in the page cache from the last invocation, so "cold start" for an app Cygnus has run recently is closer to "resume a process" than "provision an environment."
Compare that to the two things it's implicitly competing against:
- Traditional serverless (AWS Lambda). A genuinely cold Node.js function on Lambda runs a p95 of 1.2 to 2.8 seconds — provisioning a new execution environment, pulling the deployment package, and booting the runtime from scratch. Lambda's own fixes for this (SnapStart, Graviton) shave that down but don't eliminate the structural cost of "this environment didn't exist a moment ago." Cygnus pays almost none of that tax because the daemon that owns the cage never goes away — only the tenant process inside it does.
- Container-per-app single-box PaaS (Coolify, Dokploy, CapRover, Mist). These tools don't have a cold-start problem in the Lambda sense because they mostly don't try to solve it — an app's container is either running (consuming its full memory footprint at all times) or it's been manually stopped. None of them scale an idle app to zero and revive it on the next request; that's not the resource model. So they never pay Cygnus's 30ms, but they also never give back an idle app's memory, and a box with fifty rarely-used side projects on it is fifty containers' worth of resident RAM whether or not any of them get traffic that hour.
That's the actual trade the serverless framing makes, stated plainly: Cygnus gives up the "your container is always warm and always identical to how you left it" guarantee of the Docker model, and in exchange gets memory back from every app that isn't currently serving a request — at a revival cost low enough (sub-100ms target, ~30ms measured) that a user genuinely might not notice. For a box hosting a dozen low-traffic side projects, side-by-side dev previews, or per-PR ephemeral environments, that's a real, specific win a container-per-app tool doesn't have an equivalent for — not a vague "serverless is more efficient" claim, but a concrete resource-reclamation mechanism with a measured latency cost attached.
Put a number on it. A homelab operator running fifteen small side projects on a Coolify box, each Node container idling at a conservative 150MB resident (Express plus a small dependency tree, no traffic), is paying roughly 2.25GB of RAM around the clock for apps that might collectively see a few dozen requests a day — memory that's simply gone, whether or not anyone's using it, because Coolify's model is "the container is running or it's stopped," not "the container exists somewhere between the two." The same fifteen apps as Cygnus cages give that memory back to the host the moment each one goes idle, and get charged the ~30ms revival cost only on the next request that actually shows up. On a 4GB box, that's the difference between "comfortably fits fifteen apps with room to spare" and "already over half committed to processes nobody's talking to right now." That's a genuinely different resource model, not a marginal optimization on the same one — and it's specifically a model container orchestration wasn't built to offer, because a container's whole contract is "I stay exactly as you left me until you tell me to stop."
It's worth being honest about where this stands today, too: Cygnus is a brand-new project — 7 GitHub stars, one fork, a single Show HN launch as of this writing — under an AGPL-3.0 license, built by one developer (ccheshirecat) explicitly frustrated with the existing menu of "Docker is heavy, MicroVMs are maintenance overhead, Workerd is too restrictive, managed serverless is expensive and locks you in." The architecture is real and the numbers check out against the HN thread's own scrutiny. Whether it holds up in production, under a wider set of Node/Bun apps than a demo, at this project's current age, is an open question — not a criticism of the approach, just a fact worth stating before treating a week-old launch as a settled comparison point.
What It Still Doesn't Solve: One Box Is Still One Box
Here's the part the "fast, lightweight, self-hostable serverless runtime" pitch doesn't mention, because it's not what the pitch is about: Cygnus, like every container-per-app tool in this category, runs as a single daemon on a single machine. There's no clustering, no federation, and no multi-node deployment path anywhere in its docs. That's not a gap unique to Cygnus — it's the same seam this category has now produced independently, tool after tool, all through 2026: Coolify's "Add Server" connects to a box you already provisioned by hand and still schedules nothing across it; Dokploy's Docker Swarm mode gets you multiple machines but not a machine your control plane provisioned, healed, or drained on its own; Mist doesn't attempt multi-node at all, by design, for its stated homelab/side-project audience.
What that seam actually costs shows up the day one app on the box gets popular. Every cage on a Cygnus host shares one kernel, one cgroup hierarchy, one network namespace pool, and one Rust daemon's CPU and I/O budget — a noisy neighbor isn't a namespace violation, it's contention for the same physical resources every other cage on that box is drawing from, and there's no second machine to move the noisy app to. Take the same fifteen-app homelab box from above: one of those side projects lands on Hacker News, its cages start reviving and serving at a sustained rate, and it's now competing for the box's CPU scheduler and disk I/O with fourteen apps that have no idea anything changed. On a real multi-machine platform that app gets its own node, or at minimum its own resource-isolated slice of a node pool sized for it. On a single Cygnus box, the operator's actual options are "let the other fourteen apps degrade" or "manually move the popular app somewhere else" — the same manual-intervention answer Coolify and Dokploy operators have always had for this exact scenario, because "somewhere else" was never a thing the tool itself could reach for. And if the daemon process itself dies — an OOM kill, a kernel panic, a bad update — every app on the host goes down with it, because there's no other host running a copy of that daemon to fail over to. None of that is a bug in Cygnus's design — a single-binary, single-box tool that tried to also solve multi-machine scheduling wouldn't be a single binary anymore. It's a scope boundary, and it's the same scope boundary Coolify, Dokploy, CapRover, and Mist all drew for the same reason: multi-machine orchestration is a genuinely different problem than "run apps well on the box in front of you," and solving the second one well doesn't get you partway to the first.
That's also precisely the gap a Cluster API-based platform is built to not have. Where Cygnus provisions a cage on a box that already exists, a Cluster API-managed fleet provisions the box itself — declaratively, from a MachineDeployment spec, against a provider like Hetzner or bare metal, with node health checks and automated replacement built into the control loop rather than left as a human's 2am pager duty. A popular app doesn't have to fight fourteen quiet neighbors for the same box's scheduler; it schedules onto whichever node in the fleet has headroom, and a new node joins the pool automatically once none do. If a node dies, the control plane notices and reschedules the apps that were on it without anyone clicking "restart." That's not a knock on what Cygnus shipped this week — it's one developer's week-old, 7-star launch solving a real and narrow problem well. It's a statement about what "outgrows one box" actually requires once it happens, and why that requirement doesn't get any smaller just because the box in question revives its apps in 30 milliseconds instead of running them all the time.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned and healed by Cluster API instead of a single box's daemon. Star the repo on GitHub or deploy your first app today.
