Your cloud bill grew faster than revenue this year. When the renewal conversation came around, your negotiating position was the honest one: we have nowhere else to go. Every deploy script, every environment convention, every piece of tribal knowledge your team carries is welded to one provider, and both sides of the table know it. The same weakness shows up in your risk register. If your provider has a multi-day regional outage, the recovery plan is "wait".
The standard fix is a multi cloud platform, and the standard cost of one is a platform engineer, or three. That is the trap this post is about escaping. A team that can credibly redeploy its workloads to a second cloud negotiates renewals from a different position and treats a provider outage as an inconvenience instead of an existential event. The argument here is that you can get that option with the team you already have, because the expensive part of multi-cloud was never the second cloud. It was the second platform.
Ask an engineer what multi-cloud requires and the answer is usually a Kubernetes stack: clusters on each provider, Terraform for each provider's networking and IAM, an ingress controller, cert management, a CI pipeline that knows the differences, and someone on call who understands all of it. That someone is a platform engineer, and at a company running five to thirty product engineers with zero or one ops person, that hire is the entire reason multi-cloud stays on the "someday" list. It is not that the second cloud is expensive. It is that the abstraction layer that makes two clouds look the same is a full-time job to build and another full-time job to maintain.
If you have one ops person, this math gets worse, not better. They are already the whole platform team. Asking them to also become fluent in a second provider's load balancers, secrets management, and cluster upgrade cadence doubles the surface area they babysit without doubling them.
So most teams quietly accept the concentration risk. The board question ("what happens if AWS raises prices or goes down?") gets a vague answer, and the renewal happens on the provider's terms. The missing piece is not headcount. It is a platform layer that makes the provider a configuration detail rather than a body of knowledge.
Convox's approach is a Rack: an environment that installs into your own cloud account on AWS, GCP, Azure, or DigitalOcean. Underneath, a v3 Rack runs Kubernetes (EKS on AWS, and the managed equivalents elsewhere), but your team never operates Kubernetes directly. What your team touches is an app model made of Services, Resources, and Timers, described in one file called convox.yml, and a CLI whose commands do not change when the provider does.
The provider is literally a field in the output, not a way of life. Here is the documented output of convox rack:
$ convox rack
Name staging
Provider gcp
Router router.0a1b2c3d4e5f.convox.cloud
Status running
Version 3.24.11That Provider gcp line is the entire visible difference between a GCP Rack and an AWS Rack from your developers' point of view. The workflow layer is provider-neutral by design: convox apps create, convox deploy, convox env set, convox logs, convox ps, convox scale, and convox releases rollback behave identically everywhere. Your team learns the platform once. There is no "the AWS person" and "the Azure person", because there is nothing provider-specific to be the person for.
If your solo ops person built your current AWS setup, this is leverage for them, not a replacement of them. Their AWS expertise stays relevant because the Rack lives inside the account they already manage, with the IAM, networking, and billing visibility they already have. What changes is that the twenty other engineers stop needing them for every deploy, and the second-cloud option stops requiring them to learn a second provider from scratch.
Here is a minimal, real manifest: a web service, a background worker, and a Postgres database.
resources:
database:
type: postgres
services:
web:
build: .
port: 3000
health: /health
scale:
count: 2
cpu: 250
memory: 512
resources:
- database
worker:
build: .
command: bin/worker
resources:
- databaseThis identical file deploys with convox deploy to a Rack on AWS, GCP, or Azure with no rewrite. The port gets a load balancer and TLS on every provider. The scale block reserves CPU and memory the same way everywhere. Linking the database resource injects DATABASE_URL into both services regardless of which cloud is underneath. Environment secrets are set once with convox env set and travel with the release, and rolling updates with automatic rollback on failed health checks work the same on all providers.
The CI story is equally portable, because the pipeline only speaks the Convox CLI. A deploy job that runs convox deploy -r production today runs convox deploy -r dr-rack tomorrow with a one-word change. We have a full walkthrough of this pattern in multi-cloud deployments with GitHub Actions.
The economics matter as much as the mechanics. A self-hosted Rack is BYOC: it runs in your account and you pay your cloud provider directly, with no Convox markup on that infrastructure. That means a provider switch becomes a pricing negotiation rather than a contract escape, because the thing you would move is compute you already own the billing relationship for. You can see exactly what the platform layer itself costs on the Convox pricing page, and compare it against the loaded cost of the platform hire it replaces.
A multi cloud platform vendor that tells you portability is free is selling something. Here is what it actually costs.
Data gravity is the real lock-in. A manifest moves in minutes. A production database does not. Your Postgres data has to be dumped, transferred, and restored, or replicated ahead of time, and at production scale that is a project with a maintenance window, not a CLI command. Convox helps at the edges: the same resource definition provisions a database on any provider, and resource overlays let you point the same DATABASE_URL at a managed database without code changes. But nobody, including Convox, makes a terabyte of data teleport.
Provider-specific services do not port for free. If your app leans on a proprietary queue, a provider-specific ML service, or IAM-integrated features, those calls follow you to the second cloud and fail there. The discipline is to keep provider-specific dependencies behind interfaces you could swap. Convox's own feature set has an honest example: fractional GPUs, GPU scale to zero, and GPU budget caps are AWS-only features on Convox today. If those are load-bearing for you, your GPU workloads are AWS workloads.
Multi-cloud readiness is not active-active. Running the same workload live on two clouds simultaneously, with cross-cloud data replication and traffic splitting, is a genuinely hard distributed-systems problem, and Convox does not pretend to dissolve it. What one manifest gives you is the credible ability to stand your stack up somewhere else quickly. For renewal leverage and outage survival, that is the part that matters, and it is the part that used to require the hire.
And there is onboarding. Getting an existing app onto Convox means writing a convox.yml and, if you do not have one, a Dockerfile. For a typical web-plus-worker app this is small, and the example apps cover the common frameworks, but it is real work and pretending otherwise sets you up badly. Budget a day or two for the first app, less for each one after.
The realistic pattern is not two production clouds. It is one production cloud plus a periodically exercised second-cloud Rack, running staging or a DR copy. That second Rack is the proof that the option is real: it demonstrates to you, and to anyone asking at renewal time, that your workloads run somewhere else on demand. An option you have never exercised is a hope, not a negotiating position.
Concretely, the evaluation looks like this. Install a Rack on your current provider and move one representative app onto it, converting it to convox.yml. Then install a second Rack on a different provider, create the same app there with convox apps create, set its environment with convox env set, and run convox deploy against the second Rack. Count how many lines of the manifest you had to touch. That number is your actual portability, measured on your actual code rather than a vendor's claim.
The trade you are making is a platform subscription and a couple of days of onboarding in exchange for not making a platform-team hire and not writing the answer "we would be stuck" in your risk register. For a team of five to thirty engineers with at most one ops person, that is usually the cheapest insurance on the books, and it is one your ops person operates rather than one that operates them.
No. A Convox Rack runs on Kubernetes underneath (EKS on AWS, with GCP and Azure equivalents), but your team interacts with services, resources, and releases through the Convox CLI and convox.yml. Nobody on the team writes Kubernetes manifests, manages ingress controllers, or performs cluster upgrades to deploy on either cloud.
Yes. The manifest describes services, resources, timers, and environment in provider-neutral terms, and the Rack translates that into each provider's infrastructure. The same file deploys unchanged with convox deploy. Provider-level tuning such as instance types lives in rack parameters, separate from your application definition, so app code and config stay portable.
No. The recommended pattern is one production cloud plus a second-cloud Rack running staging or a DR copy that you exercise periodically. That proves the redeploy path works without doubling your infrastructure bill, and it is enough to change your position in a renewal negotiation or a provider outage.
Data and proprietary services. A production database must be migrated or replicated deliberately, and direct calls to provider-specific services like proprietary queues do not port automatically. Convox's GPU features such as fractional GPUs and GPU scale to zero are AWS-only today. The app layer moves freely; plan separately for data.
The two-day pilot: install a Rack on a second provider, deploy a staging copy of one app to it, and measure how much of the manifest moved untouched. The Getting Started Guide walks through Rack installation and your first deploy.
Create a free account and run the pilot this sprint. If you want help scoping which app to move first, talk to our team.
