Kevi: Multi-tenant key-value API for the edge

Applications need to store configuration data. Feature flags, settings, and values that change without updating code. When you have multiple services, each one needs its own storage. They should not see each other's data.

Kevi is a key-value API for Cloudflare Workers. It lets you run one API for multiple services. Each service has its own token and its own data. They share the same infrastructure but cannot access each other's data.

Motivation

Imagine you have a mobile app, a web app, and an admin dashboard. Each one needs to store configuration data. Each one needs different access rules. They should not see each other's data.

You could build separate APIs for each service. Or you could build one API with complex permissions. Both ways create problems. You need to maintain more code. You need to manage more servers. Everything becomes more complex.

Kevi solves this. One API. Multiple services. Complete isolation. Fast performance.

How it works

Kevi uses an identity-first architecture. This means tokens map directly to services. There is no complex parsing. There are no slow lookups. Just fast, direct mapping.

curl https://kevi.onurhandtr.workers.dev/v1/kv/settings \
-H "X-Kevi-Token: your-token-here"

The magic is in the prefix. If your service is mobile-app and you store a key called settings, Kevi stores it as mobile-app:settings. Another service called web-app stores "settings" as "web-app:settings". They never conflict. They never see each other's data.

Setup your own Kevi

Kevi is not a fully serverless service you can use directly. To use Kevi in your project, you need to fork the repository, configure it with your own settings, and deploy it to your own Cloudflare account. This gives you complete control over your data, tokens, and configuration.

Here is how to set it up:

Step 1: Fork and clone

First, fork the Kevi repository on GitHub. Then clone your fork:

git clone https://github.com/your-username/kevi
cd kevi
bun install

Step 2: Create KV namespace

You need your own Cloudflare KV namespace. Create your storage bucket:

bunx wrangler kv namespace create KEVI_STORAGE

Wrangler is Cloudflare's command-line tool. It helps you manage your Workers and storage. It connects your code to Cloudflare's platform. When you run this command, Wrangler creates a storage space and connects it to your project. It will ask if you want to add the ID to your configuration. Say yes.

Step 3: Create your service registry

First, create your service in src/config.ts. This is your service registry. It tells Kevi what each service can do:

export const registry: ServiceRegistry = {
  "my-service": {
    storage: "KEVI_STORAGE",
    role: "admin",
    prefix: "my-service",
    description: "My application service",
    allowedOrigins: ["https://myapp.com"],
    publicKeys: ["public/*"],
  },
};

Step 4: Update wrangler.jsonc

After creating your service in src/config.ts, you need to add the token mapping to wrangler.jsonc. This connects tokens to your services:

{
  "vars": {
    "TOKEN_your-token-here": "my-service"
  }
}

The easiest way is to use Kevi's generator tool. It creates a secure token and shows you what to add to both files:

# Using Bun
bun gen:service -s my-service

# Using npm
npm run gen:service -s my-service

The generator validates your service name and creates a secure 32-byte token. Use 3 to 30 characters, lowercase letters, numbers, and hyphens. After the command finishes, copy the TOKEN_... entry into wrangler.jsonc and add the service definition into src/config.ts.

If you prefer to do it manually, generate a token:

openssl rand -base64 32

Then add it to wrangler.jsonc:

{
  "vars": {
    "TOKEN_f06ab447627dc0a8a4e970b902b23730aed2dce50cb50f5687e35b5ebb896d9c": "my-service"
  }
}

Step 5: Deploy to your Cloudflare account

Deploy your forked Kevi instance to your own Cloudflare Workers account:

bun run deploy

After deployment, you will have your own Kevi instance running on your Cloudflare account. You can then use it in your services.

Use Kevi in your services

Once deployed, using Kevi is simple. Send requests with your token:

Store a value:

{
  "value": {
    "feature_enabled": true,
    "version": "1.0.0"
  }
}

curl -X POST https://kevi.onurhandtr.workers.dev/v1/kv/settings \
  -H "X-Kevi-Token: your-token-here" \
  -H "Content-Type: application/json" \
  -d '{
  "value": {
    "feature_enabled": true,
    "version": "1.0.0"
  }
}'

Get a value:

curl -X GET https://kevi.onurhandtr.workers.dev/v1/kv/settings \
  -H "X-Kevi-Token: your-token-here"

List all keys:

curl -X GET https://kevi.onurhandtr.workers.dev/v1/kv \
  -H "X-Kevi-Token: your-token-here"

That is it. Simple. Fast. Secure. But remember, you need to fork the repository and deploy it yourself with your own Cloudflare account.

Explore the hosted docs and API explorer

Why this matters

Kevi runs on Cloudflare Workers. This means your data is stored at the edge. Low latency. Global distribution. No cold starts. Your configuration changes reach users instantly, anywhere in the world.

The multi-tenant design means you can serve many services from one deployment. Lower costs. Less maintenance. More time to build features, less time managing infrastructure.

The identity-first architecture means fast lookups. No database queries. No complex joins. Just direct environment variable lookups. Milliseconds, not seconds.

Is Kevi right for you?

Kevi might be a bit overcomplicated for some use cases. Maybe you do not need multi-tenant isolation. Maybe you do not need edge-native performance. But if you have multiple services that need secure, isolated configuration storage, Kevi can help.

It is a good idea. It is open source. You can customize it. You can extend it. You can make it yours.

Support this content