How to use &Deploy with Claude

Connecting

Add &Deploy to Claude once. The full walkthrough, with copy buttons, is on Get started.

• Claude app and Cowork: Settings → Connectors → Add custom connector, URL https://anddeploy.com/mcp.
• Claude Code: claude mcp add --transport http anddeploy https://anddeploy.com/mcp, then run /mcp and choose Authenticate.
• Claude Code plugin: the plugin adds the connector plus a skill that teaches Claude Code the deploy workflow.

When you connect, you pick one workspace and decide whether Claude may deploy to production when you ask, and whether it may request &Bridge connections. Disconnect any time from your dashboard.

Apps and sizes

Ask Claude to put an app on &Deploy and it creates one for you. Tell it roughly how many people will use the app and it picks the size; the first Nano app in each workspace is free. Every app gets a name like team-booking, which becomes its address.

Sizes are about how many people use the app each month. See Pricing for every size and limit.

Pushing a version

When you're happy with a change, say "put this on &Deploy" or "push the latest version". Claude sends the whole app, which becomes the next version (v1, v2…). &Deploy then:

1. Scans the code for secret keys that would be visible in the browser, and refuses the push if it finds one.
2. Saves it to the app's git repository on its own branch, with a pull request and the conversation's prompts.
3. Works out how to build it (React, Vite, Next.js static export, Astro or plain HTML) and builds it in a sealed sandbox.
4. Applies any database changes to the dev database and runs the database check.
5. Publishes it to the app's dev copy and gives Claude the link.

Ask "what's the status of my app?" at any point, or "show me the deploy logs" if something failed.

Dev and production

Every app has a dev copy (your-app-dev.anddeploy.app) and production (your-app.anddeploy.app), each with its own database, keys and secrets. Pushes only ever update dev.

To go live, say "deploy it to production" or click Deploy to production on the app's page in the dashboard. Production deploys the version that's on dev, after a backup of the production database if the version changes the schema. Production is held back if the database check finds a table that anyone could read or change.

Earlier versions are kept. To go back, ask Claude to deploy an earlier version, for example "deploy v3 to production".

Database

Each environment has its own Postgres 18 database, compatible with Supabase. Use @supabase/supabase-js with the URL and publishable key from the app's Database tab (Claude reads them from &Deploy for you).

• Changes go in supabase/migrations/<timestamp>_<name>.sql. Each runs once per environment, in order, and is rolled back completely if it fails. Don't edit a migration that already ran; add a new one.
• Every new table is private (row level security is on). Add policies to allow access, e.g. create policy "own rows" on todos for all to authenticated using (user_id = auth.uid());
• The database check lists problems in plain English with a fix for each. Critical ones pause production deploys.
• The secret key bypasses those rules. It's never put in browser code, and pushes containing it are rejected.

Logins

Apps get sign-up and sign-in through Supabase Auth: email and password, magic links, and Google, GitHub, Apple or Microsoft once you give Claude that provider's keys (they're stored as encrypted secrets). People who sign in to your app are separate from your &Deploy account, and they're who's counted as "people a month".

Files

Store uploads with supabase-js storage. Files can be public, or private and shared through expiring links. File storage counts toward your size's Files limit.

Domains

Ask Claude to "use bookings.acme.com as the address". You'll get two DNS records to add where your domain is managed: a CNAME pointing at your app, and a TXT record that proves you own the domain. &Deploy checks every couple of minutes and sets up HTTPS automatically once they're in place. Custom domains need a paid size.

Email, scheduled jobs and workflows

• Email sends from your app's own address at your-app.anddeploy.app, already set up, or from your own domain after adding its DNS records.
• Scheduled jobs call a page of your app on a schedule, as often as once a minute. Each call is signed so your app can check it really came from &Deploy.
• Workflows chain simple steps: call your app, wait, send an email.

&Bridge

If an app needs an internal company system, such as a database or an internal API, ask Claude to request it. Claude describes what's needed and why; a workspace admin reviews it on the &Bridge page and approves it for specific apps. Approval gives IT a one-time token for the &Bridge agent, which runs inside the company network and only connects outward. Revoking cuts access off immediately.

Limits

Claude's tools

These are the tools Claude gets when you connect. You don't call them yourself; they're listed so you know what Claude can and can't do.