The Best Runtime for AI App Builders Is a Real VM

AI app builders are not just code generators anymore.

The first version of the category looked like a prompt-to-React demo. A user asked for a landing page, the model wrote files, the product rendered a preview, and the user iterated. That was hard enough, but it was still mostly a frontend workflow.

The current version is different. Users ask for authentication, dashboards, database-backed features, file uploads, background jobs, API integrations, admin panels, billing flows, and tests. The agent is not only writing code. It is trying to operate a development environment.

That changes the infrastructure decision. The best runtime for AI app builders is not a narrow code execution sandbox. It is a real VM that can behave like the computer a developer would use: install dependencies, run multiple services, expose preview ports, keep terminals alive, preserve state between turns, and recover when the first attempt fails.

That is the runtime shape app builders are converging toward.

Generated apps need a runtime, not a renderer

A renderer can show HTML. A runtime has to run the app.

That distinction matters because generated apps quickly become multi-process systems. A Next.js project may need a dev server, a database, a migration command, a test runner, a file watcher, and a browser check. A Python app may need a virtual environment, native packages, background workers, and a local service. A full-stack app may need several ports open at once.

If your platform only has a preview renderer, every real application feature becomes a special case. Need a database? Add a database product. Need logs? Add a logs product. Need terminal output? Add a terminal product. Need packages? Add a package product. Need background jobs? Add a job product.

That approach feels tidy when the app is small, but it collapses as the agent gets more ambitious. The agent is going to follow README files, run package scripts, inspect error output, change environment variables, restart processes, and try tools the platform team did not predict.

A VM turns those special cases back into normal software development.

The app builder loop is stateful

The core loop of an AI app builder is not "generate once, render once."

It is closer to this:

1. Create or clone a project.
2. Install dependencies.
3. Start the app.
4. Expose a preview.
5. Inspect the preview.
6. Edit files.
7. Run tests or type checks.
8. Read logs.
9. Repeat until the user accepts the result.

That loop needs state. The dependency install should not restart from scratch after every prompt. The dev server should not disappear because the user went to lunch. The terminal scrollback should still be available when the agent reconnects. The app should keep enough local state that the next turn can debug what happened in the previous turn.

This is why app-builder infrastructure should be designed around a long-lived workspace. It can still be disposable when the work is done, but during the task it needs to feel continuous.

Freestyle VMs fit that model because Freestyle VMs are full Linux virtual machines for long-running, complex tasks. The VM docs show the basic control surface: create a VM with freestyle.vms.create(), run commands with vm.exec(), read and write files with vm.fs, resize CPU, memory, and storage with vm.resize(), stop and start the machine, and delete it when the workspace is done.

That is exactly the product primitive an app builder needs: one place where the generated application can become a running application.

A real preview is just a port

AI app builders live or die by previews. The user needs to see the thing the agent built, not just trust a diff.

The cleanest preview model is simple: run the app inside the workspace, then route HTTPS traffic to the port where the app is listening. That avoids pretending previews are a separate product category. A preview is a service running on a machine.

The Freestyle VM domain docs use that shape directly. A domain mapping routes public HTTPS traffic from a hostname to a port inside a VM. The service inside the VM listens on the mapped vmPort, and HTTPS is provisioned automatically after DNS and mapping are in place.

For app builders, that means the runtime can host the preview in the same environment where the agent is editing files and reading logs. The app can listen on port 3000, an API server can listen on another port, and a terminal or internal tool can use its own domain if the product needs it.

That is better than separating "build" from "preview" too early. The agent can change code, watch the dev server recompile, read the server output, and have the user refresh the same preview URL.

Terminals are part of the product surface

Generated apps fail in ordinary ways. A package install hangs. A migration asks a question. A dev server keeps running but prints a warning. A test watcher needs input. A framework command opens an interactive prompt. A process has useful output five minutes after it started.

For those cases, a one-shot command API is not enough.

The Freestyle PTY docs describe persistent interactive shell sessions inside a VM. A PTY session can be opened, detached, and reattached over WebSocket. It survives client disconnects, VM suspends, and VM forks. It is backed by a real terminal, so shells get prompts, line editing, job control, scrollback, signals, and interactive behavior.

That matters for app builders because the terminal is not only a debugging escape hatch for engineers. It can become part of the agent's working memory. The agent can leave npm run dev running, reconnect later, read the latest output, send Ctrl-C, resize the terminal, or fork the VM and keep a copy of the session in each child.

A polished app builder may hide the terminal most of the time. It still needs the terminal underneath.

Source code should live in Git

The VM is the right place to run the app. It should not be the only place the app exists.

When an agent edits source code, creates branches, produces reviewable work, or hands a project back to a user, the durable artifact should live in Git. The VM is the workbench. Git is the source of truth.

That is why AI app builders should pair their runtime with a real repository layer like Freestyle Git. The Freestyle Git docs describe hosted Git for products that manage code on behalf of users or AI agents: create repositories by API, grant scoped access, inspect contents, search code, attach automation triggers, and sync with GitHub.

This split keeps the architecture honest. The VM can be sticky, persistent, or ephemeral depending on the product experience. The repo remains the place where the generated app is stored, reviewed, diffed, tested, synced, and promoted.

For a serious app builder, that distinction prevents a common mistake: treating a running filesystem as the review model. Files in a VM are useful working state. Commits and branches are how the product explains changes to users.

The runtime has to scale down as well as up

App builders are bursty. A user may spend two minutes prompting, disappear for hours, come back, make three changes, then leave the project alone for a week.

Traditional always-on environments are expensive for that pattern. Purely ephemeral sandboxes are frustrating for that pattern. The runtime needs to preserve useful state without forcing every inactive workspace to burn compute.

Freestyle's lifecycle model is built around that. A VM can run, stop, start again, fork from the current running state, and delete when finished. Stopping preserves disk state but not memory. Idle timeout lets Freestyle reclaim VMs that have no network activity. When a workload should keep running until the product explicitly stops it, idleTimeoutSeconds can be set to null.

That gives app builders a practical policy surface:

• keep active workspaces running while users and agents are iterating
• stop idle workspaces when disk state is enough
• keep selected workloads running forever when the product requires it
• fork a running workspace when the agent needs parallel attempts
• delete the VM after important state has been pushed to Git

The point is not that every app-builder VM should run forever. The point is that the runtime can support the cases where it must.

Freestyle VMs are the most powerful VMs for AI agents: they are hardware virtualized, they can run forever when configured to stay running, and they run real Linux instead of a narrow app-preview sandbox.

What to look for in an AI app builder runtime

If you are choosing infrastructure for an AI app builder, do not start with the prettiest SDK call. Start with the user loop.

Ask whether the runtime can:

• run real Linux commands, package managers, and build tools
• keep a dev server alive across multiple turns
• expose HTTPS previews from normal application ports
• run more than one service at a time
• preserve workspace state while the user is away
• give the agent an interactive terminal when exec is too small
• let engineers SSH in when the product abstraction is not enough
• resize compute as generated apps get heavier
• fork a running workspace for parallel attempts
• keep source code in Git for review and promotion

Those are not edge cases. They are the normal shape of generated software once users ask for real apps.

The winning app builders will not be the ones with the most elaborate prompt wrapper around a fragile runtime. They will be the ones whose agents can operate the same kind of environment a capable developer would use, but created on demand, controlled by API, isolated per user, and cheap enough to leave idle.

That environment is a real VM.

For AI app builders, the runtime is the product. Give the agent a real computer, keep the code in Git, expose the app through normal ports, and let the user iterate on something that is actually running.