Cursor can now build and host live apps, with a publish gate

Cursor now offers a route from a request for an internal tool to a hosted app with a shareable URL. Its November 5 release (opens in new tab) puts app scaffolding, an optional Postgres database, authentication and hosting inside the cloud-agent workflow. A user previews the result and explicitly publishes it after security checks, rather than receiving code that still needs a deployment setup.

That last step is the useful change. A sales dashboard or event-registration tool needs somewhere to run, somewhere to store data and a way to control access. Cursor is taking on those setup tasks. It is not giving the agent an unrestricted right to publish: the Apps documentation (opens in new tab) says nothing goes live before the user chooses to publish.

From a cloud-agent request to a live URL

Start a cloud agent and explicitly ask it to build an app. This feature is not supported by local agents (opens in new tab). Starting from scratch creates a repository on Cursor Origin; an existing GitHub repository can also be deployed. The release names Origin and GitHub as supported sources and says other git providers, including GitLab, are coming soon (opens in new tab). Cloud Agents’ broader source-control support should not be mistaken for the same deployment coverage.

Cursor prepares the app, provisions Postgres if it needs a database and supplies a preview-and-publish tray. At publication, the user picks the app’s URL, which can be changed later, and Cursor runs its security checks. A failed review produces issues to fix before trying again. Hosting runs in a dedicated account Cursor creates for the team or individual (opens in new tab), isolated from other teams’ and users’ hosting accounts.

Consider a small event-registration app: a form for attendees, a list for organizers and a count of remaining places. The organizer could ask a cloud agent to build it, inspect the preview and check that registration records persist. Cursor’s documented workflow supplies the database and hosting; the organizer still needs to decide whether attendees should be teammates or the public, and whether the app handles capacity correctly.

If it needs a connection to an existing system, Cursor prompts for the required secrets. The Apps docs say the agent never sees those secret values (opens in new tab); team secrets are usually created by an admin, with personal secrets available when permissions allow. That is a reason to use the secret-management path, not paste credentials into the build request.

Cursor says its own sales, operations, legal, finance and engineering staff use live apps for work including event registration, onboarding, customer presentations and pipeline tools (opens in new tab).

A link can be private or public

A shared URL does not by itself make an app public. Cursor provides three visibility settings (opens in new tab): invited people and groups, the whole team, or public access. Private and team apps require Cursor sign-in. Public apps can be opened by anyone with the link without Cursor authentication.

Individual plans can share publicly. On Teams and Enterprise, public sharing is disabled by default, but an admin can enable it (opens in new tab). An admin can also disallow public apps later, moving existing public apps back to team visibility. That makes the audience an administrative choice, not a property of possessing a hard-to-guess URL.

Scripts can access protected apps through a Cursor API key sent in the x-cursor-app-token header on every request. Personal keys inherit their owner’s app access; team keys reach only team apps explicitly granted to them (opens in new tab). Requests identify the key rather than impersonating a person. Admins can disallow key-based app access.

For a dashboard, this distinction matters: sharing it with finance need not expose it to every employee, while giving a script access does not require making the dashboard public. The application must still enforce any finer-grained permissions its own data needs.

What the security gate actually checks

The Apps security controls (opens in new tab) describe four checks that run before every publish, even when the AI security review is off:

• Block API keys or access tokens written into app files.
• Block credential files, including private keys and service-account keys.
• Exclude .env files from publication.
• Remove source maps from the published output.

On top of those checks, an AI security review reads the app’s files and blocks serious issues. Team admins can add instructions to the review prompt, but cannot remove the built-in checks through those instructions. That file review is the documented AI component of what Cursor’s launch calls “deterministic and agentic security checks” (opens in new tab). The Apps page does not describe an exhaustive live penetration-testing procedure.

The distinction is important for an app that holds customer records. Keeping a token out of a deployed file does not prove that one authorized user cannot read another user’s records. Passing the review is a publishing condition, not a complete security audit or validation of business logic.

Admins also have an override, with boundaries. They can approve publishes blocked by the review, except for malicious code, hardcoded secrets or exposed credentials (opens in new tab). They can see every app and secret on the team, unpublish apps and turn Apps off for the team. Changes to the documented settings are recorded in the team’s audit log. A team adopting this should decide who can override a finding before the first disputed review arrives.

Paid access is not an all-in hosting quote

Apps is available on paid plans with cloud-agent access (opens in new tab). The qualification matters. As of November 6, Cursor’s pricing table (opens in new tab) excludes Cloud Agents from Free and the $8-per-month Plus plan. Premium starts at $30 per month, with Super at $100 and Ultra at $200, before applicable taxes and fees. Teams starts at $30 per user per month; Enterprise is custom-priced. The Cloud Agents docs (opens in new tab) also include legacy paid plans among eligible plans.

Building the app consumes agent usage. Cursor says Cloud Agents draw on plan usage at the selected model’s rate (opens in new tab). On current subscriptions, Cursor-model usage draws from a weekly pool shared across Cursor and Grok; third-party models are paid separately from prepaid credit. Eligible third-party requests on Teams and Enterprise also carry a Cursor Token Rate (opens in new tab), subject to the documented exemptions. Older plans retain different usage arrangements.

Those are costs of agent work, not a published price for serving the finished app. As of November 6, the Apps page (opens in new tab) does not specify an app-hosting tariff, included bandwidth or database storage allowance. It also does not give an uptime commitment. A qualifying subscription should not be read as unlimited free hosting.

Who controls the app after publication?

The repository gives users a codebase to work with, while Cursor handles the hosted account, database provisioning and sign-in. The Apps documentation (opens in new tab) does not describe a complete migration procedure for moving that managed setup elsewhere, database backups or restores, or bring-your-own custom domains. Picking an app URL is not the same promise as controlling the underlying hosting account or a domain registration.

The Apps terms (opens in new tab) say hosting is provided “as is” and “as available,” separate from Cursor’s services, and that an app, subdomain or associated account can be revoked or suspended for the stated reasons. Teams should settle hosting cost, recovery and exit requirements before making a live app a dependency of daily work.

For a bounded internal tool, the release removes several tasks that otherwise follow code generation: provision a database, wire up sign-in and find a place to deploy. Start with a tool whose audience and data are easy to define. Before it becomes essential, verify access with an excluded user, test the business rules and establish how its records would be recovered if the hosted app disappeared.