Shared Platforms

A platform is one VPC and one ECS cluster shared by several Keel applications. Each tenant keeps its own load balancer, security groups, task roles, state, deployments, and teardown.

keel platform init --name acme --platform-region us-west-2
keel platform up --platform acme
keel platform show --platform acme

Join from an application's keel.yml:

platform: acme

The definition lives in the account registry rather than in a repository. platform export and platform apply -f provide a reviewable file form without creating a second source of truth. platform lock (Pro) refuses ad-hoc set changes until unlocked, while lock --off remains available regardless of licence state.

Ownership boundaries

The platform owns the VPC CIDR, availability zones, NAT strategy, private AWS endpoints, Container Insights setting, cluster, and any EC2 capacity fleet. A tenant that declares one of those keys is refused instead of having it silently ignored.

Tenants still decide where their own Fargate task interfaces go with networking.public_tasks, and they own application-level resources. A tenant's cluster name and capacity-provider name are always resolved from the platform record rather than derived from the app name.

Fargate and EC2 together

One ECS cluster can hold Fargate, Fargate Spot, and an EC2 capacity provider at the same time. Add a fleet to the platform:

keel platform set capacity.ec2.instance_types g5.xlarge,g5.2xlarge --platform acme
keel platform set capacity.ec2.max 8 --platform acme
keel platform up --platform acme

Then select it in a tenant without a top-level capacity: block:

services:
  gpu-worker:
    type: worker
    cpu: 4096
    memory: 16384
    gpu: 1
    capacity:
      fleet: ec2

The platform publishes the provider name, its subnet placement, and network mode. Bridge networking is refused for tenants because every task on an instance shares the host security group; on a multi-tenant fleet that would collapse network identity across applications.

Teardown safety

keel platform destroy refuses while any tenant remains. --force skips confirmation, not the tenant check. Once the platform is empty and the named VPC and cluster are confirmed, Keel generates teardown configuration without the ordinary prevent_destroy guards and removes the infrastructure.

A platform's own VPC and cluster keep those guards during every normal apply, so a CIDR edit or targeted apply cannot replace shared infrastructure accidentally.