Cursor's Agent Now Deploys Apps With Postgres and SSO. Its Docs List No Hosting Price

• Book: Event-Driven Architecture Pocket Guide
• The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

Cursor's cloud agent can now put the app it just wrote on the internet. You ask the agent for an app. According to the November 5 changelog entry, it scaffolds the web app, provisions a Postgres database if the app needs one, puts sign-in behind Cursor SSO, sets up hosting, and hands you a live link on a domain you pick.

The New Stack's headline says Cursor "takes on Lovable and Replit with fully managed app deployment" (Lovable, Replit). The editor that writes your code now wants to run it too.

The changelog calls the feature Build Live Apps, and it only works from a cloud agent. The Apps docs say "this feature is not supported locally."

What the agent sets up

You start a cloud agent and tell it explicitly that you want to build an app (changelog). The Apps docs describe what happens next:

• A new project gets a new repository on Cursor Origin. You can also deploy an existing GitHub repository. GitLab and other git providers are listed as coming soon in the changelog.
• Each app runs in a dedicated hosting account for your team, or for you on an individual plan, isolated from other accounts.
• If the app needs a database, Cursor provisions Postgres automatically.
• If the app needs an outside system, such as a data warehouse, Cursor asks you for the secrets, and the agent never sees their values.
• A tray lets you preview the app and publish it. You choose the URL and can change it later.

The changelog says it's available on all paid plans with cloud agents enabled. On Cursor's pricing page, as of November 2026, cloud agents on individual plans start with the $30-a-month Premium plan. The $8 Plus plan doesn't include them.

The pitch is internal tools. AlphaSignal's write-up lists event registration, desk seating, sales-pipeline dashboards and engineering service portals as examples, and reports that Cursor's own sales, operations, legal, finance and engineering teams already use it.

What runs before anything goes live

Cursor's own line is short: "Nothing goes live until the checks pass and you explicitly publish the app" (changelog). The Apps docs list four checks that always run, even with the AI review switched off:

• Secrets written in app files, such as API keys or access tokens, block the publish.
• Credential files, such as private keys, service-account keys or files holding auth tokens, block it too.
• .env files are left out of the published app.
• Source maps are removed, so visitors can't read the original source.

On top of those, an AI security review reads the app's files for serious issues. Team admins can add custom instructions to that review, and those instructions can't remove the built-in checks.

Before a publish, fixed checks pull secrets and credential files out, and an AI review reads the rest.

The override is the part you need a policy for. Team admins can approve a publish that the review blocked, with three exceptions they can't wave through: malicious code, hardcoded secrets and exposed credentials. Anything else the AI review flags, an admin can ship anyway. Changes to admin settings are recorded in the audit log.

Neither the changelog nor the docs give a catch rate for the AI review. Treat it as a second reader, and keep the deterministic checks as the part you can reason about.

Who can open the app

The Apps docs define three visibility levels:

Public sharing is off by default on Teams and Enterprise, and a team admin can turn it on. Individual-plan users can share publicly, and a public app opens for anyone with the link, no Cursor sign-in needed. If an admin later disallows public apps, existing public apps move back to team visibility.

Scripts and bots need a key. Private and team apps block automated tools without one, and the key goes in the x-cursor-app-token header on every request. Query parameters and cookies aren't supported. Requests made with a key are marked as automated and attributed to the key.

One detail will bite cron jobs. A key that isn't allowed is treated like a user with no access and gets the sign-in redirect, not an error page. Check the status code:

# Domain and path are placeholders for your app.
code=$(curl -sS -o out.json -w '%{http_code}' \
  -H "x-cursor-app-token: $CURSOR_APP_KEY" \
  https://your-app.example/api/export)
[ "$code" = "200" ] || { echo "got $code"; exit 1; }

Without -L, curl doesn't follow a redirect, so a key without access stops the job with a non-200 code. The docs don't name the status code the sign-in redirect uses, which is why the check accepts 200 and nothing else.

What the docs don't say yet

Price. As of November 6, the changelog and the Apps docs list no hosting price, quota or usage limit for apps. The pricing page has no line for app hosting or Postgres. It does list "Code hosting via Origin" from Premium up. That line is about repositories. Running apps aren't on the page.

Terms. The Apps docs say hosting is provided "as is" and "as available," with no warranties about your apps. Apps can be suspended or removed for violating the terms or the Acceptable Use Policy, or for business, financial or legal reasons.

Data. The same page doesn't describe backups, regions, or how to export the Postgres database. Your code lives in a git repo. Nothing on the page says how your data leaves.

The agent itself. Cursor's cloud agent security docs say internet access is on by default and can be restricted to allowlisted domains, and Enterprise admins can lock that policy org-wide. Conversation state is kept indefinitely by default and can be deleted on demand. VM snapshots are deleted after 30 days of inactivity and can't be deleted on demand.

The app is live. The price, the backups and the way out of the database aren't on the page yet.

None of that sinks a desk-booking tool for one office. It does change the math for anything holding data you would need back.

Before you publish a team tool

1. Start from a GitHub repo if you want the code somewhere you already back up and can deploy elsewhere. Both GitHub and Cursor Origin are supported.
2. Keep the schema as migrations in the repo, so the database can be rebuilt on other infrastructure if you ever need to move.
3. Decide who on your team may approve a publish the AI review blocked, before the first one happens.
4. Restrict the cloud agent's network to an allowlist before it touches internal systems (security docs).
5. Give scripts their own keys and check status codes, as above.

I haven't run Build Live Apps myself, so this is a read of the changelog and the docs, not a field report.

Would you put a team tool on hosting with no published price yet, or does it stay on your own infrastructure until the docs fill in?

If this was useful

Internal tools rarely stay alone for long. The day your generated dashboard has to react to the data warehouse, a webhook or another team's service, you're dealing with retries, idempotency and messages that arrive twice, and that's what the Event-Driven Architecture Pocket Guide covers. It's one of 8 short books in the Pocket Guides series, on agents, RAG, prompts, observability, events, databases and system design: the whole series is here. I also build Hermes IDE, a free, source-available app for macOS, Windows and Linux that runs Claude Code, Codex and other CLI agents side by side, each in its own terminal, with its own branch and worktree if you want one (GitHub).