How we use Beam Cloud
How we run coding on cloud VMs: a box that sleeps until a message, a model through OpenRouter, no real keys on the machine, and a pull request a person merges. What broke, too.
Created November 5, 2026 · Updated November 5, 20266 min read7 chaptersBy Chris Johnston
01 · THE FLOW
A machine for the job. Asleep until it is needed.
We run coding on small virtual machines at Beam Cloud. A message wakes the VM. The harness on the box runs the . The model comes through OpenRouter. The real keys stay off the machine. The opens a pull request, a person merges it, and the VM goes back to sleep.
That is the whole setup. Here is each part, what we tested, what broke, and what we still run on a Mac mini.
02 · THE BOX
It sleeps until a message wakes it.
Our worker VM is small: one vCPU and 2 GB of memory. It stops after five idle minutes and wakes on the next request. Most coding work is waiting on a model, so the small box holds up. A reel edit is different: that VM got 8 CPUs and 16 GB, because it renders video.
The test that sold us: the VM was stopped, one message woke it, and 79 seconds later a pull request was open. One file, two lines, checks green. A person merged it. About five minutes later the box was asleep again.
We aim for one machine per job, and we learned why the hard way. Our first long build shared its box with another test. Their timings overlapped, and a second caller starting a fresh clone would have wiped the folder the build was working in. We would not run it that way again.
03 · THE MODEL
The harness lives on the box. The model does not.
On the VM we install the harness, Hermes Agent. It loads the instructions, holds the session and calls the tools. No model weights sit on the box. Every call goes out through OpenRouter, mostly to GLM from Z.ai. So a VM this small can use a model that large, and changing models means changing one name in a config.
That name change is real work we did: the same reel test ran on GLM 5.2, then GLM 5.3. Run the same brief, read the results, keep what wins. The instruction files stay put, which is the point of portability.
We also forced the model to fail. Background work fell back to a Qwen model on a GPU pod that scales to zero, answered, and the pod went back to zero. The main chat path has no fallback.
04 · THE KEYS
The box holds a placeholder, never the key.
An that writes code will read its own environment. So the real keys do not go in it. Beam stores the secret and the one host it belongs to. The VM only sees a placeholder. When a request leaves for that host, Beam puts the real key in the header on the way out.
We checked the box after setup: placeholders only, and no database login anywhere on it. It can reach a short list of hosts and nothing else. The catch: a VM's secrets are fixed when it is created. When we added a key, we built a new VM. More on where we draw these lines: Is it secure?
An cannot leak a key it never had.
05 · THE PULL REQUEST
The proposes. A person merges.
The never gets a standing GitHub login. It asks our server for a token, cut down to one repo, and it can only push a new branch of its own. Then it opens a pull request and stops.
We tried to make it go further. A merge was refused. Deleting the branch was refused. Another repo was refused. When its connection to our systems was broken at boot, it got an error, no stale answer, and it would not merge or send email.
The 's summary is not proof, either. An early pull request carried an edit from a closed one, because a reused folder still held it, and the reported nothing else was touched. Now every job starts from a fresh clone and prints its file list. We still read the diff. So should you.
Where those requests will come from next: the self-improving software loop.
06 · WHAT BROKE
Red checks and a dead gateway.
The first real build was a 17-file feature. One message, one session, 69 minutes. The checks came back red: 4 of 136 code checks failed, because new public routes were not declared. The worker cannot see its checks or update its own pull request, so a fix means a second pull request. It also has no database and no keys for the live services, so it cannot find bugs that only show when the feature runs.
We built the same feature on the Mac mini, on a different model, with a throwaway database and a real browser test. That build passed, and we recommended it as the base. Neither is merged yet. The test was not fair: model and machine changed together, and the VM had less to test with. The lesson holds anyway. Give a VM jobs it can check, or give it more to check with.
A reel test stalled too. The gateway under the died mid-session, and we never found out why. The launcher now resumes the session when that happens. The next run did not need it: 17 minutes, one build of the three it was allowed, and the automated check passed. A person still judges the cut.
07 · THE MAC MINI
The fleet stays home. Jobs go out.
Our still live on a Mac mini: the messaging gateway, the schedules, the signed-in accounts, and the big builds that need a full browser test with a throwaway database. It stays on, it holds context, and it can run the whole stack. We wrote up the case for that in Run it on a Mac mini.
It has a limit, and we hit it. On November 4, six video renders at once pushed the load past 200, a watchdog killed the gateway, and every dropped off Telegram. The Mac now runs one video job at a time. Heavy or risky work belongs on a box that can fail alone.
So Beam gets the job that needs a clean machine, no secrets and a narrow door. The Mac keeps what needs to be always on. Neither is locked in, because the is files. That is Own your stack in practice.
