Takeaway: On Nov 5, 2026, Cursor shipped Build Live Apps: a cloud-agent workflow that scaffolds a web app, optionally provisions Postgres, puts private/team auth behind Cursor SSO, runs security checks, and deploys a shareable live URL. It is available on all paid plans with cloud agents enabled — not locally, and not on free. The pitch closes the familiar vibe-coding gap where writing code got cheap but shipping past localhost stayed hard. Same news week as Meta’s Conductor multi-agent acquisition and OpenAI’s Pierre/Codex git tooling move, but this is a product shipping story, not an M&A one.
Primary sources: Cursor’s Build Live Apps changelog and Cloud Agent Apps docs, with same-day analysis on DEV Community.
What Cursor shipped
Cursor’s changelog states the problem plainly: agents lowered the cost of writing code, but most apps and tools users build never leave localhost. Build Live Apps lets you describe what you want; Cursor handles scaffolding, database setup when needed, auth configuration, hosting, and a publish step that returns a live link after you pick a unique domain.
- Entry point: kick off a cloud agent and say explicitly that you want to build an app (docs: not supported locally; not an ambient “deploy everything” mode).
- Scaffold + infra: web app code; optional Postgres; authentication behind Cursor sign-in / SSO for private and team apps; dedicated hosting account isolated per team or individual.
- Secrets: if the app must reach your systems (e.g. a data warehouse), Cursor asks for the secrets it needs; the agent never sees the secret values. Team admins typically create team secrets in the Apps dashboard.
- Repos: new or existing repos on Cursor Origin and GitHub; GitLab support is coming soon.
- Availability: all paid plans with cloud agents enabled.
How publish and sharing work
After the agent prepares the app, Cursor shows a preview tray. Publishing is an explicit user action: you choose the app URL (changeable later), Cursor runs security checks, and only then do you get a live link. Nothing goes live before you choose to publish.
| Topic | What Cursor documents | Notes |
|---|---|---|
| Hosting | Dedicated account per team (or individual plan) | Isolated from other teams/users |
| Database | Postgres provisioned when the app needs one | Automatic when needed |
| Private / team auth | Behind Cursor sign-in | Share with people, groups, or whole team |
| Public sharing | Anyone with the link (individual plans) | Disabled by default for Teams/Enterprise; admin can enable |
| API access for bots/scripts | Cursor API key via x-cursor-app-token header | Header only — no query param or cookie |
| Admin controls | See all apps/secrets; custom review rules; approve blocked publishes; unpublish | Audit log for setting changes |
Security checks and guardrails
The publish gate is central. Docs describe four deterministic checks that always run before every publish, even if the broader security review is off: block secrets written in app files; block credential files (private keys, service-account keys, auth-token files); never publish .env files; never publish source maps. On top of those, an AI security review reads the app’s files and can block serious issues. Team admins can add custom instructions to the review prompt — they can add rules, but they cannot remove Cursor’s built-in checks.
Admins can also turn Apps on or off for the team, allow or disallow public apps (disallowing moves existing public apps back to team visibility), allow or disallow API keys opening apps, and approve publishes the review blocked — except for malicious code, hardcoded secrets, or exposed credentials. That design targets the failure mode of a well-meaning teammate shipping an internal tool with a hardcoded credential and a public URL.
Who this is for (and who it is not)
Cursor’s own internal examples span sales, operations, legal, finance, and engineering: event registration and desk seating, multimedia customer presentations, training/onboarding, live sales pipeline dashboards, and portals for engineering services. That list reads as internal tooling and microsites — not a replacement for a full production stack with custom networking or a non-Cursor identity system.
In the wider AI-coding market this week, Meta is folding Conductor’s multi-agent orchestration into its coding stack, OpenAI is bringing Pierre Computer’s git/review surface into Codex and previously pushed Pando as a git backend for monorepo agents, while open models like DeepSeek’s Super Agent coding track compete on agent capability. Build Live Apps is Cursor’s answer on the last mile: not a stronger coding model alone, but agent-owned deploy + auth + DB + share. It is also distinct from today’s consumer AI product posts (e.g. Claude Personal Finance) and from capability-heavy cyber launches like GPT-6 Cyber or research pipelines such as OpenAI’s Linux kernel LPE findings.
Practical checklist
- Plan check: Confirm a paid plan with cloud agents; free plans do not get Apps.
- Be explicit: Tell the cloud agent you want to build (or deploy) an app; local agents will not run this path.
- Start low-risk: Prefer an internal dashboard, event signup, or status page with real org users and no high-value secrets.
- Secrets hygiene: Use team/personal secrets in the Apps dashboard; verify the agent asks for secrets instead of inventing them.
- Publish gate test: Deliberately plant a known-bad pattern in a throwaway app and confirm the check blocks publish before you trust the gate.
- Admin visibility: Confirm an admin can list apps/secrets and unpublish after the first real deploy.
- Git provider: Expect Cursor Origin + GitHub today; plan separately if your org is GitLab-only until that lands.
- Ownership: Decide who owns the live app after ship — Cursor automates deploy, not long-term product ownership.
FAQ
Is Cursor Build Live Apps available on free plans?
No. Cursor’s changelog and docs say Apps is available on all paid plans with access to cloud agents. Free plans and local (non-cloud) agents are out of scope for this workflow.
Does the cloud agent automatically deploy every app I write?
No. You must kick off a cloud agent and explicitly say you want to build an app. Publishing is a separate, explicit step after preview and security checks. Nothing goes live until checks pass and you choose to publish.
What database and auth does Cursor set up?
If the app needs a database, Cursor provisions Postgres automatically. Private and team apps sit behind Cursor sign-in (SSO). Users on individual plans can also share apps publicly without Cursor auth. Public sharing is disabled by default for Teams and Enterprise unless an admin enables it.
What security checks run before publish?
Four always-on deterministic checks block secrets in app files, credential files, shipping .env files, and shipping source maps. An AI security review can also block serious issues. Team admins can add custom review rules but cannot remove Cursor’s built-in checks; they can unpublish any app and, with limits, approve blocked publishes.
Can scripts or Grok Bot call a private Cursor app?
Yes, via a Cursor API key sent in the x-cursor-app-token HTTP header on every request (header only — no query parameter or cookie). Personal keys open apps their owner can open; team keys open only team apps they are allowed to use. Public apps work with either key as for a normal visitor.
Leave a Reply
You must be logged in to post a comment.