Does Webamend need an autoscaler?
People who run Kubernetes ask whether Webamend fits a Horizontal Pod Autoscaler. It does not, and this is why that is the right answer rather than a missing feature.
Amit Malul Lev
Software engineer
If you run a Kubernetes cluster, the natural question is whether Webamend fits behind a Horizontal Pod Autoscaler. The short answer is no, and the longer answer is that an autoscaler solves a problem Webamend does not have.
What an autoscaler is for
A Horizontal Pod Autoscaler watches a metric, usually CPU. When it climbs, the scaler adds identical copies of a stateless service. It exists because ten thousand people might hit the same endpoint in the same minute, and the cheapest way to survive that is more copies of the thing they are hitting, spread behind a load balancer, all interchangeable.
Nobody hits Webamend. A client opens the editor and types a sentence, then waits. Then they do it again on Thursday. The load on a Webamend installation is one person asking for one change, and the installation is built around that: one process per client site, one agent at a time per site, and a lock so a second request waits for the first to finish rather than colliding with it on the same branch. There is nothing to put behind a load balancer because there are no interchangeable copies. Each client's process is theirs, under their own Linux user, with their own rootless Docker daemon.
The metric would never move
Suppose you attached an HPA anyway. What would it watch?
CPU is the usual choice, and an agent run is almost entirely waiting for a model to answer. The container sits there with the files while OpenRouter thinks, writes a few lines, then waits again. A CPU-based scaler would see a flat line and do nothing, which is correct, but then you have an autoscaler that never scales. Request count is no better. It is a few per week per client, so the scaler's polling interval is longer than most of the traffic.
Memory per client is close to fixed. An idle installation holds a small amount and a running agent holds a few hundred megabytes more, and that number does not climb with the size of the request. It climbs with the number of clients, one step per client, which is a capacity-planning question and not a runtime one. You know the answer before you deploy.
Could you run it on Kubernetes at all?
You could, and I would not. The sealed room where the agent works is a container started by a rootless Docker daemon that belongs to the client's Linux user. Reproducing that inside a pod means Docker inside Docker, or a privileged pod, or a sandbox runtime that gives you user namespaces back. All of those exist. All of them are you rebuilding, with more moving parts, the isolation that a plain Linux user already gives you for free. What the repository ships is a bootstrap script and Compose files, because that is the shape of the problem.
How capacity actually grows
Horizontal scaling still happens. It just happens at the granularity of clients rather than requests, and by hand rather than by controller.
One machine runs some number of client sites, set by its memory. When the next client would not fit, you add a machine and put them there. The release script builds the images once and hands them to every client daemon on the host, so a new machine is the bootstrap script plus a copy of each client's .env file. There is no database to shard and no session to keep sticky, because the state a client cares about is in GitHub and Netlify, not on the box. Moving a client between machines is moving one small file.
That is the whole scaling story. It is boring on purpose. The interesting part of Webamend is what the agent is allowed to touch, and I would rather spend the complexity budget there than on a scheduler that has nothing to schedule.
The one case that looks like a scaling problem
A busy client may want two changes running at once. The answer is the lock: no, and that is deliberate. Two agents editing the same repository at the same time produce two branches that do not know about each other, and the second preview is wrong the moment the first one publishes. The queue is the feature. A client who really does need two changes an hour has a site that has outgrown a chat box, and the right move is a conversation, not a replica.
If you are sizing a machine, where to run Webamend has the numbers. If you have a setup this does not cover, write to me and describe it.