What Cursor Live Apps Handles and Where a Local Setup Still Wins
Most of my side projects did not die from a lack of code. They died somewhere between a working editor session and a URL a user could open. A first version from an AI tool takes seconds now. Turning that version into something running with a database, a login screen and a host takes an evening of provisioning, environment variables and runtime settings. Two of my own projects stalled exactly there.
That gap is what Cursor Live Apps targets. It adds a cloud-based full-stack hosting and delivery environment to Cursor's Cloud Agent. Before this, the Agent stopped at producing code. With Live Apps, it can use the built-in PostgreSQL database, user authentication and a cloud runtime, then hand back an online preview link.
I took a real requirement through the whole flow to see where the product holds and where it does not. Short version. Live Apps closes the distance between generated code and a shareable preview. For lightweight applications it is a reasonable default. As a production operations platform it is not there yet.
What Live Apps Adds to the Cloud Agent
Access requirements and current limits
Live Apps is a cloud workflow aimed at paying Cursor Cloud Agent users. It runs entirely in the cloud and is not available in local Agent mode, so nothing here replaces a local setup. A project can start from scratch inside the tool, or be connected from an existing Cursor Origin or GitHub repository. GitLab is not supported at the time of writing.
Once a project is handed over, the Cloud Agent walks the delivery pipeline in the background. It creates or pulls the code, configures the cloud runtime, connects PostgreSQL, sets up Cursor-based authentication, hosts the application and opens an interactive preview environment. Testing happens in that preview. Publishing is a manual click that produces a public link.
The documentation gap worth planning around
The official documentation does not yet give a complete list of supported frameworks, and it does not spell out hosting resource quotas or billing limits. That shapes how the tool should be used. My own rule is to keep it for small, early-stage projects that do not need a specially customised runtime, and to keep runtime-sensitive work elsewhere until those limits are documented.
Five Checks I Run Before Sharing a Link
I used a single requirement to walk the whole pipeline, an internal team tool with user login, task-list management and PostgreSQL storage. The Agent wrote the implementation, and each stage still needed review.
Stage one, project generation
Describe the tool in natural language and the Agent produces the application structure and basic pages. The interface is the least interesting part of the result. What I check first is whether the project starts cleanly, which frontend and backend frameworks were chosen, how database access is handled, and whether the core task-status transition logic is complete. If the code is going to be maintained later, the stack has to be legible on day one.
Stage two, environment configuration
Dependency installation scripts, startup commands and generated environment variables all get read at this point. A project that runs in the cloud and breaks locally usually does so because the two environments drifted apart. I look for pinned dependency versions, environment variables that are documented and traceable, and a documented path for adding third-party service keys by hand. The acceptance question is blunt. Could someone new take this over tomorrow and reproduce it locally from the documentation alone.
Local drift is a different problem from delivery, and it sits on the side of the workflow that an all-in-one AI development management tool such as ServBay covers, with services, databases, domains and SSL running on the developer's own machine.
Stage three, data integration
Earlier AI-generated prototypes kept data in frontend memory and lost it on refresh. This time the Agent configured PostgreSQL with a table schema, migration scripts and basic create, read, update and delete operations. Testing covers connection stability, whether re-running migrations throws errors, and the awkward inputs. I deleted tasks, changed statuses and typed invalid characters into fields to confirm that writes actually persisted and that bad input was rejected rather than stored.
Stage four, cloud preview and testing
With a preview link in hand, the work moves onto a real network. Login, reads and writes, page refreshes and error handling get exercised and compared against the local build. Access control takes most of the attention. An unauthenticated request straight to a protected URL should be blocked. Two different users' task records should stay separated. A dropped database connection should produce a readable message instead of a stack trace on screen.
Stage five, publishing
A working preview is not a finished application. Before clicking Publish, four things get checked by hand. The application points at the production database. Authentication has no test backdoors left enabled. Test data has been cleared. Neither the frontend code nor the API responses expose secrets or administrative endpoints. After publishing, the version, live URL and rollback procedure are recorded. That is the point where delivery counts as done.
Existing PHP and Node Projects
Most of my maintenance work sits in PHP and Node repositories that predate all of this. Moving them wholesale into Live Apps is not the plan. The trade is convenience against control, and the balance depends on the project.
What the cloud workflow removes
The initial setup of a database and a cloud runtime disappears, and authentication, hosting and code land in one workflow. For a small internal tool, a product prototype, or a friend who needs a first version online without learning cloud deployment, that removes a good part of the friction around a first launch.
What still belongs on a local setup
Complex business logic does. Stepping through intricate code, using an established PHP or Node toolchain, managing private packages and local services, reproducing an intermittent production bug, tuning database settings, handling SSL certificates and deployment details, all of that still runs better where I can see it. The foundations of long-term maintenance still want a local environment.
Three tests for sorting projects
Time to launch for a new project. I record how long the usual path takes, local setup, a provisioned server, a deploy, then compare it with the Live Apps flow. The manual steps around database, authentication and configuration are the ones that matter. If the cloud path cuts the time to a usable link substantially, early validation goes there.
Migration limits for an existing project. I connected a running Node project to see whether its system dependencies, custom startup commands, historical database migrations and third-party services came across intact. A missing system dependency or a failed migration is a stop signal. The project stays on its current local plus server arrangement.
Remaining manual security work. Inside the preview, authentication bypasses, other users' data, unexpected API parameters and exposed configuration all get probed. The useful output is the split between what the Agent already prevented and what needs a manual patch. One pass gives a realistic estimate of the review time a launch needs.
Where This Leaves the Workflow
What goes to Live Apps
For the next prototype, internal tool or MVP that needs to test market demand quickly, I would use Live Apps to skip the initial cloud setup, as long as the code already lives on GitHub or Cursor Origin. That answers a question I care about, which is how fast an idea reaches a link someone can click.
What stays away
Messy legacy PHP or Node codebases do not go there, and neither do projects that need close control over the runtime or the underlying database. The same applies to work that needs predictable long-term operating costs and clear resource limits, or production systems under strict compliance, audit or data-location requirements.
The question I actually evaluate
Judged on its own terms, the value of Live Apps is that generation, PostgreSQL, authentication, previews and hosting sit in one workflow. The question I ask when evaluating it is not whether the generated code looks elegant. It is whether the path from idea to first launch got shorter, whether environment configuration mistakes dropped, whether a project is easier to share for feedback, and whether there is enough visibility to validate the result before Publish gets clicked.
The split that works for me now keeps core business logic, deep debugging and hard-to-reproduce issues in my local environment, while the Cloud Agent handles first cloud configuration, sets up previews and runs the basic delivery checks. Final quality acceptance, and the decision to publish, stays manual.