Performance & data
Heroku to Google Cloud Migration
Heroku made sense when you shipped. If the bill, the add-on sprawl or the region list has stopped making sense, the move to Cloud Run is a container and a pipeline — not a rewrite. We plan it, run it, and leave you able to roll back.
The same app, on a runtime you control
A Heroku dyno and a Cloud Run service do the same job: run your container, scale it, put a URL in front of it. Most Node.js applications move without their code changing. What changes is everything around the code — how it is built, where secrets come from, which identity it runs as, and what happens when a deploy goes wrong.
That surrounding layer is the whole engagement. We containerise the app, wire GitHub to Cloud Build and Artifact Registry, move config out of dyno env vars into Secret Manager, give the service its own IAM identity instead of a shared key, and keep the Heroku app running until the new one has proven itself.
- No rewrite
- A twelve-factor Node app is already a container away from Cloud Run. We change the build and the config, not the application.
- Reversible by design
- The Heroku app stays up and DNS stays switchable until the Cloud Run service has served real traffic. Rollback is a decision, not an incident.
- Secrets stop being env vars
- Config moves into Secret Manager with IAM-scoped access, so credentials are no longer readable by anyone with dashboard access.
What the engagement covers
- Audit of the current dynos, add-ons, buildpacks and config vars
- Containerisation and a reproducible build
- GitHub → Cloud Build → Artifact Registry → Cloud Run pipeline
- Secret Manager for credentials, with a dedicated runtime service account
- Health checks, logging and a documented rollback path
- Cutover plan and a parallel-run window before DNS moves
Technologies
- Google Cloud Run
- Cloud Build
- Artifact Registry
- Secret Manager
- IAM
- Node.js
- Docker
- GitHub
Where this helps most
The bill outgrew the app
Dyno hours and paid add-ons have grown past what the workload justifies, and you want a runtime that scales to zero between traffic.
An ecommerce API behind a storefront
A Node.js service your store depends on needs a deployment model with real build provenance, managed secrets and per-service identity.
You need a region, a VPC or an IAM story
Compliance, latency or a security review has asked for something the dyno model does not offer.
How we deliver
Inventory
We list every dyno, add-on, scheduled job and config var, and mark which are load-bearing, which are dead, and which have a managed Google Cloud equivalent.
Containerise
The app gets a Dockerfile and a build that produces the same image locally and in CI, so what you test is what deploys.
Wire the pipeline
GitHub triggers Cloud Build, images land in Artifact Registry, Cloud Run deploys the revision, and the service runs as its own IAM identity reading from Secret Manager.
Parallel run, then cut
Both environments run while we compare behaviour and logs. DNS moves last, and the Heroku app stays deployable until you decide otherwise.
Heroku to Google Cloud Migration
Will my application code have to change?
What happens to my Heroku Postgres or Redis add-on?
How much downtime is there?
Can we roll back?
Ready to start with heroku to google cloud migration?
Tell us about your store and your goals. We'll come back with a clear, honest plan and a transparent quote.