Cursor Launches Live Apps: One-Click Shareable Links

Cursor is no longer just a tool for writing code locally. It can now deploy your project directly as an online app with a shareable link, putting tools that "only run on my machine" into your team's hands.

From Local to Online: What Is Cursor Live Apps

According to a YouTube video introducing Cursor's new feature, Cursor has launched Live Apps for cloud agents. You simply describe the tool you want, and Cursor automatically handles a series of steps that previously required manual configuration: scaffolding the web app, provisioning a Postgres database as needed, integrating Cursor login, running security checks, and finally deploying to your specified domain.

The entire flow can start from a new repository on Cursor Origin or connect to an existing GitHub repository. In other words, it compresses "writing code" and "getting code running on the public internet" into a single continuous action.

The significance of this change lies in the fact that a large number of internal small tools—scheduling charts, seating maps, simple information collection forms—used to remain on the developer's localhost because the cost of deployment and permission configuration was too high. Live Apps attempts to eliminate this barrier.

Cloud agents are a running form relative to local agents: the agent's reasoning, file read/write, and command execution happen in a remote environment hosted by Cursor rather than on your local machine. Because it has a continuously accessible runtime environment, it has the prerequisite to directly build web apps, connect to databases, and deploy services to the public internet. Local agents are limited by the development machine, and their output naturally stays on localhost; cloud agents can complete the action from generating code to providing services externally within the same pipeline. This also explains why Live Apps is only available to paid plans that include cloud agents—the feature depends on the runtime environment, not merely editor capabilities.

Who Can Use It: Paid Plans Only, Local Agents Not Supported

This capability has clear boundaries. According to the video, only paid plans that include cloud agents can use Live Apps; users who only use local agents cannot access the feature.

The deployment process is "security first" by default. The app will not go live until checks pass and you actively click publish. This design leaves final control in the user's hands rather than an automated pipeline.

For teams, this means you can first publish the app for internal validation, confirm everything is fine, and then expand the scope—rather than exposing it to the public internet the moment it goes live.

Security Checks and Team Governance: Gates Before Publishing

Before publishing, Live Apps runs a set of security checks focused on blocking several risk categories: secrets in app files, credential files, dotenv files, and source maps. These are exactly the common channels for sensitive information leakage—especially source maps, which may expose source code structure.

Team administrators also have a layer of governance: they can view every app within the team, add review rules, approve blocked releases, or directly unpublish. This mechanism brings AI-generated deployments under organization-level visibility.

Sharing scope is also tiered: you can share only with specific people, groups, or the entire team, and access goes through Cursor login. Individual plan users can choose public sharing.

A source map is a mapping file generated by front-end build tools, used to restore minified and obfuscated output back to the original source code for online troubleshooting. It is usually published alongside bundled files with a .map extension, and browser developer tools automatically read it to display the original code during debugging. The problem is that once a source map is publicly accessible, anyone can use it to reconstruct unminified source code, directory structure, and even leftover comments and API paths—effectively exposing engineering details. This is exactly why Live Apps includes it in the blocked items before publishing: it is not a resource required for running, but it can become an entry point for information leakage.

A dotenv file (such as .env) is a conventional file for storing environment variables and configuration. Database connection strings, third-party API keys, and signing secrets are usually written here, then injected into the process environment at runtime via a dotenv-style library. Its risk is that it is excluded from version control by default, yet it is extremely easy to carry along when packaging, copying directories, or uploading an entire repository. For automated deployment pipelines, if such files get mixed into build artifacts, it is equivalent to hanging credentials directly on the public internet. Therefore, the check logic treats dotenv files the same as credential files and blocks them before publishing, rather than relying on developers to remember to exclude them manually.

Getting Started Advice: Rehearse with an Internal Tool First

The first practical suggestion in the video is very pragmatic: start with an internal tool the team has long requested, such as a seating map or a simple information collection form, and publish it only to colleagues.

After publishing, the author suggests trying to break through the login authentication yourself to see whether the permission boundary actually works; if you find anything wrong, unpublish immediately. The video also candidly acknowledges that this feature has not yet been fully tested, so the first app should be treated as a rehearsal rather than a formal production delivery.

A Brief Assessment

What Live Apps fills is a long-missing link in the AI coding toolchain—from generating code to delivering a usable service. For scenarios like internal tools, its value may be greater than generating more complex code, because these needs are high-volume, short-lived, and permission-sensitive.

But "automatic deployment + automatic security checks" also means users need to trust the coverage of these checks. The video author's own suggestion to "rehearse first and actively test authentication" is a rational attitude. What you save is deployment time; what you should not save is vigilance about the exposure surface.