#Nuxt Is Now Native on Zephyr

Nuxt has always made the app side feel elegant and the deployment side feel weird.

nuxt build finishes, Nitro gives you a real output, and then the platform asks you to translate the whole thing into adapters, custom scripts, and hosting-specific glue just so it can understand what Nuxt already produced.

Now Zephyr supports Nuxt natively through zephyr-nuxt-module for Nuxt 3 and Nuxt 4. It hooks into nuxt build, reads the Nitro output, detects the server entrypoint when there is one, and uploads the result directly to Zephyr. No parallel packaging story. No extra dance to make the framework legible to the platform.

#The Second Decision You Shouldn't Have To Make

Most Nuxt deployment pain comes from making the same decision twice.

First you decide how the app should behave in Nuxt: SSR, static output, API handlers, assets, middleware, the usual stuff. Then you make a second version of those decisions in CI and hosting config so the deployment platform can reconstruct the app from the outside.

One provider wants a special output shape. Another wants an adapter. Another wants your assets, server code, and functions split across different places. Before long, the deployment pipeline becomes its own product, and somehow that product is now coupled to your app.

What Zephyr is doing here is pretty simple: the Nuxt build should be the deployable unit.

#Build Once, Stop Translating

The useful part of this integration isn't just "Nuxt works on Zephyr now." It's the model behind it.

Zephyr treats the result of nuxt build as a first-class release artifact. That means the build is not just something that finished successfully in CI. It becomes an immutable version that can be deployed, previewed, promoted, and rolled back without being rebuilt from scratch every time.

That changes the shape of the workflow in a very practical way:

• Nuxt builds the app
• Zephyr stores that output as a version
• Zephyr deploys that version to the edge
• release control happens after build time, not through more packaging logic

If you're already happy with your Nuxt workflow, that's the point. You keep the framework flow you already know. Zephyr takes over the operational side of shipping it.

Every build gets captured as something usable. Zephyr gives it a preview URL, keeps it as an immutable version, and lets teams move that same artifact forward instead of recreating it for every environment. That sounds like a small detail until you've dealt with staging and production drifting because each one got rebuilt under slightly different conditions.

Zephyr's tags and environments layer nicely on top of that. Tags resolve to the right version based on rules you define. Environments decide where that version runs and what settings apply. So instead of wiring release behavior into your build scripts, you get a cleaner split:

• build decides what the app is
• release decides where that version goes

That separation is huge.

Zephyr's environment-level overrides also make "build once, deploy everywhere" mean something real. The same built artifact can change behavior at serve time, including different remote dependency targets and different public ZE_PUBLIC_ values, without forcing a rebuild just because the environment changed.

For Nuxt teams, that means fewer fragile scripts, fewer "wait, which environment built this?" moments, and a much cleaner path across development, staging, and production.

#Rollback Should Be Boring

On Zephyr, previous versions stay on the edge. So when a release goes sideways, rollback is a routing change, not a rebuild. That's the kind of operational detail that sounds boring on a marketing page and feels incredible when production is on fire.

#The Setup Is Pretty Small

The Nuxt side is intentionally lightweight. Install zephyr-nuxt-module, add it to modules in nuxt.config.ts, and let it plug into the existing build flow.

If you're onboarding an existing app, npx with-zephyr is the fast path to get a Nuxt project wired up without doing the setup by hand first.

For SSR, the current recommended path uses Nitro's Cloudflare module output. Right now, Nuxt SSR deployments work on Zephyr's default managed Cloudflare integration, so there is still a concrete availability boundary there. That's worth being explicit about.

But even with that note, the milestone is real. Nuxt is now inside the platform instead of orbiting around it through adapters and deployment glue.

You build the app once. Zephyr turns that build into a versioned release artifact. You get preview URLs, immutable versions, tags, environments, serve-time configuration, and fast rollback without rebuilding the world every time something moves between environments.

It's the difference between hosting a Nuxt app and actually shipping one.