ViteHub is still experimental. Expect bugs and breaking changes.

Server primitives

Add storage, queues, schedules, email, and other server APIs to a Vite app on any supported host.

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.

First primitive
Add KV to an app, register the Vite Integration, and call the Runtime Helper from server code.
Server model
Learn how generated imports and host configuration keep application code independent from providers.
Runtime imports
Call primitives through ViteHub-owned imports instead of generated files or provider SDK wiring.
Agents
Give an Agent selected access to server APIs through Capabilities.
Server code calls runtime helpers directly. Agents receive only the abilities added through Capabilities. Read Runtime helpers and stable imports and Capabilities API when you need those contracts.

Pick the right primitive

You needStart with
Public, server, build-time, runtime, or secret environment valuesEnv
Application users, sessions, Better Auth routing, or guarded app routesAuth
Request budgets that must be consumed before expensive server work startsRate Limit
Outbound transactional messages with provider-neutral deliveryEmail
Small key-addressed values, settings, flags, cursors, or lightweight stateKV
Relational data, constraints, joins, migrations, or queryable historyDatabase
Uploads, generated artifacts, binary files, or object metadataBlob
Provider-backed browser sessions, screenshots, DOM inspection, or live handoffBrowser
Persistent file-tree state, snapshots, diffs, rules, or sessionsWorkspace
Collaborative Markdown editing, presence, and Workspace checkpointsRealtime
Read-only retrieval from files, globs, GitHub, markdown, MCP, or custom loadersSource
Background delivery that returns before work finishesQueue
Durable long-running work with provider-tracked run stateWorkflows
Static cron output or recurring runtime schedulesSchedule
Isolated provider-managed executionSandbox
Controlled Unix-like command sessionsShell

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.

server/api/settings.put.ts
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.

NeedRead
Understand portable Definitions and location-derived discoveryDefinitions and discovery
Check where Definition files belongFile conventions
Inspect generated host artifactsProvider output
Configure package integrations and host settingsConfig options
Use ViteHub's framework and host boundaryFrameworks and hosts
Emit Cloudflare bindings, routes, queues, workflows, crons, and workersCloudflare
Emit Vercel output for functions, queues, workflows, and runtime bindingsVercel
Emit Deno Agent server output and Deno cron wake outputDeno
Run the generated server output yourselfNode/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.

NeedRead
Build the Agent that will receive the abilityAgents
Understand the agent-facing contribution modelCapabilities overview
Pick from built-in Capability factoriesOfficial capabilities
Expose KV with scoped storage toolsKV capability
Expose Blob storage with scoped file toolsBlob capability
Expose relational data intentionallyDatabase capability
Let an Agent send authorized plain-text emailEmail capability
Consume a trusted budget before an Agent InvocationRate Limit capability
Give an Agent headless browser evidence through an allowlisted commandBrowser capability
Let an Agent manage allowed Runtime SchedulesSchedule capability
Expose Workspace-backed inspection or mutationWorkspace shell
Run isolated execution from an Agent boundarySandbox capability

Next steps