Cursor published its Live Apps changelog on November 5, 2026. The feature lets a Cursor cloud agent build a web app, add a Postgres database when the app needs one, put it behind Cursor SSO and deploy it to a URL you pick. Cursor’s own framing is blunt: most apps people build with agents “never make it off of localhost.”
Cursor Live Apps also move hosting, secret storage and a publish gate into Cursor itself. That shifts who can put a running app in front of colleagues, and which checks stand between an agent’s code and a live URL.
What Cursor Live Apps do
A Live App starts when you kick off a cloud agent and tell it explicitly that you want to build an app. Cursor’s Apps docs say the feature runs only on cloud agents and “is not supported locally.”
From there, Cursor’s changelog says the agent will:
- Scaffold the web app.
- Spin up a Postgres database if the app needs one.
- Set up authentication behind Cursor SSO.
- Provision hosting.
- Ask you for secrets when the app has to reach your own systems, such as a data warehouse.
You can start from scratch, which creates a new repository on Cursor Origin, or point Cursor at an existing GitHub repository (“Deploy this repo as an app”). Cursor says support for other git providers like GitLab is coming soon.
When the app is ready, Cursor shows a tray where you preview and publish it. At publish time you pick the app’s URL, which the docs say you can change later.
How hosting, database and secrets are set up
The Cursor Apps docs describe four parts:
| Part | What Cursor does |
|---|---|
| Hosting | Deploys each app in a dedicated account Cursor creates for your team (or for you on an individual plan), isolated from every other team and user |
| Database | Provisions a Postgres database automatically if the app needs one |
| Auth | Private and team apps sit behind Cursor sign-in; individual-plan users can share apps publicly without Cursor auth |
| Secrets | Prompts you for the secrets the app needs; the docs say “the agent never sees the values” |
Team secrets are usually created by a team admin in the Apps dashboard. Users with permission can add personal secrets.
The security checks before publish
Nothing goes live until the checks pass and you explicitly publish. Cursor’s docs list four deterministic checks that run before every publish, even when the AI security review is turned off:
- Block secrets written in app files. The publish stops if a file contains an API key or access token.
- Block credential files. The publish stops if it includes private keys, service-account keys or files with auth tokens.
- Never publish .env files.
.envfiles are left out of what ships. - Never publish source maps. 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 and blocks serious issues. If a check fails, the agent lists what it needs to fix; you tell it to fix them and publish again.
What team admins control
Team admins see every app and secret on the team and can unpublish any app. The Apps docs list these extra controls:
Admin controls in the Cursor Apps dashboard
- 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
- Add custom instructions to the AI security review (they can add rules, not remove built-in checks)
- Approve publishes the review blocked, except malicious code, hardcoded secrets or exposed credentials
Changes to these settings land in the team’s audit log. Public sharing is off by default on Teams and Enterprise.
Sharing and API access
After publish you can share an app with specific people or groups, with your whole team behind Cursor sign-in, or, on individual plans, publicly.
Scripts and bots can’t get through Cursor sign-in, so Cursor lets you provision an API key. The key goes in the x-cursor-app-token header on every request:
curl -H "x-cursor-app-token: $CURSOR_API_KEY" https://<your-app-url>The docs say the key only works as a header, with no query parameter or cookie option. Personal keys open the apps their owner can open; team keys open only the team apps they’ve been given. A key without access gets the sign-in redirect, and requests made with a key are marked as automated.
Availability and limits
Cursor says Live Apps are available on all paid plans with cloud agents enabled. The current limits:
- Cloud agents only; local agents can’t build Live Apps.
- Repos come from Cursor Origin or GitHub today. GitLab and other providers are listed as coming soon, with no date.
- Cursor hasn’t published pricing or resource limits for app hosting or the Postgres database in the changelog or the Apps docs.
If you already use Cursor for coding, see how it compares with other agents in our Claude Code vs Codex vs OpenCode vs Aider breakdown, or our guide to replacing Cursor with DeepSeek and open-source tools.
Conclusion
Cursor Live Apps turn a cloud agent session into a hosted, signed-in web app with a database and a publish gate. The four built-in checks block secrets, credential files, .env files and source maps, and admins can review, approve or unpublish. Before rolling it out, decide who on your team may publish, keep public sharing off unless you need it, and remember Cursor treats hosting as a separate, as-is service.
