Journal

Why I moved devin.vc to Cloudflare from Vercel

Vercel's deploy cap broke my CMS workflow. Cloudflare Pages fixed it and the performance numbers happened to get better too.

This site runs on Astro with Sanity as the CMS. Every content change in Sanity fires a webhook that triggers a redeploy. That's how static CMS-driven sites work: edit, rebuild, publish. When you're actively building a site out, that means a lot of deploys. New journal entries, schema changes, copy edits, image swaps, project updates. Some days I was pushing 30 or 40 content changes.

Vercel's free tier caps deploys at 100 per day. I hit that. Not from some stress test or bad automation loop, just from using my CMS normally. The deploy queue backed up, changes stopped going live, and I was refreshing the Vercel dashboard waiting for the daily counter to reset. For a static marketing site.

Cloudflare Pages has 500 builds per month on the free tier with no daily cap. That was the entire reason for the move. My CMS workflow needed uncapped deploys and Vercel's limits got in the way.

The migration was straightforward. Astro has a first-party Cloudflare adapter, so the build config was mostly plug-and-play. The actual work was environment variables (Cloudflare routes these through their Workers runtime, which is a different setup than Vercel), getting the wrangler.toml right, and pointing DNS over. I spent about an hour debugging nodejs_compat flags and Cloudflare's env bridging pattern. Nothing dramatic.

The performance improvements were a side effect I hadn't planned for. Before the migration, TTFB was around 120ms. After, it dropped to about 35ms. LCP improved by roughly 300ms. Lighthouse hit 100 across performance, accessibility, best practices, and SEO.

The reason is pretty simple. Cloudflare runs 330+ edge locations in over 120 countries and serves static assets directly from whichever data center is closest to the visitor. No origin fetch for cached content. Vercel's edge runs on top of AWS, which adds an abstraction layer. For a static site where every page is a pre-built file, the fewer layers between the file and the browser, the faster it loads.

Does 85ms of TTFB matter for a personal site? Probably not at the individual visitor level. But Google's Core Web Vitals factor it into search ranking, and faster TTFB compounds into faster LCP and lower perceived load times. A Deloitte study found that even a 0.1-second improvement in site speed correlated with something like 8% higher conversions in retail. Different context, but the underlying principle applies. Faster pages hold attention better.

The stack also got simpler after the move. Cloudflare's model is: static files on the edge, Workers if you need server logic. That's it. Vercel's abstractions around serverless functions, middleware, and edge runtime are powerful if you need them, but for a static site they're just cognitive overhead. After the migration, the architecture matched what the site actually does instead of accommodating features I'd never use.

Cost-wise, Cloudflare Pages is free with unlimited bandwidth and unlimited requests. Vercel's free tier works but has limits that start to pinch once your workflow gets active (as I found out with the deploy cap).

Vercel is still the right choice if you're building a Next.js app with ISR, API routes, and dynamic rendering. It's purpose-built for that. But for a static or mostly-static site where content deploys are frequent, Cloudflare Pages removes the constraints that matter most and the performance happens to be better too.