Cursor Now Ships Your App, Not Just Your Code: What 'Build Live Apps' Actually Changes

Agents made writing code cheap. Shipping the result never got cheap with it. That is the gap Cursor...

Agents made writing code cheap. Shipping the result never got cheap with it. That is the gap Cursor is now trying to close: on November 5, 2026, it released "Build Live Apps in Cursor," a workflow that takes a described app from prompt to a hosted, shareable URL — database, auth, and hosting included.

The interesting question is not whether the demo works. It is what changes when the last mile of deployment becomes something an agent does for you, and where the new failure modes live.

What actually happens

The flow, per Cursor's changelog, is deliberately boring:

1. Kick off a cloud agent and say you want to build an app. You have to state it explicitly — this is not something that happens by accident while you are editing code.
2. The agent scaffolds the web app. It writes the application code, spins up a Postgres database if the app needs one, sets up authentication behind Cursor SSO, and provisions hosting. If the app needs to reach your own systems, like a data warehouse, the agent asks for the secrets it needs instead of guessing.
3. You pick a unique domain. Cursor hands back a live link.
4. You publish. Only after the security checks pass — and only when you explicitly publish — does anything go live.

Apps can be deployed from new or existing repos on Cursor Origin and GitHub. GitLab support is coming later. The capability is available on all paid plans with cloud agents enabled.

The publish gate is the real feature

The scaffolding is the part that demos well. The publish gate is the part that decides whether teams can actually use this.

When you publish, Cursor runs deterministic and agentic security checks designed to catch common issues — secrets written into app files, exposed credentials, that class of mistake. If a check fails, the agent tells you what it needs to fix. Nothing goes live until the checks pass and you explicitly publish.

Team admins get a second layer of control: they can see every app and secret on the team, add their own rules to the security review, approve publishes the review blocked, and unpublish any app.

That matters because the failure mode of "anyone can ship an app" is not bad code — it is a well-meaning colleague publishing an internal tool with a hardcoded credential and a public URL. The gate does not eliminate that risk, but it moves the check from "remember to review before deploying" to "deployment cannot happen until the check passes."

Sharing follows the same logic. Apps can be shared with specific people, groups, or the whole team, all behind Cursor sign-in. On individual plans, apps can also be shared publicly. You can provision a Cursor API key if a script or a bot needs to use your app.

Who this is actually for

Cursor's own examples are telling. Inside the company, people across sales, operations, legal, finance, and engineering are building internal apps: event registration and desk seating tools, multimedia presentations for customers, training and onboarding experiences, live sales dashboards, and portals for managing engineering services.

That list is the honest target market. This is not a replacement for your production stack. It is a replacement for the internal tool that currently lives as a half-finished repo on someone's laptop, or as a spreadsheet with a Slack bot duct-taped to it.

The pattern to watch: an internal tool used to need a developer, a repo, a deployment pipeline, and someone willing to own it in production. "Build Live Apps" compresses the middle three into a prompt. The remaining question is who owns the app after it ships — and the admin controls suggest Cursor knows that question is coming.

The limits, stated plainly

• Paid plans only, with cloud agents enabled. If you are on a free plan, this does not change your workflow.
• Postgres, SSO, and managed hosting. The deployment path fits web apps that work inside that model. Anything needing custom networking, a different identity system, or specialized infrastructure still needs a conventional pipeline.
• GitHub and Cursor Origin only, for now. GitLab support is announced but not shipped.
• You still have to ask for it. The agent builds an app only when you explicitly tell it to. There is no ambient "deploy everything I write" mode, which is a good thing.
• The security checks are a gate, not a guarantee. Deterministic checks catch known-bad patterns; agentic review adds judgment. Neither is a substitute for deciding, as a team, what is allowed to be public.

What to try first

If you have a paid plan with cloud agents, the lowest-risk first app is the one your team already wants but nobody will own: a small internal dashboard, a signup form for an event, a status page for a service. Something with real users inside your org and no secrets worth stealing.

Watch three things on that first attempt: whether the agent asks for the right secrets instead of inventing them, whether the publish check catches a deliberately planted mistake, and whether an admin can actually see and unpublish the app afterward. Those three behaviors tell you more about whether this fits your team than any demo.

The localhost graveyard was never a coding problem. It was a deployment-ownership problem. Cursor just automated the deployment half. The ownership half is now the interesting part — and it is still yours.

Source: Cursor changelog, "Build Live Apps in Cursor" (November 5, 2026) — https://cursor.com/changelog