Cursor adds prompt-to-live web apps with hosting, sign-in and publishing controls
Build Live Apps is available on paid plans with cloud agents enabled. Users must explicitly publish, while team admins can override blocked releases.
Loading page…
Build Live Apps is available on paid plans with cloud agents enabled. Users must explicitly publish, while team admins can override blocked releases.
Listen to this story
Launched November 5, 2026, Cursor’s Build Live Apps turns a cloud-agent request into a hosted web app with sign-in and, when needed, a Postgres database. The key product shift is that teams can publish working internal tools without separately assembling deployment and authentication, while keeping release decisions and post-launch controls with administrators. It is available on paid plans with cloud agents enabled; security checks are a review step, not a guarantee that an app is free of vulnerabilities.
Apps can start from new or existing repositories on Cursor Origin and GitHub; GitLab support is described as coming soon.
Team apps can be shared with selected people, groups, or the whole team behind Cursor sign-in; individual-plan users can share publicly.
Cursor’s checks look for issues such as secrets in app files, but publication still requires an explicit user action.
A request in Cursor can now end with a web app colleagues can open, not just code on its creator’s computer. Cursor launched Build Live Apps on November 5, 2026, combining app generation with database setup, sign-in and hosting. The capability is available on all paid plans with cloud agents enabled, with an explicit publishing step before release.
The workflow starts by launching a cloud agent and explicitly telling it to build an app. Cursor says the agent creates the web app’s initial structure, provisions hosting and configures authentication through Cursor SSO—its single sign-on system. If the app needs a database, it can create one using Postgres.
If an app needs access to company systems, such as a data warehouse, Cursor asks for the secrets it needs: credentials that let the app connect. A connected tool can therefore require access information beyond the initial prompt.
Users can deploy from new or existing code repositories on Cursor Origin and GitHub. GitLab support is described as coming soon. At publication, the user chooses a unique domain, and Cursor supplies the live link.
Cursor’s security review combines deterministic checks, which follow fixed rules, with agentic checks performed by an AI agent. The company says these look for common problems, including secrets written into application files and exposed credentials—not a guarantee that passing makes an app free of security problems.
When a check fails, the agent identifies what needs fixing. The standard publishing path requires the checks to pass and the user to explicitly publish; generating the app does not automatically put it online.
Team administrators can see every team app and secret and add their own rules to the security review. They also control exceptions and removal after publication.
Published team apps can be shared with specific people, groups or the whole team, behind Cursor sign-in. Individual-plan users can also share apps publicly. Users can provision a Cursor API key, an access credential that lets a script or Grok Bot use the app.
Cursor says its own sales, operations, legal, finance and engineering staff are building internal apps. Examples include event registration, desk-seating tools, sales-pipeline dashboards and new-hire training. The company pitches the release as a way for anyone in an organization to build and share useful work tools.
Loading discussion...
Join the conversation
Explain when an exception would be justified.
Be the first to share a perspective or an experience.
Reader comments
Newest comments first. Replies stay oldest first.