I Ran a Real Internal Tool Through Cursor Live Apps. Here Is the Part That Actually Helped
The last few side projects I gave up on did not die because I could not write the code. They died somewhere between a working local build and a link I could hand to another person.
That gap costs time in a very specific way. A database to pay for, an instance to provision, authentication to wire up, environment variables that drift between my laptop and the cloud runtime, then previews, acceptance testing and the release itself. Each step is small on its own. Together they are the reason a lot of my ideas never got a URL.
So when Cursor shipped Live Apps, I paid attention. It gives the Cloud Agent a hosted full stack delivery environment. Before this, the Agent stopped at helping me write code. Now it can use a built-in PostgreSQL database, Cursor based authentication and a cloud runtime to turn that code into a web application with an online preview link.
My assessment after running a real internal tool through it is narrow. Live Apps closes the distance between generated code and a shareable preview. I would not treat it as a production operations platform at this stage.
What This Cloud Workflow Requires
Who can use it, and what it connects to
Live Apps is a cloud workflow for paying Cursor Cloud Agent users. It runs entirely in the cloud and is not available in local Agent mode. I can build an application from scratch, or connect an existing Cursor Origin or GitHub repository. GitLab is not supported right now.
What the Agent handles after handoff
Once I hand over a project, the Agent works through delivery in the background. It creates or pulls the code, configures the cloud runtime, connects PostgreSQL, sets up Cursor based authentication, hosts the application and provides an interactive preview environment. After I finish testing in the preview, I click Publish myself and get a public link to share.
What the documentation does not settle
The official documentation does not yet give a complete list of supported frameworks, and it does not clearly specify hosting resource quotas or billing limits. My working rule is to use it only for small, early-stage projects that do not need a specially customised runtime.
A Real Internal Tool, Five Stages
To see how it behaves, I took a common requirement through the full delivery process. An internal team tool with user login, task list management and PostgreSQL storage. Even with the Agent doing the implementation, each of these five stages still needed my own review.
Stage one, project generation
I describe what I need to Cloud Agent in natural language, and it builds the application structure and basic pages quickly. I do not start with the interface. I first check whether the project starts correctly and whether I am comfortable with the frontend and backend frameworks it picked and the way it accesses the database. If I am going to maintain this later, I need to know the stack. I also check that the core task-status transition logic is complete.
Stage two, environment configuration
Once the project runs, I go through the dependency installation scripts, startup commands and environment variables it generated. When something works in the cloud but breaks locally, inconsistent environments are usually the reason. I look at whether dependency versions are pinned, whether environment variables are documented and traceable, and whether there is a way to configure third-party service keys manually. My acceptance question is simple. Could someone new take this over tomorrow and reproduce it locally by following the documentation.
Stage three, data integration
In earlier AI-generated prototypes, data lived in frontend memory and disappeared on refresh. This time the Agent configured PostgreSQL for me, including the table schema, database migration scripts and basic create, read, update and delete operations. I tested connection stability and whether rerunning migrations caused errors. I also deleted tasks, updated their status and entered invalid characters, to confirm that data was really persisted and that invalid operations were handled.
Stage four, cloud preview and testing
With the preview link in hand, I tested login, data reads and writes, page refreshes and error handling over a real network connection, then compared the results against the local build. My focus here was access control. Would an unauthenticated user be blocked if they typed a protected URL directly. Were two different users' task records kept apart. If the database connection dropped, did the page show a useful message or dump a stack trace onto the screen.
Stage five, publishing
A working preview does not mean the application is safe to share. Before clicking Publish, I check four things manually. The application points to the production database. Authentication has no test backdoors left on. Leftover test data is cleared. Neither the frontend code nor the API responses expose secrets or administrative endpoints. After publishing I record the version, the live URL and the rollback procedure. Only then do I call the delivery finished.
What Happens to My Existing PHP and Node Projects
The part I genuinely value
As someone who works mainly in PHP and Node, I have accumulated plenty of existing projects that still need maintenance. Rather than moving everything into Live Apps, I weighed the convenience of cloud automation against the control of a local environment.
The part I appreciate is that Live Apps removes the initial database and cloud environment setup, and puts authentication, hosting and code into one workflow. For a small internal tool, a product prototype, or helping a friend who has never deployed anything get a first version online, it removes most of the friction around the first launch.
The part that stays on my machine
Complex business logic is a different story. I still need my local development environment when I have to step through intricate logic, use my established PHP and Node toolchains, or manage private packages and local services. The same applies to reproducing an intermittent production bug, fine-tuning database settings, or handling SSL certificates and deployment details myself. For the foundations of long-term maintenance I want that control, and this side of my work still runs through ServBay, an AI development management tool I use to keep services, databases, domains and SSL on my own machine.
The three tests I apply before choosing
The first measures time to launch for a new project. I record how long it takes to set the environment up locally, provision a server and deploy the way I normally would, then compare that against the Live Apps workflow. I count the manual steps in database setup, authentication and environment configuration. If the cloud route substantially shortens the time to a usable link, I use it for early validation.
The second sets the migration limits for an existing project. I connected an existing Node project I already run, to see whether its system dependencies, custom startup commands, historical database migrations and third-party services moved across intact. When a required system dependency is missing or a migration fails, I stop instead of forcing it, and the project stays on its current local plus cloud server setup.
The third measures how much manual security work is left. In the preview environment I test for authentication bypasses, access to other users' data, unexpected API parameters and exposed sensitive configuration. I note which problems the Agent already prevented and which ones I have to patch in code myself. One pass gives me a realistic estimate of the time I need to set aside for manual checks before launch.
Where I Land
For my next prototype, internal tool or MVP meant to test demand quickly, I would use Live Apps to skip the initial cloud setup and get a link into users' hands sooner, provided the code is already on GitHub or Cursor Origin.
I would not currently put messy legacy PHP or Node codebases on it. Nor projects that need tight control over the runtime or the underlying database, nor cases where I need predictable long-term operating costs and clear resource limits, nor production systems with strict compliance, audit or data-location requirements.
The value I get from Cursor Live Apps is a connected workflow across code generation, PostgreSQL, authentication, previews and hosting. What I judge is not how elegant the generated code looks. I ask whether it shortens the time from a new idea to its first launch, whether it cuts environment configuration errors, whether it makes my projects easier to hand over for feedback, and whether it gives me enough visibility to validate the result before I click Publish.
The split that suits me right now is straightforward. Core business logic, deep debugging and reproducing difficult issues stay local. Cloud Agent handles the initial cloud configuration, the previews and the basic delivery checks. Final quality acceptance, and the decision to click Publish, stays with me.