Cursor can publish the app it builds. The publish button still matters.

Build Live Apps takes a Cursor cloud agent from a prompt to a hosted web app. Paid access, sharing settings and a human publish decision are the practical limits.

Conceptual draft app and database pass through a review and human publish button to a hosted app with two linked users; no product screen is shown. — AI-generated editorial illustration of Cursor's documented build, review and publish path. Conceptual, not a product screenshot or evidence that an app passed a security audit.

The 30-second bite

Cursor's November 5 Build Live Apps release can take a cloud-agent project through hosting to a live link, but publication still requires a person's choice.
Access requires a paid plan with cloud agents; the current individual Premium listing is $30 a month.
Team sharing and public sharing are different settings. Public access is disabled by default on Teams and Enterprise.
Cursor's publish checks can catch specified issues, but LLMBites did not test them or the app's permissions.

A live link is now part of the build

Cursor's November 5 Build Live Apps release aims to take an idea beyond generated code: a cloud agent can prepare a web app, provision hosting and return a link after publication. For someone making a small team tool, that removes some separate setup work. The important condition is that the agent does not silently put its draft on the public web. Cursor says the person previews the app, chooses a URL and explicitly publishes it after the applicable checks or permitted review exception.

Think of an internal event-registration tool. A prompt might describe the form and who needs the results, but a usable app also needs somewhere to run, perhaps a database, and a decision about who may open it. Build Live Apps joins those steps in one flow. This is an illustrative use case, not an app LLMBites built or a claim that every prompt yields a production-ready result.

Sources: [1] [2]

Who can try it

Cursor says Apps is available on paid plans that have cloud agents enabled, and its docs specify that the feature is not supported by a local agent. The current individual pricing page lists cloud agents under Premium at $30 a month; the $8 Plus listing does not include them. That is a more useful access test than the broad phrase 'available on paid plans.' Someone on a managed team should also check whether their administrator has enabled the relevant cloud-agent and Apps settings.

Cursor describes building from a new project or an existing GitHub repository, with Cursor Origin another supported source. The company says GitLab support is still planned. The announcement and documentation describe availability, not the cost or operational fit of every resulting app. The listed subscription price excludes possible taxes and separately billed third-party model use; teams planning significant traffic or storage should confirm the applicable hosting terms before committing to this path.

Sources: [1] [2] [3] [4]

Building, publishing and sharing are three decisions

In Cursor's documented flow, the cloud agent scaffolds the application and can provision Postgres if it needs a database. It can set up sign-in and request secrets for external connections. After a preview, the user chooses to publish. A live link then exists, but the link's audience is a separate setting: invited people, the signed-in team, or, where allowed, the public. Those choices should be made deliberately before data is entered.

For Teams and Enterprise, public sharing starts disabled and an administrator can turn it on. Individual-plan users can make an app public. A team link therefore should not be interpreted as a universal promise that no one else can ever get access, nor should a public link be mistaken for an invitation-only workspace. Check the actual visibility setting and the data behind the page each time an app is published or republished.

Sources: [1] [2]

A security gate is not a full app review

Cursor's docs describe four checks that always run before publishing: they address secrets in app files, credential files, .env files and source maps. An additional AI review looks for serious issues. Admins can approve some publishes blocked by that review, but not specified malicious-code or credential findings. These controls matter, especially when a prompt-built app connects to other systems. They are still checks of particular failure modes, not evidence that every generated access rule, query or business process is correct.

TechRepublic raises a concrete concern: automated checks are not a substitute for checking whether one signed-in user can see another user's records. Its article is independent editorial analysis of Cursor's announcement, not a reported hands-on audit. For the example event tool, a sensible pre-share check would use two accounts with different roles and verify what each can read, change and export. That is a proposed review step, not one LLMBites ran.

Sources: [2] [4]

Start with a small, reversible job

A first app should be simple enough that someone can inspect its behavior. An event signup with sample data is easier to evaluate than a payroll workflow or customer-record portal. Before adding real information, write down who should be able to open the app, which records each role should see, and what a successful submission changes. Then compare the preview and published version against those expectations. This is our suggested evaluation framework, not Cursor's certification process.

External connections deserve their own checkpoint. Cursor says it can ask for secrets when an app needs to reach resources such as a data warehouse, and its docs say an agent does not see the values of those secrets. Even so, decide what the connection can reach and whether the app needs write access at all. A convenient integration should not turn an experimental form into a broad route to sensitive systems.

Sources: [2] [4]

What the launch does not establish

The release joins coding and deployment in a shorter path, but LLMBites did not build or test an app, measure reliability, or audit Cursor's security checks. TechRepublic likewise bases its feature account on Cursor's description and offers a separate risk analysis. Cursor's own Apps documentation says hosting is separate from its services and provided as-is. A published link demonstrates deployment, not that the app is suitable for a regulated or high-stakes workload.

The useful question is therefore not simply 'Can AI make an app?' It is 'Can I identify its users, permissions, data, costs and owner before I share it?' Build Live Apps may reduce the work of standing up an internal tool. The review that makes that tool appropriate for a real workplace still belongs to the people responsible for the data and the decision to publish.

Sources: [1] [2] [4]

Why this matters

The shift from generated code to a hosted, shareable app makes a prompt more consequential. A short build process is useful only when the owner can still understand access, data and the decision to publish.

This is source-based reporting, not a hands-on app build or security audit. The independent article offers analysis of Cursor's announcement, not independent testing. Availability, pricing and settings were checked November 6, 2026 and can change.

Sources & reporting

AI-assisted research and drafting. The writing agent read Cursor's dated announcement, Apps documentation and pricing page, plus TechRepublic's separate analysis. The sources are two origin groups; TechRepublic does not independently reproduce the feature. LLMBites did not use Build Live Apps, test its security checks or interview users. The decision framework and example are our analysis. Automated editorial and visual checks were performed by the writing agent; this article did not receive pre-publication human or independent editorial review. Automated editorial and visual checks were performed by the writing agent; this article did not receive pre-publication human or independent editorial review.

Spot a mistake? Request a correction.