What happened
Cursor announced Build Live Apps in a changelog dated November 5, 2026. The company describes the feature as a response to a practical gap: agents have reduced the cost of writing code, but many applications and tools users create do not move beyond localhost. Build Live Apps is intended to let a user build a live application directly in Cursor and share it by link.
The starting point is a Cursor cloud agent. A user tells the agent explicitly that they want to build an app. Cursor says the agent will scaffold the web application, provision a Postgres database when one is needed, configure authentication behind Cursor SSO, and provision hosting. If the app must connect to another system, such as a data warehouse, Cursor asks the user to supply the required secrets. At publication time, the user chooses a unique domain and Cursor returns a live link.
The feature can deploy applications from new or existing repositories in Cursor Origin and GitHub. Cursor says support for other Git providers, including GitLab, is coming soon. Its examples of internally built applications span operational tools for event registration, account assignments and desk seating; customer presentations that combine slides, video and interactive demonstrations; training and onboarding experiences; sales dashboards and pipeline tools; and portals for managing engineering services. These are examples from Cursor, not measured customer results or guarantees about what the system can build.
Cursor has also placed publishing behind checks and an explicit user action. It says it runs deterministic and agentic security checks to identify common problems, including secrets written into application files or exposed credentials. When a check fails, the agent tells the user what it needs to fix. Cursor says no application goes live until checks pass and a user explicitly publishes it. Team administrators can view every app and secret on the team, add their own rules to the security review, approve a publication blocked by review, and unpublish an app.
Once an app is published, a team can share it with selected people, groups or the entire team behind Cursor sign-in. Individual-plan users can also share applications publicly. Cursor says a user can provision a Cursor API key so that a script or Grok Bot can use the app. The capability is available on all paid plans where Cloud Agents are enabled. The changelog does not state separate hosting prices, usage quotas, deployment limits, or service-level commitments.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
This supports agent-ready software exposes capabilities. Cursor is packaging a bounded sequence of capabilities—scaffolding, database provisioning, authentication, hosting, review, publication and sharing—around an agent task. The product description does not establish whether those capabilities are composable outside Cursor, nor whether they work reliably across a wide range of repositories and organizational policies.
Why now
Cursor explicitly frames the release around the distance between cheaper code generation and a usable application that other people can access. Its answer is to place deployment and sharing inside the same cloud-agent flow as app creation. The source offers no further explanation of why the feature arrived on this date, and provides no adoption data for the underlying problem.
Why it matters
For teams building with AI, the meaningful output can now be a reachable tool rather than a codebase waiting for an engineer to run it, host it and configure access. That can shorten the path from a narrowly defined work problem to a trial internal service: a registration tool, a dashboard, an onboarding experience or a small operations portal.
The release also makes authorization visible in the workflow. A user must explicitly publish, while administrators can inspect apps and secrets, add review rules, intervene on blocked publication, and remove a deployed application. Those features make the product more relevant to teams than a one-click demo host. They do not remove the work of deciding which data an app may access, who may use it, or whether its generated code and dependencies meet the team's standards.
The distinction matters especially when an app connects to a data warehouse or another business system. Cursor will request secrets, but the source does not say how permissions should be scoped, how secrets are stored, or how an organization should validate the behavior of the generated application. The fastest path to a live link is useful only when it is paired with ownership of access, review and rollback.
What happens next
- Cursor adds support for at least one Git provider beyond Cursor Origin and GitHub. (6 months, 65%). Watch for: a changelog entry naming GitLab or another provider.
- Teams use Build Live Apps primarily for bounded internal workflows before broader production services. (12 months, 60%). Watch for: Cursor case studies that report deployment patterns, controls, or usage data.
Limits and uncertainty
This is a vendor changelog, not an independent test of the feature. Cursor does not report deployment success rates, development-time savings, security-check accuracy, false positives, or examples of vulnerabilities the checks fail to catch. “Deterministic and agentic security checks” is a product description rather than a complete account of their coverage.
The source also does not establish application reliability, hosting regions, performance characteristics, data retention, backup behavior, audit features, or pricing beyond paid-plan eligibility with Cloud Agents enabled. It does not specify quotas for databases, domains, public applications or API-key use. The stated ability for administrators to see apps and secrets does not explain the underlying permission model. GitLab support is described as forthcoming, but no delivery date is provided.
Skill to build now
Pick one low-risk internal workflow that currently lives in a spreadsheet, form or ad hoc script, and write its access boundary before asking an agent to build it. Specify the users who may open it, the systems it may connect to, the minimum data it needs, and the person authorized to publish or unpublish it. Then test the generated app with non-sensitive data and inspect every requested secret and permission. This turns Cursor's publish gate into a useful review step instead of treating deployment as the end of the task.
Reader takeaway
Build Live Apps extends Cursor Cloud Agents from producing code to producing a shareable deployed application, with database, SSO, hosting, review checks and an explicit publication step in the advertised flow. It is a plausible shortcut for bounded internal prototypes. Use it with the same discipline as any new application: verify code, permissions, secrets and the appropriateness of the data connection before sharing it.
Open question
How much of Cursor's stated security review can be customized to an organization's specific data-access and deployment policies, and what evidence will it provide when a generated application is approved for publication?