Cloud

Moving from Vercel to Google Cloud: Why and How I Migrated My Next.js Blog

Moving from Vercel to Google Cloud: Why and How I Migrated My Next.js Blog

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.

Moving to Google Cloud Run

For the hosting, I chose Google Cloud Run. It is a "serverless container" service. This means your app only runs when someone visits your site. It scales to zero when there is no traffic, so you pay almost nothing for a personal blog.

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.

Important Tip for Cloudflare users:

  1. Set your SSL/TLS mode to "Full (Strict)".
  2. At first, leave the Proxy status to "DNS Only" (Grey cloud) until Google finishes issuing the SSL certificate. Once it's "Ready", you can turn the proxy back on.

"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!


Real Software. Real Lessons.

I share the lessons I learned the hard way, so you can either avoid them or be ready when they happen.

User avatar
User avatar
User avatar
User avatar
+13K

Join 13,800+ developers and readers.

No spam ever. Unsubscribe at any time.

Discussion