Run the same application shape across multiple providers from one config.

TurboCI treats provider changes as deployment-level overrides instead of forcing a second config tree for each cloud.

1 parent

deployment can be duplicated into another cloud with targeted overrides

Selective rollout

target or skip one cloud without changing the shared configuration

duplication

yaml

- deployment_name: my_app_hetzner
  provider: hetzner
  location: ash

- deployment_name: my_app_aws
  provider: aws
  location: us-east-1
  duplicate_deployment_name: my_app_hetzner

Why multi-cloud

The deployment model stays constant while the provider changes.

High availability

If one provider has an outage, the same application can continue serving from the others.

Cost optimization

Use the cheaper provider in one region and the stronger instance family in another without changing the operating model.

Geographic fit

Place each deployment where the provider has the best regional footprint for your audience.

Reduced lock-in

The deployment shape stays portable instead of being rewritten around one provider's resource model.

Deployment duplication

`duplicate_deployment_name` is the main portability tool.

TurboCI clones the full configuration of another deployment, including services, run commands, health checks, and mappings. Anything declared in the new deployment overrides the inherited values.

multi-cloud-config

yaml

# .turboci/config.yaml
- deployment_name: my_app_hetzner
  provider: hetzner
  location: ash
  description: Hetzner production deployment
  services:
    web:
      instances: 2
      clusters: 2
      server_type: cpx21
      dir_mappings:
        - src: .
          dst: /app
      dependencies:
        turboci:
          - bun
      run:
        start:
          work_dir: /app
          cmds:
            - pm2 start "bun server.ts"
      healthcheck:
        cmd: curl http://localhost:3000/health
        test: "ok"
    load_balancer:
      type: load_balancer
      target_services:
        - service_name: web
          port: 3000

- deployment_name: my_app_aws
  provider: aws
  location: us-east-1
  description: AWS production deployment (mirrors Hetzner)
  duplicate_deployment_name: my_app_hetzner

Running turboci up deploys both targets in the same pass.

Credentials

Load credentials for each provider you plan to use

TurboCI chooses the correct provider key based on the `provider` field declared in each deployment.

.env

bash

TURBOCI_HETZNER_API_KEY=your_hetzner_key
TURBOCI_AWS_ACCESS_KEY=your_access_key_id
TURBOCI_AWS_SECRET_ACCESS_KEY=your_secret_key

Selective rollout

Target or skip one cloud without changing the base config

The targeting surface works cleanly with duplicated deployments.

targeting

bash

# Deploy only to Hetzner
turboci up -t "my_app_hetzner.*"

# Deploy only to AWS
turboci up -s "my_app_hetzner.*"

# Tear down one cloud and leave the other
turboci down -t my_app_hetzner

Per-cloud overrides

Inheritance does not prevent provider-specific tuning.

Override instance counts, sizes, or locations on the derived deployment while leaving the shared service definition intact.

override

yaml

- deployment_name: my_app_prod
  provider: hetzner
  location: ash
  services:
    web:
      instances: 3
      server_type: cpx31

- deployment_name: my_app_staging
  provider: hetzner
  location: fsn1
  duplicate_deployment_name: my_app_prod
  services:
    web:
      instances: 1
      server_type: cpx11

Next step

See full deployment shapes in context

The examples page collects real-world layouts that combine duplication, load balancing, container services, and staged environments.

Continue to examples