Describe your whole platform in one file — then run it like code

One file, full lifecycle

Declare your project, cluster and services once, then operate them end to end: init, validate, plan, apply, status and destroy all run against the same manifest. Infrastructure-as-code discipline, one command set.

core validate compose.yaml   # schema + compliance checks
core apply compose.yaml      # provision server-side, atomically
core status compose.yaml     # live health across regions

Preview before anything changes

A dry-run plan shows what already exists versus what will be created — organizations, projects, clusters, regions and services — alongside the projected monthly cost broken down by compute, memory, storage and egress. plan and cost change nothing; apply provisions.

core plan compose.yaml   # what changes, where
core cost compose.yaml   # projected monthly cost by component

Intelligent server-side placement

A placement engine chooses regions for you, scoring candidates against a weighted blend of availability, cost and latency and spreading workloads across backends for resilience. The same logic drives the CLI and the API, and the thin client never hardcodes where things run.

regions:
  mode: auto
  auto:
    strategy: { availability: 0.8, cost: 0.1, latency: 0.1 }

Autoscaling & GPU scheduling

Set min/max replicas, target CPU or memory, custom metrics and cooldowns per service — including scale-to-zero when idle and burst overflow under load. Request GPUs by count and model as part of the same workload spec.

autoscaling:
  enabled: true
  min_replicas: 0        # scale to zero when idle
  max_replicas: 50

Declarative residency & compliance

Pin workloads and data to an allowed set of countries and lock egress so traffic can't leave the jurisdictions you permit. Declare frameworks such as GDPR, PCI-DSS or HIPAA on a service and the manifest is validated against those rules — and blocked before it ships if it violates them.

placement:
  residency:
    require_countries: ["FR", "DE", "ES"]
controls: [GDPR, PCI-DSS]   # validated before apply

Health-aware failover, idempotent retries

Deployments are steered toward the healthiest option and away from backends that are over-committed or degraded. Retried and failed-over work is bounded and idempotency-keyed so nothing runs twice, and every deployment produces an audit trail of what ran and where.