A Clip in the cloud
Dillon · 2026-05-01
Or how to run Paperclip in the cloud with ease.
Paperclip's been on my "try this weekend" list since launch, but every time I opened the setup docs my eyes glazed over. It doesn't help that my laptop is already straining under multiple Claude Code/Desktop sessions I have running.
One more thing local felt like the house of cards would finally break.
So I cheated...
I've been beta testing pad.dev, which I'm building with my team (full transparency). It spins up cloud VMs we call Pads, each defined by a Padfile: a config that tells the machine what agents to use (Claude, Codex, etc), what repo to pull, and what scripts to run on setup and start.
The setup/start scripts are where things get fun.
For Paperclip I had mine:
Install it cleanly Pin the right port Hook the Pad's auto-generated preview URL into the running app, so I get a clickable link straight to the UI the moment it boots
My Padfile is currently a crime (very long) and needs a real cleanup, but the setup does exactly what I wanted: Paperclip running in the cloud, my laptop staying quiet, and one toggle to kill it when I'm done.
Below is the full Padfile so anyone can check it out.
Answers
dotta · 2026-05-02
fwiw we're also working on paperclip cloud to make this way easier
Aron Prins · 2026-05-02
Love this — thanks for sharing the full Padfile, that's exactly the kind of thing other folks "thinking about it this weekend" can lift wholesale.
A couple of things you got right that are worth highlighting for anyone copying it:
paperclipai onboard --yes --bind lan is the right shape for a non-loopback host. Paperclip's allowed-hostname check would otherwise reject the preview URL. paperclipai allowed-hostname "3100-${PADALIAS}.pad.dev" — exactly the escape hatch that exists for this case. Without it you'd hit a host-header rejection the moment you opened the Pad's auto URL. Surfacing the bootstrap CEO invite (/invite/pcpbootstrap…) directly in the start log is a really nice touch. That invite is one-shot, so making it copy-pasteable from the very first boot saves people a lot of "where do I log in?" confusion. Using a separate start.log and tailing it as the long-running [[start]] step keeps the Pad's process tree clean while still letting you see "Server listening" deterministically.
A few things you might want to tighten next pass, if you're cleaning up the Padfile anyway:
Skip onboard re-runs idempotently — you've already got the if [ -f "$CONFIG" ] guard, but consider also skipping the allowed-hostname step when the value is already present in the saved config. Keeps subsequent boots quieter. Health probe before printing the URL — you do this with /api/health, but you could move that check ahead of the invite grep so the banner only ever prints when the server is actually accepting connections. Persist the data dir — anything important lives under /home/pad/.paperclip/instances/default/. If your Pad template wipes ephemeral storage between boots, mounting that path as persistent is the difference between "fresh company every time" and "pick up where I left off." For longer-lived setups, peek at the Deployment docs — the Docker mode and the Tailscale Private Access guide cover the same "Paperclip not on my laptop" problem with a slightly different shape (private network instead of a public preview URL). Worth comparing once you've used the Pad version for a bit.
Re: the rendering glitch on the code block — looks like backticks plus the long lines wrapped through a soft hyphen somewhere. If it keeps misbehaving, dropping the leading whitespace on the indented inner lines usually settles it. Either way, the Padfile content is readable as-is.
Genuinely cool to see Paperclip running on Pad. Drop a follow-up once the cleanup pass is in — happy to link this thread from the deployment docs as a community recipe.