Cursor Live Apps: What Ships, What Breaks

Cursor shipped Live Apps on November 5, 2026, because most agent-built tools never left localhost. A cloud agent can now scaffold the app, stand up Postgres, put sign-in behind Cursor SSO, and hand you a URL. That is a real product change. It is also a new place for the same production failures we already see when an agent holds infrastructure credentials.

This note is for founders and team leads about to put real data behind that link. It is not a feature tour. We cover what the release actually deploys, what the publish checks catch, what they do not, how sharing and API keys change the trust boundary, and the decision rule for when Cursor hosting is enough versus when the app needs a stack you own. The earlier incident — an agent deleting a production volume — is in Cursor deleted a production database. The wider repair path for a generated product is fix a vibe-coded app.

What Live Apps actually is

Cursor's changelog states the pitch in one paragraph: describe what you want, and Cursor handles the rest — build, database, auth, deploy. The Apps docs are more precise about the constraints.

You have to use a cloud agent. Local agents do not support the workflow. You have to say you want an app. You can start from scratch, which creates a repository on Cursor Origin, or deploy from an existing Cursor Origin or GitHub repo. GitLab is documented as coming soon. The feature is on all paid plans that have cloud agents.

When the agent is done, Cursor shows a tray: preview, then publish. You pick a URL, which you can change later. Publish runs security checks. If they fail, the agent lists what to fix and nothing goes live until you publish again after they pass. Cursor is explicit that you click publish. A green preview is not production.

What gets provisioned, from the same docs:

• Hosting. Each app lands in a dedicated account created for your team, or for you on an individual plan. Cursor says those accounts are isolated from every other team and user.
• Database. If the app needs one, Cursor provisions Postgres automatically.
• Auth. Private and team apps sit behind Cursor sign-in. Only people you share with, signed into Cursor, can open them. Individual plans can share publicly, and that path does not require Cursor auth.
• Secrets. When the app must talk to your warehouse or another system, Cursor prompts for the values. The docs say the agent never sees those values. Team admins create team secrets in the Apps dashboard; some users can add personal secrets.

Cursor's own examples are internal: event registration, desk seating, sales dashboards, onboarding, engineering-service portals. Tao Media's write-up of the launch repeats that list. Internal tools are the intended shape. Customer-facing products with payments, public sign-up, and a region you promised a buyer are a different shape, even if the agent can produce a URL for them.

Availability comes with a disclaimer that belongs in the same paragraph as the feature list. Cursor states it provides technology and tools, does not warrant your apps, and is not responsible for prompts or outputs. A subdomain or published app can be revoked. Hosting, the docs say, is separate from Cursor's services, provided as-is and as-available. That sentence is the difference between "we deployed" and "we run production."

What changed on November 5

Before this release, a Cursor cloud agent wrote code in a repo. You still chose a host, a database, and an auth provider. The gap between a working editor session and a URL someone else could open is where side projects died. A DEV walkthrough published November 9 describes that stall in the same words: generated code in seconds, an evening of provisioning after.

Live Apps collapses that evening into the agent turn. Postgres, Cursor SSO, and a host appear without a separate vendor account you opened by hand. For a weekly signup dashboard that five people on your Cursor team will open, that is the point. For a product that already has users, it is a new production surface sitting next to — not instead of — the questions in our security and ownership notes: who can read whose rows, where backups live, and whether you can leave.

The other change is who can ship. Changelog copy says anyone in the org can build tools and share them. Sales, ops, legal, and finance at Cursor are already doing it. That is a permission problem as much as a product one. An engineer who would not get a production deploy token can now publish a live app that talks to a warehouse secret an admin stored. The Apps dashboard is the control point: admins see every app and secret, can unpublish, can turn Apps off, can forbid public apps, and can forbid API keys opening apps. Changes go to an audit log. If you are not the admin, assume the admin can see what you shipped and can pull it.

The four publish checks, and the fifth

Cursor splits two layers. The Apps docs list four deterministic checks that are always on, even when the AI security review is turned off:

1. Block secrets written in app files. Publish stops if a file contains an API key or access token.
2. Block credential files. Private keys, service-account keys, files with auth tokens.
3. Never publish .env files. They are left out of what ships.
4. Never publish source maps. Visitors should not get original source.

On top of those, an AI security review reads the files and blocks serious issues. Team admins can add instructions to that prompt. They cannot remove the four built-in checks. Admins can approve a publish the review blocked, except for malicious code, hardcoded secrets, or exposed credentials.

That is a better default than most vibe-coding hosts shipped with in 2025. It is still a file scanner plus a model pass. It is not a second user logging in. It is not a restore test. It is not a region or backup policy. Tested at Work's November 8 note puts it cleanly: a good default, not a substitute for a publish gate you run yourself.

The fifth check is the one you run. Their three-item gate is the practical version: confirm SSO and that Postgres is the database for this app, not a leftover shared URL; plant a fake credential and confirm publish is blocked; open the live link as a second Cursor account that should not have access. If the fake key publishes, the review is not doing the job you were sold. If the second account sees data, Cursor sign-in was a front door, not a row policy.

What still breaks after a green publish

These are the failures that survive the four checks.

Sharing defaults are not the same on every plan. Teams and Enterprise: public sharing is disabled until an admin enables it. Disabling it later moves public apps back to team visibility. Individual plans: public apps are allowed, and they do not sit behind Cursor auth. A founder on an individual plan who "just wants a link for the beta" has published a public app. The publish checks do not ask whether that was the intent.

Cursor sign-in is not your product's authorization. Private apps require a Cursor account in the share list. That stops a random visitor. It does not mean user A's tasks are invisible to user B on the same team. Row-level rules are still your schema. Generated apps have been getting those wrong for a year; our Supabase RLS note is the same class of bug on a different host. The DEV walkthrough's preview tests are the right ones: an unauthenticated request to a protected URL should fail, and two users' rows should stay apart. Those tests are not in Cursor's four checks.

API keys punch a hole that looks like a user. Private and team apps block tools that cannot sign in. Cursor therefore lets you mint an API key for Grok Bot, scripts, and CI. Personal keys open whatever the owner can open. Team keys open only the team apps they were granted. The key goes in x-cursor-app-token on every request — not a query string, not a cookie. Requests are marked automated and identify the key, never a person. Admins can disallow API keys opening apps. If they do not, a key in a GitHub Action log is a signed-in colleague with no MFA prompt. Rotate it the way you would rotate any bearer token. Do not put it in the app files you just asked Cursor not to publish.

Secrets the agent does not see can still be the wrong secrets. Cursor prompts you for warehouse credentials and says the agent never reads the values. That is better than pasting sk_live_ into a component. It does not prove the app is talking to the database you think. Tested at Work's first check exists because teams connect the agent-created Postgres and a shared URL they already had. PocketOS lost production because a staging task used an id that was also production. Different vendor, same shape: one API call, nine seconds. Before the app holds customer rows, confirm the connection string in the Apps dashboard is the provisioned database for this app, and that the cloud agent's token cannot delete, resize, or snapshot anything else you run.

Backups, restore, region, and quotas are not in the launch story. Cursor documents isolation of hosting accounts. It does not, in the pages above, document backup retention, a restore drill, data region, or resource limits. The DEV piece flags the same documentation gap: no complete framework list, no published hosting quotas or billing limits. Until those exist in writing, treat Live Apps as a preview and internal-share host, not as the system you quote in a DPA. Cursor's as-is hosting clause is consistent with that reading.

The generated app still has the usual holes. Empty inputs, business logic that returns success, webhooks that never verify, admin routes with no check. Publish scans files for secrets. It does not walk the product as a second user with a declined card. When a generated app breaks in production still applies; only the URL issuer changed.

Sharing, public links, and who is on the other side

Cursor's sharing table is three rows: people you invite, the whole team, or public (anyone with the link). The interesting cases are the last two plus keys.

A team-wide app is convenient and wide. Everyone signed into your Cursor team can open it. That includes contractors, future hires, and whoever sits in a seat you forgot to revoke. For a desk-seating map, maybe. For a dashboard of pipeline or HR, share named people or a group, then review the list when someone leaves.

A public app on an individual plan is a website. No Cursor login. The four checks still run. They will not invent authentication you did not describe. If the prompt was "microsite with a signup form," you got a public form on Cursor's host. That may be what you wanted. It is also a personal-data processor you did not put in a vendor list.

Unpublish is the admin's kill switch. Use it. Cursor can also revoke a subdomain for policy or legal reasons. If the only copy of the tool is that subdomain, you do not own a product; you have a link. Keep the repo on GitHub or Origin, and know how you would run the same app on a host you pay for. That is the own your code question with a new vendor name on it.

When Live Apps is the right host — and when it is not

Use it when all of these are true:

• The audience is people who already have Cursor seats, or a public microsite with no sensitive data.
• The data is internal, replaceable, or a copy — not the only customer database.
• You can name who may open it, and an admin will unpublish it if that list is wrong.
• You have run the second-account test and a fake-secret publish test.
• You accept as-is hosting: the URL can go away, quotas may be unpublished, restore may not be a button you have practiced.

Leave Cursor hosting, and keep the repo, when any of these are true:

• Paying customers, cards, health, or HR data.
• A promised region, DPA, or backup window.
• A runtime, framework, or dependency Cursor has not documented.
• An agent that needs to talk to production infrastructure with a token that can delete.
• You cannot explain, in one sentence, where the data lives if Cursor suspends the app tomorrow.

The DEV author keeps messy PHP and Node, compliance work, and cost-predictable production off Live Apps, and uses it for prototypes and internal tools that already live on GitHub or Origin. That split is boring and correct. Speed to a link is the feature. Production is still auth, backups, and a host whose limits you can read.

What to check before the app holds real data

1. Cloud agent, paid plan, repo you control. Local agent will not publish. Confirm Origin or GitHub, not a chat transcript.
2. Read the destination. Hosting account, Postgres instance, Cursor SSO on, public sharing off unless you chose it.
3. Secrets in the dashboard, not in files. Team secrets for warehouse keys. Rotate anything that ever sat in a prompt or a committed file.
4. Fail the four checks on purpose once. A fake token in a file must block publish. If it does not, stop.
5. Second Cursor account. Not in the share list: no app. In the share list: not the first user's rows.
6. API keys off unless a script needs them. If on, header only, stored like a password, listed in the Apps dashboard, revocable.
7. Unauthenticated request to a "protected" URL. Should not return data. Should not return a stack trace.
8. Write down restore. If you cannot restore Postgres, the app is a demo. Cursor has not published that drill in the docs cited above; until it does, copy data you care about somewhere you have restored from.
9. Unpublish path. Who can click it. Who is on call if the link leaks.

If you cannot tick these, do not connect the warehouse. A weekly signup chart can wait a day. A leaked production dump cannot.

How Techtribe takes a Cursor Live App from here

On the scope call we open the live URL, the Apps dashboard, and the repo. We tell you whether Cursor hosting is enough for this audience, whether a second account can see data, and whether the honest next step is a publish gate on what you already have or a move onto a host and database you control. You leave with a fixed scope and a price. The call is free.

When the tool is internal and the holes are access rules, secrets, and a restore path, the work is a repair on your repo. When the same codebase has to become a product — your cloud, your auth, your backups, evals if it calls a model — that is a Production MVP or a Dedicated Team. Prices and inclusions are on the packages page.

Bring the live link, the share setting, and one account that should not see the data. If it can, that is the whole meeting. If it cannot, we look at backups, secrets, and whether you should still be on as-is hosting next month.