Moving from Vercel Nextjs to Google Cloud Run

Let’s be honest: I love Vercel. It is an amazing platform. The developer experience is probably the best you can find. If you are starting a new project or need to move fast, I still recommend it.

But as I added more projects like zum360, LearningCool, and my sister’s website, my monthly bill started to grow. Those "Edge Function Execution" charges can be a surprise at the end of the month.

Since I use Google Cloud Platform (GCP) at my current job, I decided it was time to move my personal blog and projects there. I wanted total control and lower costs.

Here is the technical journey of how I did it, developer to developer.

Preparing for Docker

First, you need to package your app. I already wrote a guide on how to deploy Next.js outside Vercel which covers the basics, but here is the specific "secret sauce" for GCP.

Next.js has a built-in standalone mode. This is critical because it creates a very small production build. You don't need to ship your massive node_modules folder.

Update your next.config.ts:

const nextConfig = {
  output: 'standalone',
}

[!TIP] You can find more details in the official Next.js documentation.

Why Google Cloud Run? (The "Goldilocks" Service)

GCP can be overwhelming. You have App Engine (too opinionated for some), Compute Engine (too much server management), and GKE (K8s is overkill for a blog).

I chose Google Cloud Run because it's the "just right" spot for a Next.js app. It is a serverless container platform that abstracts away the infrastructure but gives you the power of Docker.

The Developer "Free Tier" Hack

Here is the best part: Cloud Run has a very generous Free Tier.

First 180,000 vCPU-seconds per month are free.
First 360,000 GiB-seconds per month are free.
2 million requests per month? Also free.

For a personal blog, this means your monthly bill will likely be $0.00. It scales to zero when nobody is reading, and it handles the SSL certificates for you. It's essentially "Vercel for engineers" who want to know what's happening under the hood.

GCP vs Vercel (The Technical Face-off)

If we talk numbers, the "Hobby" tier of Vercel is great, but it has boundaries that an engineer might find restrictive as they scale:

Requests: Vercel gives you plenty, but GCP Cloud Run gives you 2 million requests per month for free. For a blog, that's effectively infinite traffic.
Edge Functions vs. Containers: On Vercel, you have to worry about the 10-second execution limit for Edge Functions. In Cloud Run, your container can run for up to 60 minutes if needed. You have the full power of a Linux environment, not just a restricted runtime.
Build Times: This was a big one for me. Vercel's free tier gives you about 45 minutes of build time per month. GCP's Cloud Build gives you 120 free build-minutes per day (on certain machine types). I can push code all day long without worrying about hitting a wall.

In short, Vercel is a managed service for speed; GCP is infrastructure for control. If you're building a "portfolio of many small apps" like I am, GCP's aggregated free tier is a life-saver.

[!TIP] Want to dive deeper? Check out the Google Cloud Run Pricing page to see how the free tier works.

The CLI Setup

First, I installed the Google Cloud CLI. After logging in with gcloud auth login, I was ready to build.

Building and Deploying

Instead of building the Docker image on my laptop (which is slow), I used Cloud Build. This command sends your code to Google’s servers, builds the image, and saves it in a private registry:

gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/danywalls-blog .

Then, to make it live:

gcloud run deploy danywalls-blog \
  --image gcr.io/YOUR_PROJECT_ID/danywalls-blog \
  --region us-central1 \
  --platform managed \
  --allow-unauthenticated

Managing Secrets (The Professional Way)

On Vercel, you just paste your API keys into a web panel. In GCP, we use Secret Manager.

I stored my ConvertKit API key and Google Analytics ID there and granted my Cloud Run service the Secret Manager Secret Accessor role. Then, I updated the service to mount these secrets as environment variables:

gcloud run services update danywalls-blog \
  --set-secrets=CONVERTKIT_API_KEY=CONVERTKIT_API_KEY:latest

It’s more steps than Vercel, but it’s much more secure. No secrets are ever stored in my code or build logs.

Connecting the Domains (Double Trouble)

My blog uses both danywalls.dev and danywalls.com. To link them, I used Domain Mappings in Cloud Run.

gcloud beta run domain-mappings create --service danywalls-blog --domain danywalls.com

Google gave me a list of A and AAAA records. I use Cloudflare for DNS, so I added those records there.

Handling WWW and Redirections

One thing I noticed after the migration was that www.danywalls.com stopped working. Unlike Vercel, which handles www redirects automatically, Google Cloud treats subdomains as separate entities.

To fix this, I had to:

Add another Domain Mapping in Cloud Run for the www version of each domain.
Create a CNAME record in Cloudflare for www pointing to the root domain.
Set up a Redirect Rule in Cloudflare to send all www traffic to the root domain (non-www) for better SEO consistency.

If you are using Cloudflare's new Redirect Rules, you can use a Wildcard pattern like https://www.* and target https://${1} with a 301 redirect. This ensures your users always land on your preferred URL.

"Git Push to Deploy" with GitHub Actions

I didn't want to lose that Vercel feeling where you just push code and it updates the site. I recreated this using GitHub Actions.

I created a .github/workflows/deploy.yml file. This workflow authenticates with Google Cloud using a Service Account key (stored in GitHub Secrets) and runs the build and deploy commands automatically every time I push to main.

In my next article, I’ll dive deeper into exactly how I configured this. I’ll share how my AI assistant helped me set up everything to make the workflow feel as natural and smooth as it did on Vercel. Stay tuned!

Lessons Learned

Leaving Vercel was a big step, but I learned so much:

Cost Control: I now pay a few cents instead of $20/month.
Infrastructure Skills: I now manage my own containers and security policies.
Portability: My app is now a standard Docker image. I can move it to any other cloud in 5 minutes.

If you’re feeling restricted by Vercel’s pricing or just want to level up your engineering skills, building your own "nest" in the cloud is a great experience.

Are you thinking about migrating? Let me know your thoughts on Twitter/X!