Bring your own key. It stays on your box.

We host the machine, not the model. Six agent CLIs are installed and waiting; you sign each one in with the subscription or API key you already pay for, and that credential never touches our infrastructure.

What's already installed

Every workstation ships with all six, globally installed and on your PATH from first boot:

Cursor and Pi joined the image on 2026-08-07, after the sign-in walkthrough below was written. Both answer on your PATH from first boot; run either one and follow whatever it asks for, and tell us if it asks for something this page did not warn you about.

Versions are pinned in the machine image, so your box doesn't change under you mid-session. They move forward when the image does; you can also update any of them yourself: you have sudo and npm.

Signing in

There is no key field in our UI, no settings page, no vault to paste into. You authenticate each CLI the same way you would on your laptop: run it, and it walks you through its own first-run sign-in.

Cursor and Pi are the two exceptions to "just run it." Cursor authenticates through agent login. Running cursor first only tells you authentication is required. You can set CURSOR_API_KEY instead. Pi opens straight into its own interface, and you connect a provider with /login from inside it. Everything else follows its own first-run prompt.

Each CLI stores its own credentials in its own config directory under your home folder, which lives on your persistent volume. Sign in once; it survives suspends, wakes, and reconnects.

The consequence of that, stated plainly

Because we never hold your keys, we cannot recover them. If your workstation is destroyed (at the end of the cancellation window, say), the credentials stored on it go with it. That's a one-minute re-auth, not a disaster, but it's worth knowing rather than discovering.

It also means we cannot debug your provider's billing, rate limits, or model availability for you. If claude says you're out of quota, that's between you and Anthropic. What we can debug is the machine underneath it.

Agents are terminal sessions

There is no orchestration layer here, and that's on purpose. HolyCode does not wrap, route, or parse agent CLIs: it gives them a real machine and a real terminal. So:

• Your session list is your agent list. One session per agent you have running.
• Watching an agent means reading its raw output, the same bytes it would print on your laptop.
• Steering an agent means opening its session and typing into its own prompt.
• Running several at once is just opening several sessions. Nothing gates it, on any tier.

Close the browser tab and the sessions keep running on the machine. That is the entire point of the product. What that guarantee does and does not cover is in Security basics. Read that section before you trust an unattended overnight run.

Running other tools

It's your machine and you have root. The image ships with the tooling a coding workstation is expected to have, so the obvious things are not yours to install:

• Node, git and the six agent CLIs, plus the usual shell tools: ripgrep, jq, tmux, vim, rsync, wget, tree, htop, sqlite3, dig.
• Python 3 with pip and venv, and a full build toolchain (gcc, make).
• Package managers: uv, pnpm, yarn and npm.
• The GitHub CLI (gh).
• Media tooling: ffmpeg, imagemagick and pdftotext.

Anything past that you add yourself with apt, npm, or whatever you prefer: other agent CLIs, language runtimes, your own tooling. It persists on your volume.

Reaching the box over SSH

The browser terminal is not the only way in. Your box runs sshd, so your own editor, scp, rsync and git over ssh all work against the same machine.

Your login on the box is coder, unless you chose a different username during setup. This is the part people lose time on: a bare ssh your-box.app.holycode.cloud sends whatever username your own laptop uses, and the box turns it away with not listed in AllowUsers. Write it out in full:

ssh coder@your-box.app.holycode.cloud

Two steps, both from your dashboard.

1. Switch SSH on. That gives your machine its own dedicated address. Without it the box answers on a shared address that only carries web traffic, so port 22 goes nowhere from most home connections, which are IPv4-only. It costs you nothing extra and takes a few seconds.
2. Pick how you want to log in. Two buttons appear once SSH is on:
   • Generate a password. We create it (twenty characters, no lookalike letters) and set it on the box for you. It is shown once and never stored, so copy it when it appears. Generating again replaces it.
   • Add a public key. Paste the contents of your .pub file and we install it. The private half never leaves your machine. Paste the wrong half by mistake and we will tell you, rather than accepting it.

You do not need a terminal on the box to set either of these up, which used to be the awkward part: the old way to add a key was to already be logged in.

Root login is refused outright and only your own username is accepted, whichever way you choose. Password attempts are capped at three per connection.

If your box is asleep when you press either button, it wakes for a moment and then goes back to sleep. That is normal.

One thing to know about connecting. SSH does not wake a sleeping box. Opening your workstation does, and so does either button above, so if ssh times out, open your workstation first and then connect. This is deliberate: port 22 is scanned continuously by bots, and if a scan could wake your machine it would never get to sleep, which would cost you the fast, cheap idle state the box is built around.

Once you are in, the connection above lands you in the same home directory, on the same disk, as the browser terminal. Sessions you start over SSH are ordinary shell sessions: they are not the persistent sessions the web terminal manages, so a long unattended run is still better started in a session you can close the tab on.