Getting Started
Learn how ViteHub fits into a Nitro app, from route structure to shared server config.
ViteHub adds server-side primitives to Nitro. Each feature owns its own package, Nitro module entrypoint, optional top-level config key, and documented runtime imports when the feature needs them.
Mental model
Every feature follows the same pattern:
- install the feature package
- register the feature Nitro module
- add a top-level config object only when you need to customize the default behavior
- define named resources under
src/<feature>/**:: - define named resources under
server/<feature>/**:: - call the documented runtime import from a route, task, or other server code
ViteHub documents one Nitro-facing config style: top-level db, blob, cache, sandbox, workflow, cron, kv, and queue keys inside defineNitroConfig when you need feature-specific overrides.
Feature map
Resource patterns
Most features follow one of these patterns:
- discovered files become public names
- global feature config sets provider defaults
- definition-level options override behavior next to the resource itself
- resolved handles expose provider-specific methods only after you ask for them
Crons keep scheduling simpler in the docs: choose the provider in cron, then declare schedules next to the handler with defineCron(handler, options?).