Multi-cloud — AWS, GCP, Yandex Cloud, Kubernetes
Same service definition deploys to AWS Lambda, ECS Fargate, GCP Cloud Run, GKE Autopilot, Yandex Cloud Serverless Containers, or self-hosted Kubernetes. Switch templates; the service stays the same.
Why this matters
The point of a multi-cloud abstraction isn’t to deploy to all clouds at once — it’s that you pick the right one for the workload and switch when you need to. SC services declare what they need (a container, a connection string, an outbound CNAME); the template you pick decides which cloud handles it.
For our flagship product Forge, this concretely means:
- Reasoning agents run on AWS Lambda — cheap, time-boxed, perfect for ~5-minute prompt sessions.
- Long-running runtime workers run on Fargate — no 15-minute Lambda cap.
- Marketing sites run on AWS S3 + CloudFront via
aws-static-website.
Same parent: forge/infra. Three templates: aws-lambda, ecs-fargate, aws-static-website. Three deployments. One mental model.
What’s actually shipped
The templates and resources below are what the current SC CLI provisions out of the box:
Compute templates
| Template | Cloud | Use case |
|---|---|---|
aws-lambda | AWS | Time-boxed serverless |
ecs-fargate | AWS | Long-running containers |
aws-static-website | AWS (S3 + CloudFront) | Static sites / SPAs |
cloudrun | GCP | Managed containers |
gcp-gke-autopilot | GCP | Managed Kubernetes |
gcp-static-website | GCP (GCS + Cloud CDN) | Static sites |
kubernetes-cloudrun | any k8s | Self-hosted or managed |
yc-serverless-container | Yandex Cloud | Managed containers, scale-to-zero |
Data + integration resources
| Resource | Behind the scenes |
|---|---|
mongodb-atlas | MongoDB Atlas managed cluster |
aws-rds-postgres | AWS RDS for Postgres |
gcp-cloudsql-postgres | GCP Cloud SQL for Postgres |
kubernetes-helm-postgres-operator | Postgres on your k8s cluster |
kubernetes-helm-mongodb-operator | MongoDB on your k8s cluster |
kubernetes-helm-redis-operator | Redis on your k8s cluster |
kubernetes-helm-rabbitmq-operator | RabbitMQ on your k8s cluster |
gcp-redis | GCP Cloud Memorystore |
s3-bucket, ecr-repository | AWS storage + container registry |
cloudflare | DNS zones + registrar |
yc-bucket | Yandex Object Storage (S3-compatible) |
yc-dns | Yandex Cloud DNS + an API Gateway edge for custom domains |
yc-object-storage | Pulumi state backend on Yandex Object Storage |
Yandex Cloud, and why we maintain our own provider
Yandex Cloud landed in sc v2026.9.11 (September 2026): a yc-service-account auth type, a Pulumi state backend on YC Object Storage, yc-bucket, yc-serverless-container, and yc-dns with an API Gateway in front for custom domains. Runtime secrets come out of Lockbox rather than the environment, and schedules are Timer Triggers declared in client.yaml under cloudExtras, the same place AWS schedules live.
Getting there took a detour worth mentioning, because it is the part nobody sees. Pulumi’s own Yandex provider has been deprecated since 2022, frozen at v0.13.0 — a version that predates Serverless Containers entirely, so the one resource you need most is not in it. Rather than shell out to a CLI and pretend that is infrastructure-as-code, we bridged our own: simple-container-com/pulumi-yandex v1.1.0, muxed over the current upstream Terraform provider, 268 resources where the deprecated one had 88.
Measured on the commissioning smoke: eight resources provisioned in 23 seconds; a container answering on its own custom domain through the API Gateway edge; timer triggers firing 6 for 6 with distinct event ids; MongoDB Atlas reachable from ru-central1 at a warm p50 of 44–53 ms.
What this is not, yet. This is Simple Container’s support for deploying your services to Yandex Cloud. It is not a claim that everything we run is hosted there — our own platform still runs on AWS, with the first service’s YC port in progress. And it is a statement about where bytes physically sit, not a compliance certification: we will tell you which region a bucket is in, and we will not tell you which law that satisfies.
Buyer-friendly + acquirer-friendly
A subtle but important property: because SC abstracts the compute layer, customers aren’t locked into one cloud. Equally, a potential acquirer can absorb an SC-based platform without rewiring everything — the abstraction makes the underlying cloud swappable.
Ship your infrastructure on autopilot.
Try the SC parent stack in your own repo, or see what we built on top of it — Forge, our flagship AI workflow engine for teams.