Deploy an app built with Cursor

Add one local MCP server to Cursor, paste one prompt, and Cursor deploys your app from its saved managed or GitHub source to Dev and Prod on ohmyho.st with Postgres and a live URL. Free gives 200 credits a UTC month; Paid is $10 a month for 1,000 credits shared by every project. Three static portfolio sites cost about 49.12 credits a month.

Paste this prompt

Open the repository in Cursor, open the agent chat and paste this. Cursor reads the two linked files, checks what is installed and signed in, and follows the get-started Skill before it touches anything.

Read https://ohmyho.st/llms.txt and https://ohmyho.st/skills/ohmyhost-get-started/SKILL.md. Connect this agent to ohmyho.st and develop and deploy this application using only the capabilities it needs. Read the existing project source first and follow the get-started Skill to reuse GitHub or managed versions for this workspace. After signing in, use the user and organization that whoami reports; never guess an account, organization or project ID. Follow the deployment Skill, keep my existing project decisions and verify the app.

"Only the capabilities it needs" is deliberate. A static Vite portfolio gets hosting and nothing else. A Next.js app with a database gets Postgres plus the secret names and callback URLs the plan reports. Cursor is told to keep the decisions already in the repository, not to replace them.

How to deploy with Cursor

1. Add the MCP server. Cursor reads .cursor/mcp.json in the project or ~/.cursor/mcp.json globally, and its MCP settings show the same list. Add a local stdio server named ohmyho with the command ohmyhost-mcp and the environment variable OHMYHOST_ENVIRONMENT=production; the token-free configuration to merge is served at ohmyho.st/mcp.json. Keep your other servers. If the command is not installed yet, the CLI and MCP guide has the current archive, and the Skill installs or upgrades it when the prompt runs.
2. Reload. A running server keeps the tool list it started with, so after an install or upgrade reload the connection in Cursor's MCP settings and confirm that the ohmyho server lists its tools (114 today).
3. Paste the prompt above into the agent chat. Cursor runs ohmyhost whoami and ohmyhost init --dry-run, reads the Skill and reports the state before it acts.
4. Confirm sign-in. With no session on the machine, Cursor posts a sign-in link and a short code. Open the link, check that the page shows the same code, sign in or sign up on that page, and tell Cursor you are done. It verifies with whoami instead of trusting the report. It never asks for a password, an email code or a token.
5. Review the plan. deployment_plan returns the exact commit, the build hold (about 16.87 credits for 14 reserved minutes, settled to the measured seconds), required secrets and effects. Confirm, and Cursor calls deployment_create.
6. Verify. Cursor polls operation_get, reads project_status, opens Dev through the reusable share link (or the clean URL, for public Dev) and tests a real read and write before it reports the URL. Ask it to promote once Dev works.

The whole path is the deployment Skill; Cursor follows it step by step.

These examples use the local stdio client. When the client exposes authenticated remote MCP, follow the get-started Skill for OAuth and explicit project/preview/publishing grants; discover its actual tools instead of assuming this local catalog. Private application values then use secret_input_request and its same-account portal link rather than local stdin. A new app developed entirely in chat starts with managed versions. This describes the supported transport contract, not a claim that a particular native chat UI has completed acceptance.

What Cursor does next

The sequence for a first deployment, in order (MCP tools unless marked CLI):

1. identity_get reads who is signed in and which organization is selected. With several workspaces Cursor uses organization_list and organization_use; with none it asks you for a name and calls organization_create.
2. Read project_context_get and source_get for an existing project and continue its current binding. For an unbound checkout, honor your source choice; a selected GitHub repository keeps GitHub, otherwise choose once between managed versions and GitHub setup.
3. Reuse the project, or call project_create with your region and data mode when you want a new app.
4. Save current files with source_publish for managed versions. For a selected GitHub source, use workspace github_status/github_connect when needed, then source_link for the authorized repository. Confirm source_get before planning.
5. deployment_plan for the exact saved managed or pushed GitHub commit, then your confirmation.
6. secret_set_command for each required secret. It returns a CLI command that reads the value from stdin, so the value never passes through the chat or the MCP server.
7. deployment_create with the reviewed plan and one saved idempotency key, then operation_get until the build finishes; deployment_logs if it fails.
8. project_status and project_dev_share_link_get to verify Dev.
9. promotion_plan and promotion_execute when you ask for Prod.

A later session starts with project_context_get, which returns status, DNS and mail next actions and the notes Cursor saved with project_notes_set. There is no deploy dashboard; the portal at app.ohmyho.st shows projects, credits, budgets and API tokens. The full catalog is at docs.ohmyho.st/mcp-tools.

What it asks you

Cursor asks for decisions, not credentials.

• Sign-in: open one link and check the code. Sign-up is open; there is no invitation and no waitlist.
• Region: US or EU, once, at project creation. US is the default. New projects provision databases, new files and builds in their selected region. Existing projects moved to US with their owner's authorization use US databases; recorded R2 locations remain unchanged. Read database_compute_get for actual database location. Transactional mail is processed in the US either way. The customer API cannot change region later.
• Data mode: optional, shared by default, or isolated Dev and Prod data areas, which the Skill recommends for production work. Isolated meters databases separately. An Owner can later review project_data_plan and confirm project_data_change; the platform copies no records or files and charges ordinary usage. Sharing keeps Prod and permanently deletes the separate Dev data, files and deployment; resetting isolated Dev deletes its area and deployment.
• Secrets: it hands you a command that reads the value from stdin. You paste the value into your terminal, never into the chat.
• Plans: every deployment, promotion, rollback and deletion is a plan you confirm before it executes.
• Money: it never starts a checkout without your request, and automatic recharge stays off unless the Owner turns it on.

A project ID in a prompt is context, not permission. Cursor checks its current authorization on every call.

Dev and Prod

Every project gets two environments on a platform hostname of the form three-words.check.omh.st. Dev is protected by default: an anonymous request gets a 404, and Cursor opens it through the reusable share link from project_dev_share_link_get. The link has no automatic expiry; rotating or revoking it cuts off old links and sessions on their next request, and public Dev is an explicit choice at project creation. Prod is public. Promotion moves the verified Dev artifact to Prod without a rebuild; with isolated data it applies schema migrations and copies no Dev rows, so existing Prod records survive. With isolated data you can also build a commit straight into Prod; a project whose Dev and Prod share a database deploys to Dev and promotes.

Each deployed script uses about 6.57 credits a month while it exists, and every deployment stages one that stays for rollback until cleanup. A customer-owned domain on Prod needs Paid, or on Free a project that shows the “Powered by ohmyho.st” flag, and an active Prod deployment (otherwise the domain tools return production_deployment_required). It uses about 32.86 credits a month, nothing while the flag shows; the domain Skill returns the exact DNS records, or authorizes Cloudflare DNS when you host the zone there. See environments and domains.

Safety

• Two steps for anything expensive or destructive: deployment_plan → deployment_create, promotion_plan → promotion_execute, rollback_plan → rollback_execute, delete_plan → delete_execute. Cursor cannot skip the plan.
• Secrets never enter the chat. secret_set_command returns a stdin-only CLI command, and the MCP server never sees the value. See secrets.
• Your auth stays yours. Better Auth and customer-owned WorkOS AuthKit are the verified integrations; the platform login is separate from your application's users, and the plan preserves whatever the repository already uses. See application auth.
• Budgets: a project can carry a monthly budget in continue or stop mode. Stop blocks new billable work at the limit; continue warns and keeps drawing from the shared balance. See budgets.
• Zero balance: a seven-day grace period starts, funded services keep running, and afterwards only unfunded services suspend. Export, diagnosis and buying credit stay available.
• Leaving: project_export_create returns a password-encrypted ZIP with a portable SQL dump, one accepted request per project in any rolling 24 hours, downloaded through a signed link valid 24 hours. SQL exports are free. See backups.
• Tokens: optional, created after interactive login, shown once, saved to a private env file, revocable with token_revoke.

What it costs

Free: 200 credits per UTC month. Paid: $10 a month for 1,000 credits per period, which also unlocks verified sender mail and a customer-owned domain. The domain also works on Free while the project shows the “Powered by ohmyho.st” flag, which waives domain credits on either plan. Monthly credits expire at period end. Paid-only top-ups carry over until downgrade to Free (100 credits per dollar up to $100, 125 per dollar above). Every project draws from the organization's one balance and there is no per-project base fee, which is the point for a portfolio.

About $0.49 of credit value at the standard rate.

Add a database and the numbers move. One active database hour at 512 MiB RAM costs 20.00 credits; the 256 MiB size available on Free costs 10.00 credits. Databases sleep after five idle minutes, with no active-RAM charge while asleep. Allocated disk and seven-day backups are included. Customer files and retained Worker scripts keep their separate rates. A quiet side project with a database costs about 19.80 credits a month. The small app example uses about 567.10 credits, including its requests, database activity and mail. Requests are 98.571429 credits per 1,000,000 requests; Workers bandwidth is not charged. Mail needs Paid and a verified mail domain, with 0.18 credits per 1 sent recipient and no monthly domain fee.

Where Vercel wins: Vercel Hobby costs $0 a month for one developer seat, and for a static portfolio with no database and no mail it is the cheaper answer. Vercel Pro is $20 a month before you add a database or a mail provider. ohmyho.st fits once a project needs Postgres, transactional mail or a domain, or once you run several small projects and want one balance instead of one plan each.

List prices checked on 2026-09-28 — Vercel pricing.

What we have tested, and what we have not

On October 27, 2026 we started the locally installed ohmyhost-mcp (version 0.1.36) over stdio from a script, sent initialize and tools/list, and read the answer. It listed identity_get, source_inspect, deployment_plan, deployment_create, deployment_logs, promotion_plan, promotion_execute and secret_set_command. The captured result is in our public repository.

That is a protocol check of the shared tool server, not a Cursor session. We have not published a transcript of Cursor deploying an app and make no claim about how Cursor's agent chat or its MCP settings screen behave. The same check applies to Claude Code and Codex.

FAQ

Is there a recorded Cursor deployment I can look at?

Not yet. When we record a real Cursor run with its commands and resulting address, it will be added here with its date.

Does Cursor need an API token?

No. Cursor runs ohmyhost login, posts a link and a code, and reuses that local session for the MCP server. A token is optional for automation: token_create after interactive login writes it once to a private env file, and OHMYHOST_TOKEN in the server's env block then wins over the saved login. Never paste a token into the chat.

Can I stay on Free for a portfolio?

Yes, when the sites are static or quiet. 200 credits a UTC month cover three static sites at about 49.12 credits, or one quiet project with a database at about 19.80 credits. Sender mail needs Paid; a customer-owned domain needs Paid or a project that shows the “Powered by ohmyho.st” flag, which waives domain credits. Free supports 256 MiB RAM with 500 MiB disk and seven-day backups included.

Where does the code come from?

From the project's current managed source or a GitHub repository you authorize. Managed versions save the filtered current files; GitHub uses commits you push. Containers remain unsupported. Supported frameworks are Astro, Next.js, Vite with React and TanStack Start. Cursor runs ohmyhost init --dry-run first and reports blockers before anything is provisioned.

Can I take my data and leave?

Yes. Ask Cursor for an export: project_export_create builds a password-encrypted ZIP with a portable SQL dump, one accepted request per project in any rolling 24 hours, downloaded through a signed link valid 24 hours. You choose the password and the archive is kept seven days. Files and source are not in it; source versions remain in the project's managed repository or selected GitHub repository.

Does my app's login change?

No. Your app keeps its own auth provider. Better Auth and customer-owned WorkOS AuthKit are the verified integrations; deployment_plan preserves whatever the repository already uses and reports the secret names and callback URLs it needs. The ohmyho.st login that Cursor uses is separate from your application's users.

Sources

• List prices checked on 2026-09-28 — Vercel pricing.

Deploy with Claude Code · Deploy with Codex · Cost breakdown · Six things that break when a vibe-coded app meets production