Cursor cloud agents now build, host and publish live apps
Cursor's cloud agents can scaffold a web app, provision Postgres and Cursor SSO, run security checks, then publish a shareable URL — without a separate hosting account.

On 5 November 2026, Cursor announced "Build Live Apps in Cursor": cloud agents can scaffold a web app, provision Postgres if needed, put auth behind Cursor SSO, provision hosting, and hand back a shareable URL. The company frames the problem in one line — agents made writing code easier, but most apps never leave localhost (changelog).
The same flow is documented in Cursor's Apps docs. Coverage on The New Stack (6 November 2026) notes that Vercel said on X the feature is built on Vercel for Platforms — Cursor's own changelog does not name the host.
How it works
You start by kicking off a cloud agent and telling it explicitly that you want to build an app. Local agents are not supported (docs).
From there, Cursor (changelog, docs):
- scaffolds the web app;
- spins up a Postgres database if the app needs one;
- sets authentication behind Cursor SSO for private and team apps;
- provisions hosting in a dedicated, isolated account per team or individual;
- asks for secrets when the app must connect to your systems (for example a data warehouse) — the agent never sees the secret values.
When the app is ready, Cursor shows a preview tray. To publish, you pick a unique domain/URL. Cursor runs deterministic and agentic security checks; nothing goes live until those checks pass and you explicitly publish (docs).
You can deploy from a new repo (created on Cursor Origin) or from an existing GitHub repository. GitLab support is listed as coming soon (changelog).
Security checks before publish
Four checks always run before every publish, even if the AI security review is turned off (docs):
- block secrets written in app files;
- block credential files (private keys, service-account keys, auth-token files);
- never publish
.envfiles; - never publish source maps.
On top of that, an AI security review reads the app's files and can block serious issues. Team admins can add custom review rules in the Apps dashboard; custom rules can add constraints but cannot remove Cursor's built-in checks (docs).
Team admins can also see every app and secret on the team, unpublish any app, turn Apps on or off, allow or disallow public apps and API-key access, and approve publishes that the review blocked — except for malicious code, hardcoded secrets, or exposed credentials (docs).
Sharing and API access
After publish, you share with (docs):
- specific people or groups (Cursor sign-in);
- the entire team (Cursor sign-in);
- publicly, on individual plans.
Public sharing is disabled by default for Teams and Enterprise; a team admin can enable it. Disallowing public moves existing public apps back to team visibility (docs).
Private and team apps sit behind Cursor sign-in, which scripts cannot pass. Cursor API keys let Grok Bot, scripts or CI call an app as a signed-in user would, via the x-cursor-app-token header on every request — header only, no query parameter or cookie (docs).
Hosting under the hood
Cursor deploys each app in a dedicated account it creates for the team (or for the individual on an individual plan). Each hosting account is isolated from every other team's and user's (docs).
The New Stack reports that Vercel said on X the new functionality is built on Vercel for Platforms, so deploy works without creating a separate Vercel account or wiring hosting yourself. That hosting claim comes from New Stack's reporting of Vercel's post, not from Cursor's changelog.
Who it is for, and availability
Cursor lists internal examples already in use across sales, operations, legal, finance and engineering (changelog):
- ops tools (event registration, account assignments, desk seating);
- multimedia customer presentations (slides, video, interactive demos);
- training, enablement and onboarding for new hires;
- live sales dashboards and pipeline tools;
- portals to manage engineering services.
The feature is available on all paid plans with cloud agents enabled (changelog, docs).
Why it matters for vibe-coding and AI surfaces
The practical shift is the last mile: same cloud agent that writes the app can now stand up Postgres, Cursor SSO, isolated hosting and a publish gate with fixed secret/credential checks. For teams that already live in Cursor, that removes a separate hosting account and a manual deploy checklist for many internal tools — with the caveats Cursor itself publishes (cloud agent only, paid plan, admin controls for public share and API keys).
As more of that work moves into agent UIs and wait screens, advertisers will keep testing those surfaces the same way they test any new channel: small budget, clear creative, measure whether people actually engage. Idlen sits in that wait-time / native-ad layer for AI products; Cursor Live Apps is another reminder that the build-and-share loop is getting shorter, and that the surfaces where users wait for an agent will keep multiplying.
Concrete takeaways from Cursor's own materials: cloud agent only, Postgres + Cursor SSO + isolated hosting on publish, four always-on publish checks plus AI review, public share default-off for Teams/Enterprise, paid plans with cloud agents, and (via New Stack) Vercel for Platforms under the hood. Verify against the changelog and docs before you depend on any of it for production internal data.


