stack orchestrates the native tools you'd install anyway — vfox, uv, Caddy, your own database binaries — from a single stack.toml. Plain child processes, a shared central store, no hypervisor idling in the background.
| No. | Kind | Installed by | Activated by stack |
|---|---|---|---|
| 01 | language | vfox / uv | Pinned per folder, resolved to a binary path |
| 02 | service | you, once | Started as a plain process, deduped by engine@version |
| 03 | tool | you, manually | Path registered, injected into the child PATH |
Every project referencing the same engine@version shares the one running instance — schema-isolated, never duplicated.
Name defaults to the folder, domain defaults to {name}.localhost — reserved, so it resolves with zero setup, no hosts-file edit.
Reference →Pinned per project. Binaries are shared across every project at that version; only the schema is per-project.
Reference →The one process that needs a stable domain — routed through Caddy's admin API, logged, torn down as a unit.
Reference →stack has no product to photograph, so this page frames its own terminal instead of a duotoned stock image — clone, activate, start, route, in that order, every time.
$ stack up
Loaded C:\Users\you\acme-api\stack.toml
project: acme-api
languages: ["php"]
services: ["mysql"]
php: C:\Users\you\.vfox\...\php.exe -> PHP 8.3.1 (cli)
service.mysql: already running, shared with other projects (pid 41232, port 3306)
run: php -S 127.0.0.1:52140 -t public (pid 41244, port 52140)
routed: http://acme-api.localhost -> 127.0.0.1:52140
"cd in. The right PHP, the right Node, the right Mongo. Nothing running you didn't ask for."
Install the binary, run stack setup once, and every project with a stack.toml activates itself the moment you cd in — no daemon to remember to start.