Vite, Astro and Void Are One Company's Stack Now: How We Decide What to Adopt and What to Keep Portable

Should you change your stack because Cloudflare now owns Vite? No — least of all because of the ownership. Vite, Vitest, Rolldown, Oxc and Vite+ are still MIT-licensed, open source and vendor-agnostic after VoidZero joined Cloudflare on June 4, 2026. What did change on October 15 is that Cloudflare open-sourced Void, its full-stack platform for Vite apps on Workers. The decision splits by workload: content site → stay on static Astro; app with a database or internal tool → Void is a legitimate default today; project where portability is a hard requirement → keep Vite and choose the host last. That is the three-lane framework we are using at Mintec.

Nine months were enough for one company to hold the content framework we run, the bundler that feeds it, and the runtime we deploy to. This is not an acquisitions anecdote: it is an architecture decision that gets made now, before your next project starts on someone else's defaults.

The timeline, with dates you can check

"Cloudflare is taking over the ecosystem" is the sentence everyone repeats and nobody verifies. Here are the milestones, all with first-party sources: the announcement of the Astro team acquisition, VoidZero joining Cloudflare, and the Deploy with Void post.

The numbers in the June announcement say a lot about the weight of this: Vite is at roughly 129 million weekly downloads and the Cloudflare Vite plugin at almost 14 million — over 10% of Vite itself, in their own words — and they attribute it to a phenomenon with a name: agent-written applications choose Vite, and increasingly they choose Vite running on Cloudflare.

What Void actually is

Void does not compete with Astro. It is the layer that was missing from Astro — and from any Vite app: data and deployment.

• Void SDK — a Vite plugin (npm install void) that turns your app into a full-stack app on Workers: server routes on Hono, Better Auth, pre-rendering, caching, islands, and end-to-end type safety from the database query to the UI. void/db gives you a local database in development and provisions D1 in production; void/ai does the same through the AI Gateway.
• Void CLI — built on the new cf CLI and designed so your agents can deploy too: asking an agent to read logs, debug failing requests, or own the full lifecycle is part of the flow.
• Void Platform — the open-source, forkable piece: a shared deployment environment on Workers for Platforms where an admin sets resource limits and controls who can deploy.

And this is what matters if you already have a site in production: Void integrates with existing frameworks — React Router, SvelteKit, Nuxt, TanStack Start, Vinext and Astro — instead of replacing them. You can keep writing your site the way you write it today and let Void handle data, migrations and deployment.

The three-lane framework we use before adopting a layer

We do not adopt technology because of the announcement; we adopt it for the layer it solves. Our current rule:

The third row is not theory: we wrote it in October when EmDash and Vinext shipped hours apart, and it is still the filter we apply before committing a client site to a vendor stack (the portability budget we use before adopting a vendor stack).

What we are doing at Mintec, no spin

mintec.co runs today on Astro 6.4 on Cloudflare Pages — the same site we migrated from Next.js on Vercel, and about which we already published what we learned six months after the Astro acquisition.

Our position, three announcements later:

1. We are not moving mintec.co to Void. An editorial site gains nothing from D1 or automatic provisioning, and we have already documented what actually changes when moving from Pages to Workers — we are staging that migration, not executing it.
2. We do evaluate Void for internal tooling. There the calculus inverts: provisioning a dashboard with a database in minutes beats portability, because the tool lives or dies with us.
3. The Astro upgrade stays a separate decision — we analyzed what Astro 7 changes with Vite 8 and the Rust compiler and our repo is still on 6.4 for a reason: the real benefit depends on the site's profile, not the version number.

Where lock-in actually lives

The debate over whether Vite "became Cloudflare's" is settled by the license: MIT, vendor-agnostic, same team leading, $1 million fund administered by the Vite core team. The New Stack described the community's reaction as mixed, and rightly so: nobody disputes the legal contract, everybody senses the direction.

Our reading, after operating this stack in production: lock-in is not in the license, it is in the defaults. The Cloudflare Vite plugin runs your server code inside workerd in local development — exactly what you want if you are deploying to Cloudflare, and exactly what you do not want if your app has to run somewhere else. Void takes that logic one step further: void/db does not ask which database you use, it gives you D1.

That is not a trap; it is a value proposition you accept or reject consciously. What is a mistake is accepting it by inertia because "every agent generates Vite apps".

What to do this week if you are choosing a stack

• If your project is content: change nothing because of this announcement. Verify your site does not depend on anything that only exists in Cloudflare, and keep building.
• If your project is an app with data: spin up a Void prototype in a test account and time how long it takes to have database, auth and deployment running. It is the only honest way to evaluate it.
• If you sell to clients: document today which layer of your stack is replaceable and which is not. When a client asks "what if we leave?", the answer has to exist before the question.

The Void announcement does not force anyone to migrate. It forces everyone to decide, with eyes open, which part of your stack you want to belong to nobody and which part you are willing to let belong to Cloudflare.