The Azure bill was never the problem. The problem was the hours. Every Next.js project I have seen put on Azure ended up with a developer, often a good one, spending days doing something that takes ten minutes on a host built for Next.js. The cost of Azure for a Next.js app is not measured in the monthly invoice. It is measured in developer time, and that is the most expensive line item you have.
The root of it is simple. Next.js is built by Vercel, and its best features assume an environment that looks like the one Vercel provides. Azure does not provide that environment, so the features that make Next.js worth choosing each turn into a small engineering project to make them work at all.
The features that define Next.js are the ones that break
Image optimization is the clearest example. The next/image optimizer works by generating resized images on demand and caching them to disk. On Azure App Service running Linux, the folder your app is deployed to is read-only. The optimizer tries to write its cache, cannot, and image optimization fails. The fix exists, you redirect the cache to a writable location, but now you are configuring filesystem paths to make a core framework feature do the one thing it is supposed to do out of the box.
Incremental static regeneration is the next casualty. On Azure Static Web Apps, ISR image caching is not supported, and the platform caps a hybrid Next.js app at 250 MB, which pushes you into standalone-build territory with custom scripts copying static folders into the right place just to fit. ISR is one of the headline reasons teams choose Next.js. Having to fight the host to use it tells you the host and the framework were not designed for each other.
Middleware is the third. Middleware is fragile on Azure in a way it simply is not elsewhere. People have had it working on one version of Next and watched it stop working after an upgrade, with no change on their side except the framework version the rest of the world upgrades to routinely. You also end up writing matcher rules to exclude the platform's own internal routes so your middleware does not process them. That is configuration that exists purely because of where you are hosting.
And if you put Azure Front Door in front of the app to get a CDN, you walk into a new category of problems: double compression between Next's own gzip and the CDN's, caching rules that break JavaScript chunk loading, and the trap where caching your pages to get compression also breaks ISR revalidation. You end up choosing which feature to sacrifice.
None of these are unfixable, and that is the point
Every problem I just listed has a workaround. You can redirect the image cache, script the standalone build, pin to a Next version where middleware behaves, and tune Front Door rules until the compression stops fighting itself. Azure is a capable cloud. This is not a claim that it cannot run Next.js.
The point is what it costs to get there. Each of these is a research task: read the GitHub issues, find the person who solved it, test it, and document it so the next person on your team does not rediscover it from scratch. Then you upgrade Next.js six months later and some of that work has to happen again, because the workarounds are coupled to versions and platform behaviour that move underneath you. The instability is the tax. You are not paying it once.
Compare that to a host built for Next.js, where image optimization, ISR, and middleware are simply on, upgrades are boring, and the developer who would have spent three days on deployment plumbing spends them on the actual product. That difference, multiplied across a team and a year, is real money that never shows up labelled as "Azure."
When you are stuck with Azure anyway
Sometimes you do not get to choose. The client is an enterprise standardised on Azure, there are compliance and procurement reasons, the rest of their stack lives there, and that is the end of the discussion. That is legitimate, and if it is your situation, the answer is not to fight it on principle.
But go in with your eyes open. Budget the developer hours for the deployment work explicitly, instead of discovering them halfway through. Pin your Next.js version deliberately and treat upgrades as scheduled work with testing, not routine bumps. And consider whether a static export covers the project, because a site that does not need ISR or server rendering sidesteps most of this entirely and Azure hosts static output perfectly well.
My actual position is narrow and practical. If you have a free choice of host for a Next.js project, do not pick Azure, because you will pay for it in the one currency you cannot get back. And if you do not have a choice, price the time in before you start, because the platform certainly will not warn you.
