Why it exists

ORCHD was extracted from a concrete problem that turned out to be general.

Two products needed the same thing at the same time: run many small workloads, one per tenant, each with its own hostname and its own data, almost all of them idle, cheaply enough that a free tier is not a liability, and isolated enough to run code that was written by somebody else. One product needed a hosted database backend per project; the other needed a set of dev servers per generated app. The interesting half of both was identical, and neither of them was the orchestrator.

So the orchestrator became its own thing.

The workload shape that nothing serves well

The awkward workload is not "a big app with traffic". It is:

• many units — hundreds or thousands, growing with signups, not with load;
• small — tens of megabytes of RAM each while running;
• mostly idle — a preview environment gets opened twice; a free-tier project is visited by its owner and nobody else;
• stateful — each has a volume that must survive being stopped;
• individually addressable — each needs a URL, and sometimes a customer's domain;
• untrusted — the code inside is not necessarily yours.

Every one of those properties is cheap on its own. Together they fall between the tools.

What was rejected, and why

Plain Docker or Compose on the host

This is the closest honest comparison, and ORCHD uses Docker as one of its substrates — so the question is what Docker alone does not do.

docker run starts a container. It does not:

• hand out a hostname, resolve an incoming Host header to a container, or terminate TLS for a customer's domain;
• notice that a container has served no requests for five minutes and stop it;
• start a stopped container because a request just arrived, hold that request while it boots, and then serve it;
• mint credentials for a tenant, or keep an audit trail of who created what;
• snapshot a volume on a schedule to S3 while excluding derived files;
• keep an index of which tenant owns which container, surviving a daemon restart, so the answer to "list every project" does not come from parsing docker ps.

Compose adds multi-service definitions for one project, on one machine, edited by hand. It has no notion of a tenant, a wake, or an idle timeout, and a per-tenant Compose file generated by a script is exactly the thing ORCHD replaces.

The gateway is the crux. Wake-on-request means holding a request while the substrate boots and only then proxying, which requires whatever accepts the request to also control the lifecycle. A reverse proxy in front of Docker cannot do it; a Docker wrapper without the proxy cannot either. ORCHD is both, in one process, which is why they are in one binary.

Kubernetes (with Knative or KEDA for the scale-to-zero part)

Kubernetes solves this. It also asks for an API server, etcd, a CNI, an ingress controller, a certificate controller, and an activator/autoscaler add-on to get scale-from-zero — then someone to operate all of it, and a per-tenant namespace and CRD story on top. That is a reasonable trade at large scale with a platform team. For "pack thousands of 40 MB tenants onto one or two boxes, cheaply", the control plane costs more than the fleet it manages, and the operational surface is the actual expense.

ORCHD's whole state is a JSON file (or SQLite, or Postgres) and its whole control plane is one process you can read end to end in an afternoon.

A PaaS — Fly, Render, Railway, Vercel

Excellent products, wrong unit economics for this. Pricing is per app or per machine, so a fleet of free-tier tenants is a fleet of line items; you do not control packing density, and density is the product when the margin comes from how many idle tenants fit on a box. Running untrusted code is your problem in either case, but on a PaaS you also cannot choose the isolation boundary.

A serverless / FaaS platform

Wrong shape. These workloads are long-lived stateful servers with a volume and an open port — a Postgres-backed backend, a Vite dev server holding a module graph, a Metro bundler. Statelessness and a request/response lifecycle are exactly what they do not have.

systemd, pm2, supervisord

They keep processes alive. They have no tenancy model, no routing, no wake, no data lifecycle, no isolation worth relying on for untrusted code. ORCHD's local driver occupies this niche and needed all of the above around it.

The bet

The bet is that wake latency has become cheap enough to make idleness free. If a suspended workload comes back in about a second, then "stopped" is an acceptable default state, and the cost of a tenant collapses from "its running memory" to "its disk". A box that could hold 40 warm tenants can hold thousands of cold ones. Density stops being a scheduling problem and becomes a concurrency problem — how many are warm at once, which is a much smaller number than how many exist.

Everything else in ORCHD follows from taking that seriously: the gateway owns the lifecycle because it must hold the first request; the volume is decoupled from the instance because instances die constantly; the runtime is an interface because the next factor-of-ten in wake latency comes from microVM snapshots, not from Docker.