Render to Google Cloud in an hour.
Fully automated.
One command. An agent reads your repository and your render.yaml, then deploys into the Google Cloud project you already own - after you approve the plan.
“We migrated our whole staging environment with a single prompt. Production was a one-click clone of staging. Once the tests gave us confidence we moved DNS off Heroku - we have been running production on our own cloud with Qovery ever since.”
“We liked the Heroku experience, and we knew the cloud meant skills and effort we did not have spare - that is why we kept putting the migration off. We do not regret doing it with Qovery. Deployments that took me over two hours now take 30 minutes.”
Render is a good platform right up until it is not.
Nothing below is a criticism of how Render works. They are the boundaries of the model: a platform that runs your services in its own account can only ever offer you what it has already built.
Five regions, and a service cannot move between them
- Oregon, Ohio, Virginia, Frankfurt and Singapore. If your customers or your regulator need somewhere else, there is no somewhere else. Render also does not support changing the region of an existing service - you create a new one and migrate the data across. And because each region has its own private network, two services in two regions cannot talk privately at all; that traffic crosses the public internet and you secure it yourself. In your own Google Cloud project a region is a deployment parameter. Any Google Cloud region, with multi-region and multi-cluster from one control plane.
The features that make it production-grade are plan gates
- Autoscaling, preview environments and audit logs start at Pro. SAML SSO, SCIM and HIPAA-enabled workspaces start at Scale. Dedicated outbound IPs need Pro and then cost an additional monthly fee on top. Even reading Render’s SOC 2 Type 2 report requires Pro and an NDA. None of these are exotic - they are what a security review asks about, and each is a line on a pricing page rather than a property of infrastructure you control. In your own project, Google Cloud IAM governs access, Cloud Audit Logs records what happened, and the three fixed egress IPs are simply how the network is built. No tier attached.
Fixed instance shapes, and disks that block scaling
- Instance types are fixed RAM and CPU tiers, so a service needing slightly more memory buys a whole size class more of everything. A service with a persistent disk attached cannot run more than one instance at all, which turns a storage decision into a hard scaling ceiling. On Compute Engine the node shape is yours to choose, storage is a volume claim rather than a constraint, and Qovery can place interruptible pools on cheaper capacity while the web tier stays on demand.
Three steps, then the agent does it.
Your side takes about five minutes. Everything after that is automated.
- 01
A service account key provisions the network and a GKE cluster in your own project - about twenty minutes, and nothing leaves your boundary. Qovery gets a role you can read, scope down or revoke. Talk to a migration engineer before you connect anything.
- 02
One command teaches your coding agent how to read the repository - a render.yaml Blueprint, a Dockerfile, a build command, a set of environment variables - and describe the deployment in Qovery’s own terms. Nothing is deployed at this point. You are only giving the agent the vocabulary.
- 03
The agent detects every service, writes a Dockerfile where one is missing, maps your Render environment variables to Qovery variables and secrets, and shows you the plan. You approve it before a single resource is created - and your Render Postgres stays where it is, connected over the network, so you validate against real data before migrating a byte.
- 04Optional
Take this first or last - some teams want it as step zero, before they connect anything. A Qovery staff solution engineer reviews the cluster setup and environment layout with your team, then goes through the practices that keep the estate cheap and quiet: node sizing and Spot policy, autoscaling thresholds, preview-environment lifetimes, secret scoping and how to promote the same artifact between stages.
- network
- your VPC, three fixed egress IPs
- cluster
- GKE, in your region
- access
- a role scoped to Qovery
Works with any coding agent that reads skills. Nothing is deployed at this point.
web Node.js 20 Dockerfile generated worker Node.js 20 detected from render.yaml scheduler cron 2 jobs database PostgreSQL 15 Render Postgres, connected remotely
Nothing has been created yet. You approve the plan first.
- cluster
- node sizing, Spot policy, autoscaling
- workflow
- stages, approval gates, preview TTLs
- access
- secret scoping, roles per environment
From there it is automatic. Your apps come up running and live on Google Cloud, reachable on a public URL - while the Render stack keeps serving traffic untouched.
You pay Google Cloud. And it discounts you automatically.
Render sells you a tier. Google Cloud sells you a machine, applies sustained use discounts to it without being asked, and lets you commit for more on top. For a service that runs all month - which is what a web service is - that discount arrives whether or not anyone negotiates it.
Depends on your instance types and counts, your Postgres and Key Value plans, egress, data volume and region. A migration engineer will model your estate against the equivalent Google Cloud shape before you commit to anything.
What Google Cloud gives you that five fixed tiers cannot.
Render asks you to pick from a short list of instance types in a short list of regions. Google Cloud asks you what the service actually needs, and where.
Custom machine types instead of size classes
- Google Cloud lets you define the exact vCPU and memory a service needs. On Render a worker that wants a little more memory has to buy the next tier of everything, so a memory-heavy job and a CPU-heavy API end up subsidising each other. Sizing per service is the single easiest cost reduction available immediately after a migration, and it is not something a tier list can express.
Sustained use discounts you do not have to ask for
- Google Cloud applies sustained use discounts automatically to instances that run for most of the month, and committed use discounts on top if you commit for one or three years. The first needs no contract and no forecast. Render has neither mechanism, because you are buying a plan rather than capacity.
Every Google Cloud region, and private networking between them
- Render offers five regions, will not move an existing service between them, and gives each region a separate private network so cross-region services must talk over the public internet. In your own project you choose from Google’s full region list, and VPC peering, Private Service Connect and Cloud NAT make cross-region private traffic a configuration rather than a rewrite.
Our control plane. Your account, your bill.
Qovery sits above the infrastructure and never owns it. Every cluster, database and bucket is provisioned inside the Google Cloud project you already hold - Google Cloud invoices you directly.
- We do not take a cut of your Google Cloud spend. A flat subscription, whether your bill is $2k or $200k.
- We push it the other way: idle nodes, oversized requests and preview environments left running get flagged so you stop paying for them.
- Render runs all of this in its own account. Qovery runs it in yours.
Not sure which Google Cloud services fit your workload? A solution engineer will map it with you.
CONTROL PLANEStop paying Qovery and the stack keeps running - the manifests and qovery/qovery Terraform are already in your account.
Your first service on Google Cloud,
live within the hour.
Any Google Cloud region, with multi-region and multi-cluster from one control plane. Nothing you do here touches your existing Render services until you decide to move the domain.
Render to Google Cloud
Something not covered here? Talk to a migration engineer - they have done this on estates larger than yours.