Compare ViteHub primitives
Choose between ViteHub capabilities, orchestrators, interfaces, and shared state.
ViteHub packages solve different server-side jobs. Pick the primitive by the shape of the work first, then choose the provider page for your deployment target.
Use this page when you are deciding whether a feature should store state, store files, run outside the response path, run in isolation, coordinate a model loop, expose a chat interface, or stay inline in the request.
For the architecture behind these boundaries, read ViteHub philosophy.
Pick by outcome
| You need to | Use | Why |
|---|---|---|
| Read or write small JSON-like values by key | KV | The route needs fast key-based state without provider SDK code. |
| Accept, store, list, or stream files | Blob | The data is a file, stream, binary body, or object with metadata. |
| Return before background work finishes | Queue | The request should enqueue work and let the provider deliver it outside the response path. |
| Coordinate durable steps, waits, retries, or resumable work | Workflow | The work needs orchestration beyond one request or one model call. |
| Run user-defined or risky code behind an isolated boundary | Sandbox | The work needs an execution boundary and a result payload. |
| Run a model/tool loop | Agent | The feature needs model instructions, tools, and ViteHub message input. |
| Receive and respond to chat platform events | Chat | The feature needs Chat SDK adapters, webhook handling, and conversation state. |
| Persist conversation or stream state across interfaces | Messages | Agent and chat need the same serializable message/event model. |
| Finish a small amount of work before responding | Inline request code | The work is quick, reliable, and belongs to the response path. |
| Query relationships, joins, transactions, or history | A database | The data has a relational or durable application model. |
Choose the primitive for the runtime behavior you need. Provider setup comes after that choice: Cloudflare and Vercel pages explain bindings, tokens, buckets, topics, and deployment-specific checks.
Package fit
::
::
Only KV currently has Nuxt package docs. Blob, Queue, and Sandbox are documented for Vite and Nitro.
Common decisions
| Decision | Choose this |
|---|---|
| Store a user avatar upload | Blob |
| Store the selected theme for a workspace | KV |
| Send a welcome email after signup | Queue |
| Run an onboarding process that waits for provider callbacks | Workflow |
| Generate release notes from a request payload in an isolated runtime | Sandbox |
| Answer a support question with tools and model instructions | Agent |
| Receive Slack, Discord, or Teams messages and respond in a thread | Chat |
| Save assistant stream events and replay them after reload | Messages |
| Increment a request-local counter before returning JSON | Inline request code |
| Store users, teams, permissions, and audit history | A database |
Combine primitives
Many features use more than one primitive:
- Store upload metadata in KV and the file body in Blob.
- Accept a request, write a small status record to KV, then enqueue Queue work.
- Run a Sandbox job, store its output in Blob, and save the latest result key in KV.
- Let Chat adapt a direct message into Messages, then hand it to Agent.
- Let Workflow coordinate a long-running Agent task that uses Sandbox as a scoped capability.
Keep the public route small. It should validate input, call the primitive that owns the work, and return a result the client can handle.