Projects & setup
Create a project from a repo or from scratch — then watch the sandbox configure itself and prove it runs.
A project is your top-level workspace. Most projects connect to a git repo so every thread gets a sandbox cloned from that repo, and work lands as branches and pull requests. You can also create a project without a repository and connect GitHub later.
Ways to start
The New Project flow has a few paths, all producing the same kind of workspace once a repo is connected:
| Start from | What happens |
|---|---|
| Git URL | Paste any GitHub repo URL. Private repos authenticate with your connected GitHub account (GitHub App install or classic token). |
| Start fresh | Create the project with no repo yet — connect one when you're ready to open PRs. |
| Empty repo | A private GitHub repo is created for you, so there's always a target for pull requests. |
The sandbox sets itself up
You don't write a setup script. When a project is created (with a repo), a setup agent brings the environment up in a throwaway sandbox:
- Clones your repo and reads it to detect the right install and dev commands, the port, and any prerequisite services.
- Installs dependencies and starts the dev server.
- Brings up prerequisites — a database, cache, or queue your app needs — in Docker, cross-referenced against your secrets so it never double-provisions something you already configured.
Throughout, you can watch the clone progress, the build console, and the live desktop stream in real time.
It proves the app runs before finishing
Setup doesn't end at "the build passed." The agent proves the app actually serves: it waits for the dev server to answer, screenshots it, and records a short demo of the app running. Then the build parks — the sandbox stays live so you can click around the real app yourself — until you confirm or send feedback. Feedback kicks off a fix-and-re-record loop.
Setup never commits anything to your repo. A fresh clone and install must leave a clean working tree; leftover build artifacts fail the setup rather than getting snapshotted.
Fast threads after that
Once you confirm, the ready environment is snapshotted, and a small warm pool keeps a pre-configured sandbox paused and ready. New threads claim one and boot in seconds instead of re-running the whole setup — they just fast-forward to the latest code and rewrite secrets. Run config & snapshots covers how that state persists and updates itself.
Secrets
Secrets you provide are stored on the project and injected into every sandbox. Because any secret is visible to every sandbox, keep write-capable tokens out of project secrets — scope those per automation instead. Secrets & environment covers the full model, including per-sandbox overrides.