Your build tool has amnesia. I built one that remembers.

This is not a "Vite is dead" post. I love Vite. It's the reason dev servers stopped being painful. What I'm about to describe doesn't make Vite worse — it points at something every fast build tool still does, including the Rust ones.

Here it is: your build tool has amnesia.

Every layer of computing eventually learned the same lesson — stop redoing work you've already done:

• CPUs → caches
• Databases → indexes & materialized views
• Networks → the CDN
• Compilers → incremental compilation
• The frontend → memoization & query caches

One layer never learned it: the build.

Every build rediscovers the same dependency behavior, re-transforms the same modules, and rebuilds the same artifacts — from near zero. Vite, Rollup, esbuild, even Turbopack and Rspack made each run faster. But each run still starts from nothing. They optimized the speed of forgetting.

Ionify is what happens when you refuse to accept that.

Not a faster bundler — a different category

Ionify is a Rust-powered build engine that replaces disposable execution with persistent build intelligence. Instead of rediscovering dependency behavior and rebuilding the same artifacts every time, it persists the project's knowledge — the dependency graph, transformed artifacts, dependency contracts — and reuses valid work across dev, CI, and production.

The shift is from build execution to build intelligence. Execution throws its knowledge away after every run. Intelligence keeps it.

The number

On a real production app — 11,000+ modules, 25,000+ dependencies — Ionify produces a warm build in 196ms, deterministically. The number isn't the headline; it's the proof the model works at scale.

What's actually persisted and reused:

Capability	Status
Persistent dependency graph	Stable
Content-Addressable Storage (CAS)	Stable
Native dependency resolver	Stable
Dependency Publication Layer (DPL)	Stable
Unified dev + build pipeline	Stable
Federation foundation	Stable
Cloud CAS	In progress
AI optimization layer	Planned

I'd rather tell you what's stable and what isn't than sell you a roadmap as a fact.

How it works, in four ideas

One Graph. A persistent dependency graph that survives restarts, branch switches, dev/build transitions, and workspace boundaries. The graph is infrastructure, not temporary state.

One CAS. Every transformed artifact is stored by identity. If the inputs haven't changed, Ionify reuses the existing artifact instead of recomputing it. Artifacts are immutable; valid work is never redone.

One Dependency Authority. Dependencies are analyzed once and published as reusable contracts, consumed by the dev server, the production bundler, federation, and (soon) the cloud. No drift. No multiple realities.

One Pipeline. Most tooling quietly maintains a dev reality, a build reality, a CI reality, and a production reality — and they disagree. Ionify runs one deterministic pipeline so development and production can't.

Getting started looks like any other tool:

pnpm create ionify@latest

export default {
  entry: "/src/main.ts",
  outDir: "dist",
};

pnpm ionify dev
pnpm ionify build

The bug that made me build the DPL

The "One Dependency Authority" idea didn't come from a whiteboard. It came from a production bug.

In a real build, shared chunks were importing symbols from entry chunks that those entry chunks never actually exported. Invalid ESM relationships that passed tests and then waited to break at runtime. The root cause wasn't a single bad line — it was that no part of the pipeline owned the truth about what a module exports. Each stage re-derived the export surface, and they quietly disagreed.

The fix became the Dependency Publication Layer: publish a dependency's export surface exactly once as a content-hashed export ABI manifest, make that manifest the single export authority, and put a fail-closed loader in front of it that refuses to hydrate raw node_modules without a verified contract. Published contracts also carry an export-surface hash, singleton ownership, and a deterministic artifact identity.

The principle: one dependency, one contract, one authority. That's what kills duplicate Reacts, version drift, and phantom exports — not at lint time, but structurally.

Publish before build

Here's the part that surprises people. The work to produce production was already latent in your dev session — and every tool throws it away. Ionify doesn't.

While you develop, Ionify can publish production-keyed artifacts ahead of time, so your first production build after a dev session approaches warm-build speed:

export default defineConfig({
  productionArtifactPublishing: "auto",
});

The guardrails are the whole point — this is not a cache trick:

• ionify build stays the verifier. Published artifacts are optional accelerators it must re-validate.
• Publication writes only under .ionify — never dist/, never deploy output.
• Production namespace only. Dev artifacts can't masquerade as production ones.
• Fail-closed. If anything is missing, stale, or incompatible, build repairs via the normal production path.

Speed without giving up correctness — or it doesn't ship.

Why this is a different axis

Vite won on dev speed. Turbopack and Rspack are racing on raw speed too. But that's all the same axis — faster execution. Ionify competes on a different one: accumulated intelligence. When you change the axis, the question changes from "is this faster?" to "why did we ever accept that the build forgets everything, every single time?"

Try it

pnpm create ionify@latest

• Site: https://ionify.cloud
• GitHub (a star helps a lot): https://github.com/ionifyjs/ionify

This is post 1 in a series. Next up: how Ionify publishes dependency contracts — the DPL in depth, and why "one dependency, one authority" is the end of duplicate Reacts and phantom exports.

What would your CI look like if it never started over? I'd genuinely like to hear where your builds waste the most time — drop it in the comments.