Run config & snapshots
How darting.dev remembers the way your app installs and runs, and why new threads boot in seconds.
Project setup happens once. What it learns persists — as a run config and a snapshot — and that's what makes every thread after it start fast.
What setup learns
The setup agent doesn't ask you for commands. It reads the repo and works out how to run your app: the install command, the startup command, and the port. It brings up prerequisite services the app needs, and it proves the app actually serves before you confirm anything.
The run config
Those findings are recorded as the project's run config:
| Field | What it holds |
|---|---|
| Install command | How dependencies get installed on a fresh clone. |
| Startup command | A composite: prerequisites first, then any migration step, then the dev server. |
| Dev port | The port the app serves on. |
That config isn't a setup artifact you can forget about — it's live infrastructure. It's what the Open app button points at, and what the app health check in every thread measures against.
Snapshots and the warm pool
On confirm, the ready environment — repo, installed dependencies, running services — is snapshotted. A small warm pool then keeps pre-configured sandboxes paused and ready.
When you start a thread, it doesn't re-run setup. It claims a warm sandbox, fast-forwards to the latest code, rewrites secrets, and boots in seconds.
setup (once) ─▶ run config + snapshot
└─ warm pool ─▶ new thread: fast-forward code, rewrite secrets, boot
That's the mechanism behind the claim on Isolated sandboxes: parallel threads are cheap because none of them pays the setup cost.
The config is living
Apps change how they run. You add a migration step, swap package managers, move the dev server to another port — and a stale run config would mean every future thread boots wrong.
So the config updates itself. When an agent changes how the app installs or runs, it updates the run config as part of that work. Once the change reaches your default branch, the project re-snapshots with the new config baked in — deterministically, from the recorded config, with no second setup pass and no interview. Future threads boot already knowing the new way to run your app.
What this means for you
- A new thread is not a cold start. Dependencies are installed and the dev server is already coming up before the agent reads its first file.
- The environment follows
main. A build-system change lands like any other change — through a PR — and the snapshot catches up when it merges. - Environment work is reviewable. Because the run config changes inside a thread, it shows up in the diff you review before you commit the thread.
If a thread's app isn't serving, the health check is reading the run config's port and startup command — the fix belongs in the config, not in a one-off command you run by hand in the terminal.