One Config, Many Servers

Your side project works. It’s deployed on one VPS, it has real HTTPS, you’re happy. Now someone actually depends on it, and the questions start piling up: where do I test changes before prod? Where does the second server go when the first one falls over? How do I point staging at a different database without duplicating the whole config?

Tako’s answer is: add a few lines to your tako.toml. One config file describes every environment you run and every server each environment lives on. Deploys know the difference, rolling updates happen in parallel, and rollback is a single command.

One config, many environments

Environments are declared under [envs.<name>]. Each gets its own routes, its own server list, and its own idle-scaling policy. Here’s a real-shaped tako.toml:

name = "myapp"

[build]
run = "bun run build"

[vars]
LOG_FORMAT = "json"

[vars.production]
API_URL = "https://api.myapp.com"

[vars.staging]
API_URL = "https://api.staging.myapp.com"

[envs.production]
route = "myapp.com"
servers = ["la", "nyc", "fra"]
idle_timeout = 600

[envs.staging]
route = "staging.myapp.com"
servers = ["staging"]
idle_timeout = 60

[vars] is the base, [vars.<env>] layers on top. Staging gets aggressive idle timeouts so it scales to zero almost immediately — no resources wasted on code nobody is looking at. Production gets longer warm windows and a three-server fleet.

The same server name can host multiple environments of the same app. staging.myapp.com and myapp.com could both live on one box if you want — Tako keeps them separated on disk under /opt/tako/apps/myapp/staging and /opt/tako/apps/myapp/production, with independent processes, secrets, and release histories.

Deploying to an environment

tako deploy defaults to production. To ship staging instead:

tako deploy --env staging

Tako builds the artifact once, then uploads and starts it on every server listed under [envs.staging].servers in parallel. Each server runs its own rolling update: start a new instance, wait for the SDK readiness signal, drain the old one, repeat. If fra falls behind because of network weather, la and nyc don’t wait for it — partial failures are reported at the end and successful servers stay on the new release.

Secrets follow the same model. They’re encrypted locally, keyed per environment, and pushed to each server over the management socket. Tako hashes the local secrets and asks each server whether they match before sending anything — if they do, the deploy skips the secrets payload entirely. New servers and drifted ones are caught automatically.

Scaling per environment, per server

Instance counts are runtime state, not config. You set them with tako scale:

# two warm instances on every production server
tako scale 2 --env production

# but LA is the big one — bump it to six
tako scale 6 --server la --env production

# staging stays on-demand (scale to zero)
tako scale 0 --env staging

These counts persist across deploys, rollbacks, and server restarts, stored on each server rather than baked into tako.toml. That means a production hotfix can’t accidentally undo last night’s scale-up decision.

Adding a region later

The nice thing about declaring servers per environment is that growing is just a list edit. Register the new server globally once:

tako servers add <host>

Add its name to [envs.production].servers, run tako deploy, and your app is now serving from the new region alongside the existing ones. Point the DNS record for myapp.com at all three IPs (or front them with Cloudflare and let smart routing pick the nearest), and you’ve got your own edge network running on commodity VPS boxes. No Kubernetes, no orchestrator, no control plane to babysit.

Tako is aiming to be more than a deploy tool — the same tako.toml that describes your fleet today will describe channels, queues, and workflows tomorrow. Environments and multi-server deploys are the floor, not the ceiling.

Read the deployment docs for the full story, or how Tako works for the architecture underneath.