# Run a Cloud app

> How a Cloud app runs on Playcode - two computers, what a publish copies, where the data lives, sleep and wake, and what it costs.
> Source: https://playcode.io/docs/publish/cloud-apps - last reviewed 2026-10-09.

A Cloud app runs on computers that Playcode operates: a development computer, where you and the agent build, and a production computer, which serves the published app. Each publish sends your latest code to production, and production keeps its own database and files.

## Two computers

| | Development | Production |
|---|---|---|
| What it does | Runs the preview, the terminal and the agent's work | Serves the published app at its address |
| When it exists | From the moment the project becomes a Cloud project | From the first publish |
| When it sleeps | After 10 minutes of quiet, and after 4 hours without you or the agent in the project | After 10 minutes of quiet, unless you change it |
| What wakes it | Opening the project, or the agent's work | A visitor |
| Its own | Secrets, checkpoints, logs | Secrets, checkpoints, logs |

The app is a full stack: pages, a backend, a database, stored files and background jobs. A new Cloud project starts with a SQLite database file; Postgres and Redis are available when the app needs them.

## What a publish does

The first publish copies the whole development computer to make the production computer: code, installed packages, database and files.

Every later publish sends only the code. Production first saves a checkpoint of itself (**Saving a backup**), takes the code (**Pushing your changes**), installs, applies database changes, builds and restarts the app (**Building & publishing**), then checks that the address answers (**Final checks**). If a later publish fails, production goes back to the previous version of the code: "We rolled back to your previous version, so your site stays up." Database changes that the failed publish already applied stay.

## Where the data lives

The database and uploaded files live on each computer's disk. After the first publish, production keeps its own data: a publish never copies the development database over it.

Files the code history ignores do not travel with a publish either, like `.env.local`, `data/` and `uploads/`. Put the values the app needs in **Settings**, **Secrets**, under **Production**. See [Secrets and environment](/docs/publish/secrets-and-environment).

To keep a copy of the database and files at a point in time, save a checkpoint. See [Snapshots and rollback](/docs/publish/snapshots-and-rollback).

## Sleep and wake

A sleeping computer runs nothing: a visitor wakes the production computer, and background work waits until then. **Settings**, **Computer** shows how many quiet minutes production waits before it sleeps; choose **Change** to ask the agent for another value. **Always on** keeps it awake around the clock. A schedule can wake it to run a command at set times.

## What it costs

A Cloud app uses credits for the hours its computers are awake, the disk it stores, and traffic past the plan's allowance. **Settings**, **Computer** shows the size of the production computer and its prices; **Settings**, **Usage** shows what each app used. When the workspace's balance reaches zero, Playcode warns the workspace owner and later stops the Cloud computers. See [Bandwidth and limits](/docs/publish/bandwidth-and-limits) for the allowance and the timing.

## Limits

- Cloud apps need a Pro or Max plan. A workspace can have 3 on Pro and 10 on Max. Every Cloud project counts, published or not; archived ones do not.
- The production computer's disk has a size limit: see [Bandwidth and limits](/docs/publish/bandwidth-and-limits).
- Only the project's creator, or an Admin of the project or its workspace, can publish.
- To learn how a Cloud project differs from a static site, see [Browser and Cloud projects](/docs/build/browser-and-cloud-projects).