Architecture
ViteHub is a set of Vite plugins that extend upward through the Nitro and Nuxt module systems. Each layer builds on the one below it.
The stack
┌─────────────────────────────┐
│ Nuxt │ Full-stack framework
│ (extends Nitro + adds UI) │ @vitehub/*/nuxt
├─────────────────────────────┤
│ Nitro │ Server framework
│ (extends Vite + adds │ @vitehub/*/nitro
│ server runtime, routes, │
│ tasks, storage) │
├─────────────────────────────┤
│ Vite │ Build tool
│ (plugins, config, dev │ @vitehub/*/vite
│ server) │
└─────────────────────────────┘
Each ViteHub feature ships three entrypoints:
| Entrypoint | What it does |
|---|---|
@vitehub/*/vite | Vite plugin. Reads the top-level feature config and compiles definitions at build time. |
@vitehub/*/nitro | Nitro module. Calls the Vite plugin internally, then adds server runtime wiring (routes, storage bindings, type generation). |
@vitehub/*/nuxt | Nuxt module. Calls the Nitro module internally, then adds Nuxt-specific hooks if the feature needs them. |
Why three entrypoints
Nitro calls Vite under the hood. Nuxt calls Nitro under the hood. ViteHub mirrors this layering so you only register the entrypoint that matches your framework:
- Vite project — register the Vite plugin directly. You get build-time compilation and the top-level config key.
- Nitro project — register the Nitro module. It sets up the Vite plugin for you and adds server runtime integration.
- Nuxt project — register the Nuxt module. It sets up the Nitro module for you and adds any Nuxt-specific behavior.
The feature config (queue, blob, db, etc.) stays identical across all three. Only the registration line changes.
What each layer adds
Vite layer
The Vite plugin handles work that happens at build time:
- Reads the top-level feature config from
vite.config.ts - Discovers definition files (
src/queues/**,src/workflows/**, etc.) :: - Discovers definition files (
server/queues/**,server/workflows/**, etc.) :: - Compiles definitions into runtime artifacts
- Generates type declarations
Nitro layer
The Nitro module extends the Vite plugin with server-side behavior:
- Registers the Vite plugin automatically
- Wires storage bindings for the hosting provider
- Adds server routes when the feature needs them (queue consumers, workflow callbacks)
- Infers the hosting provider from the Nitro preset
Nuxt layer
The Nuxt module forwards everything to Nitro and adds framework-level hooks:
- Registers the Nitro module automatically
- Adds Nuxt DevTools integration where applicable
Shared internals
All three entrypoints share the same @vitehub/_shared package for:
- Feature definition compilation
- Runtime artifact generation
- Storage configuration resolution
- Provider inference from Nitro presets
The shared foundation keeps the behavior identical regardless of which entrypoint you use. The framework selector in the sidebar adjusts code examples only — the underlying feature works the same way.