I Spent 8 Hours Proving I Was Wrong

January 30, 20267 min read
devops-deployment
I Spent 8 Hours Proving I Was Wrong

Last Tuesday(this week on 27th January), I decided to break up with Vercel.

Not for any good reason. There was no outage, no bill shock, no dramatic incident. I just... wanted to see if I could. You know that feeling? When you've been with a platform so long that the relationship starts to feel like complacency? I'd been hearing whispers about Cloudflare. "Edge computing," they said. "Deploy everywhere," they promised. "Zero config," the hype claimed.

I wanted to feel independent. I wanted to prove that my Next.js app was mine, that I could pick it up and plant it anywhere the internet reached. I was a software developer, dammit. Platform-agnostic. Cloud-neutral. Free.

I was also, as I would learn over the next eight hours, completely deluded.

Act I: The Cloudflare Trap

The migration started with confidence. I exported my repo, signed up for Cloudflare, connected my GitHub account. The dashboard was sleek. The promise was intoxicating. I clicked deploy and sat back, waiting for that satisfying green checkmark.

Instead, I got red. Build failed. Something about Node.js APIs not being available in the Edge runtime.

"Edge runtime," I muttered, googling. Ah. Cloudflare's Workers run on V8 isolates, not Node.js. My Next.js app, which had been happily spinning up servers on Vercel, was now being asked to squeeze into a JavaScript sandbox where fs doesn't exist and process is a ghost.

Fine. I found the fix. I spent the next two hours adding export const runtime = 'edge' to over a hundred pages and API routes. Copy. Paste. Save. Commit. My fingers developed muscle memory. My eyes glazed over. But I was making progress. I was adapting. This is what platform independence looks like, I told myself. A little elbow grease. A little grit.

I pushed. The build passed.

I actually cheered. Alone in my apartment, I raised my coffee cup to the screen. Then I clicked the preview link.

White screen. Nothing. The logs showed no errors, but the browser showed no content. I refreshed. I hard-refreshed. I opened DevTools and found... nothing. No network errors. No console screams. Just an empty HTML shell where my application should have been.

I spent another hour in Cloudflare's docs, then Discord, then GitHub issues. I found others with the same hollow eyes. "Works on Vercel," they wrote. "Broken on Cloudflare." No solutions. Just shared confusion.

I told myself it wasn't personal. Just business. Time to try Netlify.

Act II: The Netlify False Hope

Netlify felt like coming home. I'd used them before, back in the static site days. Their dashboard was familiar, comforting. I connected the repo, held my breath, and clicked deploy.

Green checkmark. First try.

I laughed out loud. Relief flooded in. I clicked the preview link and my homepage loaded. Fast. Clean. Working. I navigated to a few pages. Everything rendered. I started to believe I'd escaped.

Then I clicked the login button.

Nothing happened. The API route returned a 404. Not a 500 — a 404. As if the endpoint didn't exist. But it did exist. I could see the file. app/api/auth/route.ts. It worked locally. It worked on Vercel. But on Netlify, it was a ghost.

I checked another API route. That one worked. I checked a third. Also worked. The fourth? Dead. There was no pattern. No logic. Some routes served, others vanished, and Netlify's logs offered no explanation. Just randomness dressed as infrastructure.

I found myself in a special kind of debugging hell. When something is consistently broken, you can fix it. When it's randomly broken, you start questioning your sanity. Did I imagine that route working yesterday? Is this a caching issue? A timing issue? Did I offend a load balancer in a past life?

I added logging. I changed HTTP methods. I rebuilt seventeen times. The same routes worked. The same routes failed. I was not adapting anymore. I was drowning.

Act III: The Shameful Return

At 11 PM, I opened Vercel. Just to look. Just to remember what working felt like.

My project was still there, archived but intact. I clicked "Reactivate." I created a new branch, fix/edge-runtime-cleanup, and began the reverse migration. Removing export const runtime = 'edge' from those hundred-plus files. Undoing my afternoon of labor. Erasing my bid for independence, file by file.

The shame was specific and sharp. Not because I'd failed we all fail at deployments. But because I'd failed at something I'd been promised would work. Next.js marketed itself as the React framework for the web. Not for Vercel. For the web. And yet, here I was, crawling back to the golden cage, my tail between my legs, my git history a graveyard of edge runtime experiments.

I pushed to Vercel. It built in ninety seconds. Everything worked. The API routes that Netlify had ghosted. The pages that Cloudflare had blanked. The image optimization. The ISR. The middleware. It all just... worked. Immediately. Effortlessly.

I sat in the dark and stared at the green checkmark. The same green checkmark I'd taken for granted that morning.

The Gradient

Here's what I understand now, what I was wrong about:

Next.js isn't lying when it says you can self-host. You can. You can dockerize it, pump it through a Node.js server, sprinkle it across edge nodes. The documentation has pages for this. Tutorials exist. It's possible.

But possible isn't the same as viable.

The framework has been sculpted, feature by feature, optimization by optimization, around Vercel's infrastructure. Incremental Static Regeneration? Designed for Vercel's caching layer. Image optimization? Expects Vercel's image API. Edge middleware? Runs on Vercel's edge network. The next build command doesn't output a generic application. It outputs a Vercel application, with assumptions baked into every byte.

When you try to run that output elsewhere, you're not just changing hosts. You're fighting the fundamental geometry of the tool. You're discovering, one broken API route at a time, that "platform-agnostic" was a marketing whisper, not an engineering guarantee.

This isn't a conspiracy. Vercel built a good product. They fund Next.js development. They have every right to optimize for their own platform. The trap isn't malice. It's the gradient.

They never forced me to stay. They just made leaving harder than staying. Just hard enough that, after a day of pain, I'd return ashamed rather than persist in independence. That's the lock-in. Not a contract. Not a technical restriction. A gradient of friction, sloping always downward toward their data centers.

The New Rule

I use Next.js still. It's excellent for what it is. But now I enter every project with honest eyes. I'm not choosing a React framework. I'm choosing a host. I'm choosing Vercel, even when the client asks for "flexibility," because I know that flexibility is a mirage I've already chased into the desert.

And when someone tells me they're considering Next.js for a project that "might move off Vercel someday," I tell them this story. The story of the hundred edge runtime exports. The random API failures. The shameful return.

The story of learning that "just because I could" sometimes means "I absolutely should not."


What's your "crawling back in shame" deployment story? Did you try to escape a platform only to come running back? Did you spend six hours debugging a "simple" migration that the docs promised would "just work"?

Drop it in the comments. I could use the company. Plus, misery loves company, and apparently, so do my API routes.

And hey! if you enjoyed this tale of hubris and heartbreak, consider subscribing to my newsletter. I send out stories like this (and actual technical insights, I promise) every week. No edge runtime exports required.

Rate this post
Share:
George Ongoro
George Ongoro

Blog Author & Software Engineer

I'm George Ongoro, a passionate software engineer focusing on full-stack development. This blog is where I share insights, engineering deep dives, and personal growth stories. Let's build something great!

View Full Bio

Related Posts

Comments (0)

Join the Discussion

Please login to join the discussion