When you need it
Your services already run in containers, but each team ships them its own way. Every new service starts as a copy of another team's pipeline and infrastructure, and you do not want to run Kubernetes just to fix that.
What sets the quote
- One cloud, one region and one runtime: ECS on Fargate, Azure Container Apps or Google Cloud Run.
- Starter (3–4 weeks): up to 3 environments, up to 5 stateless services that already run in containers, one registry, one ingress domain and one CI platform.
- Standard (6–7 weeks): the Starter scope for up to 20 services, plus a preview environment for each pull request, canary or blue-green releases through the shared module and a cost dashboard.
- More services, environments or regions, or a second runtime, are quoted after sizing.
What changes
- A new service goes live by calling the shared module, not by copying another team's setup.
- Every service gets the same identity, secrets, networking, logging and scaling settings by default.
- Releases run through one pipeline, and rolling back is a single step.
- With Standard, reviewers try each pull request in its own preview environment, and releases reach users gradually.
What you get
- Terraform code for the platform, covering networking, ingress, the registry and each environment
- A reusable service module that sets identity, secrets, scaling, health checks and logging for each service
- A CI/CD pipeline template with image build, vulnerability scanning and keyless deployment through OpenID Connect
- Your services onboarded to the module, up to 5 in Starter or 20 in Standard
- A custom domain with a managed TLS certificate on the ingress
- In Standard, pull-request previews, canary or blue-green releases and a cost dashboard by service and environment
- Runbooks and a handover session with your team
We built Rayna Tours’ container platform on ECS on Fargate this way: one shared service module used across many repositories, and a preview environment for each pull request.
What we cover on each platform
| Area | ECS on Fargate | Azure Container Apps | Google Cloud Run |
|---|---|---|---|
| Ingress and network | Application Load Balancer with an ACM certificate; services in private subnets | Container Apps environment in your VNet; managed certificate on your domain | External Application Load Balancer with a Google-managed certificate; Direct VPC egress |
| Identity, secrets and images | A task role per service; Secrets Manager or Parameter Store; ECR | A managed identity per app; Key Vault references; ACR | A service account per service; Secret Manager; Artifact Registry |
| Releases | Rolling deployments with the circuit breaker; blue-green or canary in Standard | Revisions; traffic splitting in Standard | Revisions; traffic splitting in Standard |
| Pull-request previews (Standard) | A preview service per pull request behind a load balancer rule | A labelled revision per pull request | A tagged revision with its own URL per pull request |
Not included
- Containerising legacy apps (a separate package, legacy app modernisation)
- Setting up or migrating databases and other stateful services
- The landing zone and organisation-wide guardrails around the platform
- Running the platform after handover (available as Platform Care)
What we need from you
- AWS: an IAM Identity Center permission set with AdministratorAccess in the platform accounts for the length of the build.
- Azure: Contributor and Role Based Access Control Administrator on the platform subscription.
- Google Cloud: Editor and Project IAM Admin on the platform projects.
- Admin rights on the platform repositories in your CI platform, and DNS changes for the ingress domain.
- A technical owner for 2–3 hours a week, and a developer from each service team during onboarding.
How it works
Free 30-minute call, then a written fixed quote based on your runtime, environments and services.
Design workshop to agree environments, naming, ingress, secrets and the release model.
We build the platform and the service module as code, and you review every change as a pull request.
One service goes through end to end first, then the rest follow in short iterations.
Handover with runbooks, with the option to continue under Platform Care.
At a glance
- Duration
- 3–7 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related services
Container platform check
A one-week, read-only review of your Kubernetes clusters or serverless container runtime, with evidence for every finding, a hardening plan ordered by risk and a readout with your team.
Kubernetes platform
A Kubernetes platform on EKS, AKS, GKE or managed OpenShift in 5–6 weeks, run through GitOps, with access, policies, secrets and scaling in place and your first services onboarded.