VoidZero announces Vite native deployment platform “Void”

VoidZero, the developer of tools such as Vite, Rolldown, Vitest, and Oxc, has announced a web application deployment platform called “Void”. Early access applications began on March 16, 2026.

VoidZero’s movements in the past week

VoidZero has been making a series of big announcements in recent days. On March 13th, we adopted the Rust bundler Rolldown Vite 8.0, the next day we introduced Vite+, which integrates builds, tests, lint, and formatting, and now we have a deployment platform.

@@CODE0@@

In the webpack era, separate tools such as webpack, Jest, ESLint, Prettier, and Vercel were combined, but the idea is to integrate them with vp dev → vp build → vp test → void deploy. We’re trying to do for the entire Vite ecosystem what Vercel is doing for Next.js.

How Void works

Void is built on top of Cloudflare’s suite of services.

Service	Role
Cloudflare Workers	Backend Server (Edge Execution)
D1	SQLite-based distributed database
R2	Object storage
KV	Key Value Store

Users do not need to be aware of these directly. You don’t even need a Cloudflare account, and Void takes care of post-deployment management. It scans the source code and automatically provisions the necessary resources (DB, KV, storage, etc.), and no configuration files are required. Just add the plugin to your Vite project and hit void deploy.

@@CODE1@@

For local development, you can use Miniflare (a local simulator compatible with Workers).

V8 Isolates limitations

Since the technical foundation is Cloudflare Workers, the execution environment is V8 Isolates. Unlike the full Node.js runtime, there are some limitations.

Constraints	Contents
CPU time limit	50ms for free tier, upper limit for paid tier
Not compatible with CommonJS	`require()` cannot be used (ESM only)
Node.js API	Many can be used with the `nodejs_compat` flag, but some such as `fs` and `child_process` cannot be used
File system	Local files cannot be read or written

This restriction is not a problem if you use SSG (static site generation) to generate HTML in advance. The build is completed on Node.js, and the generated HTML is delivered to the CDN. If you use SSR to dynamically access the Node.js API, the migration hurdle will simply be higher.

Merging with vinext

vinext, which Cloudflare used AI to reimplement Next.js on Vite in one week, which we covered last month, can also be deployed to Cloudflare Workers with vinext deploy. Although vinext and Void are separate projects, the combination of “Vite + Cloudflare infrastructure” is the same.

graph LR
    A[Cloudflare] -->|vinext| B["Next.js APIを<br/>Vite上に再実装"]
    C[VoidZero] -->|Void| D["Viteネイティブの<br/>デプロイ基盤"]
    B --> E["Cloudflare Workers<br/>エッジ実行"]
    D --> E

vinext achieves 4.4 times faster production builds with Vite 8’s Rolldown integration. Void should also use the same Rolldown-based build pipeline. The combination of Cloudflare + Vite is being attacked from different directions: vinext from the Cloudflare side and Void from the Vite side.

What happens when these things merge? This is a world where everyone rides on Cloudflare’s edge, with Next.js users via vinext and users of other Vite-based frameworks (Astro, Nuxt, SvelteKit, etc.) via Void.

Can this blog (Astro + Vercel) be migrated to Void?

Here’s my own story. This blog was built using Astro 5 and deployed as a static site on Vercel. We investigated whether it is possible to migrate to Void or Cloudflare, and what will change if we migrate.

Current configuration

Identify parts that depend on Vercel from the actual astro.config.mjs and package.json.

Vercel specific dependency.

Depends	Usage
`@astrojs/vercel`	Astro adapter (configured with `webAnalytics: { enabled: true }`)
`@vercel/speed-insights`	Performance measurement
`vercel.json`	Redirect settings (5 301 redirects from old URL to new URL)

**Platform independent dependency (no impact on migration). **

Depends	Usage
`astro-pagefind`	Full text search (index generated during build, distributed as static file)
`@astrojs/partytown`	Separate third-party scripts into Web Workers
`rehype-katex` / `remark-math`	Formula rendering
`rehype-external-links`	Add `target="_blank"` to external links
Custom rehype plugin	YouTube embed, lazy loading of video embed
`sharp`	Image processing (only when building)
`better-sqlite3`	For Lab tools (only when building)

output: 'static'’s completely static site, so there are no places that use Node.js API at runtime. The limitations of V8 Isolates are irrelevant.

Migration to Cloudflare Pages (if not using Void)

Astro officially provides an @astrojs/cloudflare adapter, but with output: 'static', you don’t even need an adapter. Static sites can be deployed directly to Cloudflare Pages.

The only specific change is the removal of the adapter.

import vercel from '@astrojs/vercel';

export default defineConfig({
  adapter: vercel({
    webAnalytics: { enabled: true },
  }),
  output: 'static',
  // ...
});

// adapter行を削除するだけ
export default defineConfig({
  output: 'static',
  // ...
});

Migration checklist.

Item	Work details	Difficulty
Adapter	Delete `@astrojs/vercel`	Just delete one line
Web Analytics	Vercel Web Analytics → Cloudflare Web Analytics (JS snippet replacement)	Easy
Speed Insights	Delete `@vercel/speed-insights` (No equivalent in Cloudflare)	Delete only
Redirect	Convert `vercel.json` → `public/_redirects` file	Rewrite 5 items
DNS	Vercel name server → Cloudflare DNS	Change domain settings
Build settings	Select framework “Astro” on the Cloudflare Pages dashboard	Automatic configuration

_redirectsConversion to a file looks like this:

/script/k-on-tape /lab/generator-kontape 301
/dojin /doujin 301
/dojin/* /doujin/:splat 301
/ksbiz/generator/kontape /lab/generator-kontape 301
/ksbiz/generator/kontape/ /lab/generator-kontape 301

Technically it’s pretty simple. Previously, when I was stuck deploying Vercel (/en/en/articles/vercel-deploy-failure-lessons), the unexpected cause was Git’s email settings, but migrating to Cloudflare Pages has fewer such pitfalls. This is because CDN distribution of static sites is a simple mechanism.

Transition to Void

Void supports Vite-based meta frameworks, but it is unclear whether Astro is explicitly supported at the early access stage. Astro uses Vite internally, so theoretically it would be eligible, but operation has not been confirmed.

Even if Astro is supported, for static sites, there is almost no benefit from Void’s selling point of “automatic provisioning” (DB, KV, authentication, etc.). Void is at its best in full-stack applications, and is overspecified for static sites.

What will change after migration?

Cost

Item	Vercel (Hobby)	Cloudflare Pages (Free)
Number of requests	Unlimited	100,000 yen per day (equivalent to 3 million yen per month)
Bandwidth	100GB/month	Unlimited
Egress fee	Charges for over 100GB	None
Build	6,000 minutes/month	500 times/month

On the other hand, Cloudflare has unlimited bandwidth so there will be no impact. On the other hand, Cloudflare has a limit of 500 builds per month, so if you deploy multiple times a day, you may reach the upper limit (in the case of this blog, it’s about 50 builds per month, so it’s not a problem).

Performance

Both are fast enough as they are CDN distribution for static sites. Cloudflare has over 330 edge locations, and Vercel also has edges in major regions. If access is mainly within Japan, there is almost no difference.

However, as this blog states on CLAUDE.md, image bandwidth is a future issue, and “switching to Cloudflare CDN” is cited as an escalation path. By migrating to Cloudflare Pages, your CDN becomes Cloudflare itself, making image delivery optimization seamless. If you stick with Vercel, you will need to install a separate Cloudflare CDN in front of it, but with Cloudflare Pages, that is not necessary.

Vercel comes standard with automatic deployment using git push, preview deployment, and Web Analytics, and can be used without any configuration. Cloudflare Pages has similar functionality, but it lacks the sophistication of Vercel. Vercel Web Analytics in particular is lightweight and easy to use.

I have previously built a real-time analytics infrastructure with Cloudflare Workers, so I am familiar with Cloudflare’s management screen. However, Vercel’s dashboard is overwhelmingly simpler.

No reason to migrate now

In the case of this blog, I have no problems with Vercel. The migration itself is easy, but the only benefits you get are costs (less bandwidth restrictions) and optimization of future image distribution, so it’s not worth the migration cost.

Migration is worth considering in the following cases:

If traffic exceeds Vercel’s bandwidth of 100GB/month
If image bandwidth becomes a problem and you need to migrate to Cloudflare CDN (Pages will solve the problem)
If you want to switch to SSR and take advantage of Cloudflare Workers’ edge execution
If you come across a function that requires use of Cloudflare-specific services such as D1 or KV

Void still in early access

It is still unclear whether it will be suitable for production use as it is in early access. The pricing structure has also not been disclosed. Since it is based on Cloudflare Workers (starting from $5 per worker per month), it will be difficult to make it completely free, but we will have to wait for future information to find out how much of a free tier VoidZero will offer.

VoidZero has raised a total of $17.1M ($ 4.6M Seed + $12.5M Series A) from a16z and others, and one of its goals is to make the entire Vite ecosystem commercially sustainable. There is a possibility that Void will become its revenue source.

Void aims to provide an experience where you can deploy without thinking if you use Vite. Following Vercel/Next.js, the trend of vertical integration by a single company from front-end build tools to deployment infrastructure began with VoidZero/Vite. However, as someone who operates a static site, I am more concerned about CDN bandwidth limitations and edge locations than the differences in deployment platforms.