2026-10-10 · 6 min read

How to deploy an app built with Claude Code, step by step

Claude Code (or Cursor, or Codex) can write a complete app in an afternoon. The part that usually stalls is the next one: the app works on localhost, but the data lives in your browser, there is no real login and nobody else can open it. This guide takes it from there to a public URL, with a database and user accounts, and your agent does most of the typing.

What you need

• The app's code in a folder on your computer (exported from Lovable, Bolt or v0 works too).
• Claude Code, Cursor or another agent that supports MCP.
• A free Rapibase account. No card.

1. Create the project

In the Rapibase console, create a project and pick its name. That name becomes your address: my-app.rapibase.com. The project already has its own Postgres database, user login, file storage and hosting; there is nothing to install.

2. Connect your agent

In Claude Code, run this once in your terminal:

claude mcp add --transport http --scope user rapibase https://rapibase.com/mcp

Then, inside Claude Code, type /mcp, choose rapibase and press Authenticate. Your browser opens and you pick the project and whether the agent can only read or also write. No key is copied anywhere. In Cursor, add the same URL to ~/.cursor/mcp.json:

{ "mcpServers": { "rapibase": { "url": "https://rapibase.com/mcp" } } }

The Connect section of the console gives you the exact command for each agent, including Claude.ai and ChatGPT.

3. Ask it to move the data

Open the app's folder with your agent and ask in plain words. For example:

Use my Rapibase project as the backend for this app.
Move everything stored in localStorage to tables,
add sign-up and login with email,
and make sure each user only sees their own data.
Do not publish anything yet.

The agent reads the Rapibase guide, creates the tables, turns on row level security so the database itself enforces who sees what, and changes the code to use the API. The public key goes in the frontend; the secret key stays in your .env and never in the chat.

4. Check it before publishing

• Run the app locally and create two accounts.
• Add data with one and log in with the other: it must not see it.
• Open the app in another browser: the data must still be there.

If something is off, tell the agent what you saw. It can read the project's logs and tables to find the problem.

5. Publish

When you are happy, ask: "build the app and publish it on Rapibase". The agent uploads the build and the app is live at my-app.rapibase.com, on the same domain as the API, so there is no CORS to fight. Each publish is a release: if something breaks, you go back to the previous one from the console with one click. The agent only publishes when you ask; if it ever does it on its own, tell it not to.

6. Your own domain

In the console, under Deploys, add your domain (for example www.myapp.com) and create the CNAME it shows you at your DNS provider. HTTPS is issued automatically on the first visit, and the Rapibase address keeps working.

Common problems

• The app needs a server (Next.js with server rendering, an Express API). Most apps work as a static site plus TypeScript functions, which is the simplest option. If yours really needs its own server, Rapibase can run it as a service on the same domain.
• A key ended up in the code. The anon key is meant to be public. The service key is not: ask the agent to move it to .env and rotate it from the console.
• Login with Google. Create OAuth credentials in Google Cloud and add them to the project's configuration; the console shows the callback URL to register.