Day 2 | One Next.js upgrade made me rethink how I deploy

In the last post I said this site runs on Cloudflare + Astro. Cost and build speed were part of the reason, and so was one earlier project.

Back then we wanted features from a newer Next.js, so we set out to upgrade the project from 14 to 16. Partway through, the deploy tool we relied on ran into support problems, and in the end the way we deployed had to change too.

An adapter in the middle

We built that site with Next.js and wanted it to deploy to Cloudflare Pages automatically. The tool in between was @cloudflare/next-on-pages.

Going back to the deploy settings from that time, these were the fields:

Build command: npx @cloudflare/next-on-pages@
Build output: .vercel/output/static
Build comments: Enabled

It works like an adapter plug: it reshapes the Next.js build output into something Cloudflare Pages can deploy. next-on-pages on GitHub

So besides Next.js and Cloudflare, we also had to keep track of which versions this adapter supported.

We upgraded for new features and hit a deploy problem

Upgrading Next.js was already on our list, because we wanted the newer features.

During the upgrade we ran into support problems with @cloudflare/next-on-pages. The deploy setup that worked with the old Next.js became one more thing the upgrade had to fix.

When I looked the tool up again, the official README clearly marks it deprecated, the repository is archived, and it points to other tools to migrate to. The deprecation notice

So that job covered two things: upgrading Next.js and changing how we deployed. It took a lot of effort to get from 14 to 16 and to get automatic deploys on Cloudflare running.

Since then I watch one thing more closely: when the framework upgrades, can the deploy tool it depends on keep up? A deprecated tool doesn't stop an old site from running today. For a project that wants to keep upgrading, though, the deploy path needs another look.

This time I check deploy support first

So for the fourth site, I started by looking at how the framework and the hosting platform fit together. Since I'd already decided to stay on Cloudflare, I cared even more about who maintains that deploy path and what I'd have to change when versions move.

That's also why I picked Astro. Astro's official Cloudflare integration docs

Still, next-on-pages was a Cloudflare tool too. So what I check is whether the integration path is still maintained and how future upgrades will go. Even when something says "official support", I look at its maintenance status.

After that upgrade, how nice a framework is to write is only part of it. I also weigh whether a change goes live smoothly and what the whole thing costs to maintain.