Astro Got Bought by Cloudflare 3 Months Ago — Here's What Actually Changed for Solo Operators

On January 16, 2026, Cloudflare acquired the Astro Technology Company. The usual promises came out on launch day: Astro stays open source, governance stays open, the roadmap stays intact, the team just gets more resources. Everyone in my Twitter timeline either cheered ("more investment in Astro!") or doomed ("Gatsby-Netlify all over again"). I stayed quiet because you can't really tell from a launch-day announcement which of the two camps is right. You have to wait and see what ships.

It's been 90+ days. This blog you're reading runs on Astro 5 + Keystatic, deployed to Vercel. I am the exact user this acquisition affects. I've been watching the releases, the PRs, the roadmap discussions, and the general vibe of the project since the announcement, and I now have an honest middle-read on what changed, what didn't, and what I'd tell a solo operator starting a new project today.

Short version: it's not Gatsby-Netlify, but it's not the "nothing changes" story either. The direction of gravity in the project has shifted. That shift is good in some ways and concerning in others, and the concerning parts are specifically concerning for people like me who don't deploy to Cloudflare.

What Actually Shipped

Credit where it's due. The Astro team has shipped real work in the last 90 days.

Astro 6's dev server runs on workerd — Cloudflare's open-source Workers runtime — so your local dev environment uses the same runtime as production if you deploy to Workers. This is a legitimately nice unlock: dev/prod parity is one of the persistent footguns in JS web development, and Astro 6 mostly closes it for Workers deployments. No more "it worked locally but Workers' weird globals broke it in prod."

Stable Live Content Collections. This went from experimental to stable in 6.0. It lets you pull content at runtime instead of only at build time — useful for dynamic content like real-time inventory, personalized dashboards, or anything where the content needs to be fresh. I've been waiting for this feature for about a year and it delivered.

First-class Content Security Policy support. CSP was a pain point in Astro for a long time. Now it's stable, well-documented, and genuinely easier than rolling your own. This is a quiet quality-of-life upgrade that matters more than the release notes made it sound.

One-command deploys to Cloudflare Workers. The Workers adapter got a real polish pass. npm create astro@latest with the Workers preset is now smooth in a way it wasn't pre-acquisition. Template, config, deploy — all clean.

The agency partner program. Not a technical change, but Astro now has a formal agency/enterprise partner program for implementations. This matters for the project's long-term business viability in a real way. Agencies needed to be able to bill against Astro, and now they can.

Those are real wins. If you're deploying to Cloudflare Workers, you are having a better time in April 2026 than you were in January. That is the fair read.

What Didn't Ship (Quietly)

Now the honest part.

Vercel adapter improvements. The Vercel adapter has not had a meaningful update since the acquisition. Not a big update, not a small update, not a docs refresh. It's maintained at roughly the level it was at on January 15. Compare that to the Workers adapter, which has seen a steady stream of commits.

This is not, by itself, a failure — the Vercel adapter works, nothing is broken — but the slope of "Workers gets faster, Vercel holds steady" is a direction. Twelve months of that direction is how projects get quietly unstable on the non-preferred path.

The Node adapter. Same story. Fine, maintained, not actively improved. If you're deploying Astro to a VPS, a Docker container, or basically anywhere that isn't Workers, you're in maintenance mode.

The static adapter. This one I was specifically hoping would get love. Static Astro sites — the thing Astro was originally famous for — are a perfect fit for deploying to any CDN. There's a universe where the static adapter gets better in the acquisition era because Cloudflare benefits from static sites hitting Cloudflare's CDN. There's another universe where the static adapter quietly stagnates because all the engineering attention goes to Workers-flavored features. So far we're in the second universe.

Generic serverless improvements. There's been no meaningful work on generic serverless deployment patterns that would benefit Netlify, AWS Lambda, or Deno Deploy users. Feature requests in those areas are still open, still unassigned.

The pattern is not malicious. Cloudflare bought a team, the team is now employed by Cloudflare, and the team is — unsurprisingly — working on the things their new employer benefits from. The governance stayed open on paper. The engineering attention clearly shifted.

The "Stewardship vs. Steering" Problem

Open governance is not the same as open direction.

Astro's governance remained open post-acquisition. Community proposals still work. RFCs still happen. The technical steering committee still exists. On paper, nothing changed.

In practice, the roadmap gravitates toward Cloudflare primitives. Durable Objects, KV, R2, D1 — these are increasingly first-class in the Astro ecosystem. The core team writes tutorials that assume you're deploying to Workers. New features land with Workers-flavored examples. When you ask "what's the recommended way to do X in Astro," the implicit answer is increasingly "the Cloudflare way."

This is not gatekeeping. Nobody is refusing to merge non-Cloudflare improvements. But the center of gravity has shifted, and a center of gravity in open source does a lot of work. If you're deploying to Vercel, you can still use Astro happily — but you're going to feel, incrementally, like you're using Astro on the B-track.

I know some of the core team, and I genuinely believe they're trying to keep the project neutral. The incentives just point the other direction, and incentives beat intentions over time.

Is This Gatsby-to-Netlify All Over Again?

No. Or at least, not yet.

Gatsby was, for most of its post-acquisition life, a project whose technical direction was eaten by its acquirer's commercial priorities, until eventually the project lost community trust and got outrun by competitors. The specific pattern was: the acquired team stopped shipping the things the broader community wanted, the roadmap became a sales-enablement document for Netlify's business, and a growing fraction of Gatsby users quietly migrated to Next.js or Astro.

Astro is not there. The technical direction is still coherent. The community is still active. The core team still ships. The open-source contributions still merge. The vibe in the issues and PRs is still recognizably "the Astro community."

But the trajectory is recognizable. The question is whether the Astro team has the organizational muscle to maintain neutrality in a way the Gatsby team did not. The first 90 days suggest they're trying. The next 18 months will tell us whether trying is enough.

The thing to watch for, if you want a leading indicator: whether the Vercel and Node adapters get meaningful improvements in the next two releases. If they do, the neutrality is real. If they don't, you're watching the pre-game of a Gatsby replay.

What I'd Actually Do Today

If I were starting a new Astro project this week:

I'd stay on Astro. The framework is still the best choice for content-driven sites. The DX is excellent, the output is fast, the Markdoc/MDX support is solid, and the ecosystem around it — Keystatic, for example — is healthy.

I'd pin my deploy target deliberately. Pick Workers, or pick Vercel, or pick Node, but decide up front. Don't let your deployment target drift over time, because the project's incentive structure is going to pull you toward Workers, and you should only go that way on purpose.

I'd keep the project adapter-portable. Write your code so that swapping adapters is a small config change, not a migration. Avoid deep integrations with Durable Objects, KV, or other Workers-specific primitives unless you're certain Workers is the long-term answer. If you're certain, use them — they're great. If you're not, keep your project portable.

I'd watch for a Vercel/Node adapter improvement in Astro 6.1 or 6.2. If one ships, good sign. If two consecutive releases go by without one, that's the signal that the neutrality has quietly eroded, and it's worth re-evaluating the framework choice for new projects.

Would I Switch?

For this blog, no. It's running happily, the Vercel adapter works, the Astro DX is still the best I've used. The cost of switching to something else (Eleventy, Hugo, a homebrew Markdoc setup) is real and the benefit is hypothetical. If the trajectory gets worse over the next 12 months, I'll revisit. For now I'm holding.

For a new project with a long time horizon? I'd think harder. Not "don't use Astro" — it's still my recommendation — but "go in with eyes open about where the project's gravity is pointing." A solo operator starting a new content site today is picking a bet on both a framework and a long-term maintainer posture. Astro is still a defensible bet. It's just not the no-brainer it was 12 months ago.

The Honest Read

Cloudflare acquiring Astro was neither the disaster the doomers predicted nor the unambiguous win the launch-day threads claimed. It was a corporate acquisition of an open-source project, executed competently, with real benefits for users on the acquirer's platform and real (if subtle) costs for users on other platforms.

If you're deploying to Cloudflare Workers, this acquisition was good for you. Ship more.

If you're deploying anywhere else, this acquisition was neutral-to-slightly-negative for you. Watch the adapter releases. Keep your project portable. Don't panic, don't cheerlead, just pay attention.

And if you're thinking about starting a new Astro project, the framework is still great. The acquirer posture is more complicated than the marketing copy says. Pick your deploy target on purpose, keep your code portable, and check back in six months.

Not Gatsby-Netlify. Not "nothing changed." Something in the middle, gradually accreting in one direction, and worth watching with clear eyes.