Why we built Launchpad for Claude Code
· The Launchpad crew · 3 min read
Something shifted in how software gets built. A single person with a clear idea and a coding agent can now produce, in an afternoon, what used to take a small team a fortnight. We've watched non-engineers build real internal tools this way. It's genuinely new.
And then the afternoon ends with a working app on a laptop, and the next question is the same one it's always been: where does this go?
The last mile hasn't moved
Getting a working app to a URL still means the usual list. Pick a host. Size a server. Install a database. Wire up credentials. Configure a web server. Sort out DNS. Get a certificate. Work out how you'll deploy next time. None of that is hard for someone who does it weekly. All of it is a wall for someone who doesn't.
The cruel part is that AI coding tools are perfectly capable of doing that work. Claude Code can install nginx, write a systemd unit and run a migration. What it lacks isn't skill. It's a place: a real server it's allowed to touch, with a safe way in.
"Against the live server" is the whole idea
There are two common answers to this today, and we didn't love either.
The first is to give the agent a toy environment: an in-browser sandbox or a preview container that resets when you close the tab. It's safe, but it's not real. The moment you want a database that persists, a background job, or an address you can send to a colleague, you're back to the wall.
The second is to hand the agent the keys to your actual cloud account. This is real, but it's terrifying, because the agent's mistakes have the same blast radius as yours. Nobody should be one confident tool call away from deleting a production bucket.
Launchpad is the third answer. Claude works against a real server, one that persists, has a database, and serves a public URL. But that server is a sandbox: dedicated to one project, isolated from everything else, and reachable only through a short-lived, single-host certificate that the Launchpad connector issues on demand. Claude gets a real shell on a real box. It cannot reach any other box. There is no "production infrastructure" for it to break, because you don't manage any.
What the connector actually does
The Launchpad connector installs into the Claude desktop app in a few clicks. Once it's on, Claude Code gains a handful of tools:
- Launch a server on your plan, and poll until it's ready.
- Open an SSH session: the connector mints a certificate scoped to one server that expires in thirty minutes.
- Deploy over HTTPS for environments that can't open SSH at all.
- Read logs and health, so a failure is diagnosable from inside the conversation.
- Rename the subdomain, list servers, revoke sessions, and so on.
That's deliberately small. Everything else, Claude does with the shell it already knows. We didn't want to build a proprietary deploy abstraction that Claude has to learn; we wanted to give it a normal Ubuntu server and get out of the way.
What it feels like
You open Claude Code in the desktop app and say: "Spin up a Launchpad server for the quoting tool and deploy what we've built."
Claude asks the connector for a server. A minute or two later it's up, with nginx, MySQL and a *.asklaunchpad.com address. Claude requests a session, copies the app over, creates the database, writes the service file, restarts it, checks the logs, notices the port is wrong, fixes it, checks again, and hands you a link.
You didn't open a cloud console. You didn't read a DNS guide. You did the fun part.
That's why we built Launchpad for Claude Code. Not because the building was hard, but because the launching still was.