Server primitives
Server primitives for Vite apps and any host
ViteHub adds storage, queues, schedules, email, and other server APIs to Vite apps. Call them from routes, handlers, jobs, or workers. You don't need an Agent Definition.
Start with Your first server primitive for a runnable example. Return to Concepts when you need to understand generated imports or host configuration. Read the Agents section only when a model needs access to one of these APIs.
Pick the right primitive
| You need | Start with |
|---|---|
| Public, server, build-time, runtime, or secret environment values | Env |
| Application users, sessions, Better Auth routing, or guarded app routes | Auth |
| Request budgets that must be consumed before expensive server work starts | Rate Limit |
| Outbound transactional messages with provider-neutral delivery | |
| Small key-addressed values, settings, flags, cursors, or lightweight state | KV |
| Relational data, constraints, joins, migrations, or queryable history | Database |
| Uploads, generated artifacts, binary files, or object metadata | Blob |
| Provider-backed browser sessions, screenshots, DOM inspection, or live handoff | Browser |
| Persistent file-tree state, snapshots, diffs, rules, or sessions | Workspace |
| Collaborative Markdown editing, presence, and Workspace checkpoints | Realtime |
| Read-only retrieval from files, globs, GitHub, markdown, MCP, or custom loaders | Source |
| Background delivery that returns before work finishes | Queue |
| Durable long-running work with provider-tracked run state | Workflows |
| Static cron output or recurring runtime schedules | Schedule |
| Isolated provider-managed execution | Sandbox |
| Controlled Unix-like command sessions | Shell |
Use primitives from server code
Most primitives expose the same application import on every host. ViteHub connects that import to the selected provider during the build.
import { kv } from 'vite-hub/kv'
export default defineEventHandler(async (event) => {
const [error] = await kv.set('settings', await readBody(event))
if (error) throw error
return { ok: true }
})
The route doesn't need to know whether KV uses local files, Cloudflare, Vercel, or another driver.
Definitions and generated output
Some primitives work directly after configuration. Env, KV, Blob, Source, and Shell can often be called from server code without a discovered Definition.
Other primitives need a Definition so ViteHub can discover runtime behavior or named work. Email composes one declaratively configured provider, while Auth uses a singleton Definition bound at runtime. Database schemas, Workspace Definitions, Queue Definitions, Workflow Definitions, Static Schedule Definitions, Sandbox Definitions, and Agent Definitions can also generate Runtime Registries or host-specific Provider Output. Rate Limit uses source-local handles with explicit stable IDs instead of location-derived Definitions.
| Need | Read |
|---|---|
| Understand portable Definitions and location-derived discovery | Definitions and discovery |
| Check where Definition files belong | File conventions |
| Inspect generated host artifacts | Provider output |
| Configure package integrations and host settings | Config options |
| Use ViteHub's framework and host boundary | Frameworks and hosts |
| Emit Cloudflare bindings, routes, queues, workflows, crons, and workers | Cloudflare |
| Emit Vercel output for functions, queues, workflows, and runtime bindings | Vercel |
| Emit Deno Agent server output and Deno cron wake output | Deno |
| Run the generated server output yourself | Node/self-hosted |
Connect primitives to Agents
Capabilities expose controlled agent-facing access to primitives. A storage Capability can expose scoped read/edit tools, a Schedule Capability can manage allowed Runtime Schedules, and workspaceShell() can expose file inspection through Workspace and Shell boundaries.
Don't expose a server API to a model just because the app uses it. Add the relevant Official Capability only when the Agent needs that ability. Configure its scope, write mode, and approvals for that task.
| Need | Read |
|---|---|
| Build the Agent that will receive the ability | Agents |
| Understand the agent-facing contribution model | Capabilities overview |
| Pick from built-in Capability factories | Official capabilities |
| Expose KV with scoped storage tools | KV capability |
| Expose Blob storage with scoped file tools | Blob capability |
| Expose relational data intentionally | Database capability |
| Let an Agent send authorized plain-text email | Email capability |
| Consume a trusted budget before an Agent Invocation | Rate Limit capability |
| Give an Agent headless browser evidence through an allowlisted command | Browser capability |
| Let an Agent manage allowed Runtime Schedules | Schedule capability |
| Expose Workspace-backed inspection or mutation | Workspace shell |
| Run isolated execution from an Agent boundary | Sandbox capability |