KV

@vitehub/kv gives Vite, Nitro, and Nuxt apps one kv handle for application state that fits a key-value shape.

Use KV when route code needs to read or write small JSON-serializable values without carrying provider-specific SDK calls through the app. The provider choice stays in config. Runtime code keeps the same kv.get(), kv.set(), and kv.del() calls.

import { kv } from '@vitehub/kv'

export default defineEventHandler(async () => {
  await kv.set('settings', {
    theme: 'system',
    onboardingComplete: true,
  })

  return { ok: true }
})

import { kv } from '@vitehub/kv'

export default defineEventHandler(async () => {
  return {
    settings: await kv.get('settings'),
  }
})

{
  "settings": {
    "theme": "system",
    "onboardingComplete": true
  }
}

What KV Solves

Provider storage SDKs are useful, but they couple route code to deployment infrastructure.

KV puts the provider behind the Nitro storage mount:

One Portable Flow

The same shape works across supported frameworks:

1. Install @vitehub/kv.
2. Register hubKv(), @vitehub/kv/nitro, or @vitehub/kv/nuxt.
3. Choose a driver or let ViteHub resolve one.
4. Import kv from @vitehub/kv in server/runtime code.
5. Read and write values with get, set, has, del, keys, and clear.

Driver Routing

ViteHub resolves KV config in this order:

Explicit config always wins. That means you can force fs-lite locally, force Cloudflare for a Worker, or force Upstash for any runtime.

Framework Support

Vite registers hubKv() and exposes resolved config through #vitehub/kv/config.

Use this path when Vite owns the app setup. Runtime access to kv still depends on a Nitro-compatible server runtime.

Supported Providers

Start Here

Start with Quickstart for a complete local setup. Use the primitive comparison when you are deciding between KV, Blob, Queue, Sandbox, or a database.

Next Steps