Run your deployment strategy, not a control plane.
TurboCI turns one YAML file into provisioned VPS fleets, private networking, rollout-safe clusters, and repeatable multi-cloud environments.
Download the Node.js buildDeployment graph
One config driving two clouds and a guarded rollout# Shared production shape
- deployment_name: my_app_hetzner
provider: hetzner
location: hil
services:
web:
instances: 3
clusters: 2
healthcheck:
cmd: curl http://localhost/health
test: OK
- deployment_name: my_app_aws
provider: aws
location: us-east-1
duplicate_deployment_name: my_app_hetzner # Inherit all configsRollout status
Safe modeEverything required to run the fleet, without dragging in a platform.
TurboCI keeps the surface area tight: one orchestrator, one config, and enough deployment machinery to handle real production traffic.
Process, container, or balancer
Run Any Workload
Default VPS, Docker, or NGINX load balancer. Pick the service type that fits. Run any command on any server, in any order.
One deployment shape, four providers
Multi-Cloud by Default
Deploy to Hetzner, AWS, GCP, or Azure. Use duplicate_deployment_name to mirror a full stack to another provider with a single config override.
Health checks gate every shift
Zero-Downtime Rollouts
Clusters are deployed sequentially. Each cluster must pass a health check before the next one starts, and before traffic is shifted. At least one cluster stays live throughout.
Private by default
Networking Done For You
Every deployment gets a private network and a relay server that acts as NAT gateway, distribution hub, and SSH entry point, automatically.
Config stays readable
One YAML, Everything
No Terraform modules, no Kubernetes manifests, no Helm charts. Just one simple YAML that defines your entire infrastructure.
Provision + deploy in one pass
VPS Orchestration
Provision servers, install dependencies, configure services, manage load balancers, all from one orchestrator.
One deploy file defines the fleet.
A TurboCI deployment carries the infrastructure shape, service topology, runtime commands, and rollout guards in one readable config.
# Add to your project root
- deployment_name: web_hetzner
provider: hetzner
location: ash
services:
web:
instances: 2
clusters: 3
dependencies:
turboci:
- bun
run:
start:
work_dir: /app
cmds:
- pm2 start "bun server.ts"
healthcheck:
cmd: curl http://localhost:3000/health
test: ok
- deployment_name: web_aws
provider: aws
location: us-east-1
duplicate_deployment_name: web_hetznerSetup stays flat
Add only the provider credentials you need. TurboCI detects the rest.
# Add to your environment or .env file
TURBOCI_HETZNER_API_KEY=your_key
TURBOCI_AWS_ACCESS_KEY=your_key
TURBOCI_AWS_SECRET_ACCESS_KEY=your_keyConfiguration that stays operationally small
The same file handles provider choice, runtime setup, deployment duplication, and rollout policy. The operational model stays close to the workload instead of fragmenting into separate stacks.
One source of truth
Provider choice, service shape, and rollout rules stay in the same file.
Topology comes along
Private networking, relay routing, and balancer wiring are all implied by the deployment model.
Cloning stays cheap
Duplicate one deployment into another cloud with an override instead of a rewrite.
Example
`instances: 2` plus `clusters: 3` means six servers in three guarded batches.
Each batch can be rebuilt, checked, and promoted independently. That gives you a predictable rollback boundary without introducing a second scheduler.
config file in TurboCI
manifests per cloud in Kubernetes
modules and resources in Terraform
Updates that behave like an operator with a steady hand.
TurboCI keeps at least one healthy cluster in rotation while the next one is provisioned, checked, and promoted.
Phase 1
Cluster A stays live
Traffic keeps flowing to healthy instances while the next cluster is prepared.
Phase 2
Cluster B updates in isolation
Provisioning, dependency installs, runtime hooks, and health checks happen before traffic moves.
Phase 3
Balancer shifts only after success
Once the health check passes, TurboCI adds the new cluster into rotation and continues.
Example
`instances: 2` plus `clusters: 3` means six servers in three guarded batches.
Each batch can be rebuilt, checked, and promoted independently. That gives you a predictable rollback boundary without introducing a second scheduler.
Health policy
promoted at a time
with 5-second spacing
Deployment sequence
Provision, prepare, run, and promote repeat in a fixed order. The rollout stays deterministic because the scheduler only advances after a healthy result.
Sequential by design
Instances update together inside a cluster, but clusters move one at a time.
Health check gated
Every cluster must pass its command-based health check before it can receive traffic.
Failure stops the rollout
If a cluster never becomes healthy, TurboCI halts the remaining steps and leaves live capacity untouched.
From repository to live fleet in three clean moves.
The workflow stays close to the application: define it, point TurboCI at your provider credentials, and let the orchestrator carry the rollout.
Model the deployment
Describe the provider, services, cluster counts, health checks, and runtime commands in one YAML file.
Load provider credentials
Set only the cloud credentials you actually need. TurboCI resolves the matching provider for each deployment.
Push one command
TurboCI provisions the fleet, syncs your code, executes the runtime steps, and shifts traffic cluster by cluster.
Control surface
Target, skip, and tear down without leaving the same CLI.
The same command surface handles full deploys, partial service updates, and selective teardown. No second toolchain needed.
The point is to ship infrastructure, not inherit a platform.
TurboCI sits in the gap between app deployment and infrastructure sprawl. It handles the operational mechanics without requiring a cluster platform or a cloud-specific resource graph.
config surface
major cloud targets
extra control planes
Operating stance
TurboCI collapses provisioning and rollout logic into one deployment model. You still ship machines and services, but without adopting a platform whose main job is abstracting those same machines.
| Comparison point | TurboCI | Kubernetes | Terraform |
|---|---|---|---|
| Infrastructure model | One concept: deployment -> VPS + private network | Pods, Services, Ingress, ConfigMaps, Secrets... | Provider-specific resources (EC2, VPC, ALB, RDS...) |
| Configuration | One YAML file | Multiple manifests + Helm charts | Dozens of .tf files + modules per provider |
| Networking | Automatic per deployment (NAT + routing built in) | Manual CNI, Services, and Ingress setup | Define VPCs, subnets, NAT gateways, and security groups |
| Multi-cloud | Native. Same config, any provider. | Complex federation, separate clusters | Rewrite modules per provider |
| Workload flexibility | Containers, Compose, or plain apps | Containers only | Infrastructure only |
| Load balancing | Built-in service type | Ingress controllers + cloud load balancers | AWS ALB, Hetzner LB, etc. |
Start small
Download TurboCI and ship the first deployment from one file.
Begin with the binary, keep the docs nearby, and only reach for the Node build if that fits your environment better.
Node.js buildLean config. Cross-platform. No platform sprawl.
$ turboci up
-> Private network ready
-> SSH keys registered
-> Provisioning 6 servers
-> Syncing files through relay
-> Installing dependencies
-> Preflight complete
-> Application started
-> Healthcheck passed
-> Load balancer updated
Deployed in 3m 47s