Skip to content

Platform Adapters

Platform adapters contribute host-level infrastructure to Zelavis: database drivers, KV stores, file storage, and dashboard settings persistence. They are the adapter: option you pass to new Zelavis({...}).

In Zelavis there is only one kind of adapter — the environment adapter. There are no “framework adapters” — framework integration is handled by small utility functions like expressMiddleware(zelavis) from zelavis/express.

// Direct paths
import { nodeAdapter } from "zelavis/adapters/node";
import { bunAdapter } from "zelavis/adapters/bun";
import { cloudflareAdapter } from "zelavis/adapters/cloudflare";
import { vercelAdapter } from "zelavis/adapters/vercel";
import { netlifyAdapter } from "zelavis/adapters/netlify";
// Or via the barrel (with zelavisX aliases)
import {
zelavisNode,
zelavisBun,
zelavisCloudflare,
zelavisVercel,
zelavisNetlify,
} from "zelavis/adapters";

Node-oriented defaults:

  • better-sqlite3 database driver
  • File-backed dashboard settings store
  • In-memory KV store
  • Local file storage rooted in the Zelavis data directory
import { Zelavis } from "zelavis";
import { nodeAdapter } from "zelavis/adapters/node";
import { createNodeServer } from "zelavis/node";
const zelavis = new Zelavis({
adapter: nodeAdapter({ dataDirectory: ".zelavis" }),
});
const server = await createNodeServer(zelavis);
server.listen(3000);

Bun-oriented defaults:

  • Bun SQLite database driver
  • File-backed dashboard settings store
  • In-memory KV store
  • Local file storage rooted in the Zelavis data directory
import { Zelavis } from "zelavis";
import { bunAdapter } from "zelavis/adapters/bun";
const zelavis = new Zelavis({ adapter: bunAdapter() });
export default { fetch: (req) => zelavis.fetch(req) };

Cloudflare-oriented bindings. Pass the Worker env object and the adapter discovers the standard Zelavis bindings (ZELAVIS_DB, ZELAVIS_KV, ZELAVIS_FILES):

  • D1 database driver
  • KV namespace as the KV store
  • R2 bucket as file storage
import { Zelavis } from "zelavis";
import { cloudflareAdapter } from "zelavis/adapters/cloudflare";
export default {
async fetch(request, env, ctx) {
const zelavis = new Zelavis({ adapter: cloudflareAdapter({ env }) });
return zelavis.fetch(request, ctx);
},
};

The env object is passed at call time. Cloudflare Workers inject bindings at request time, so cloudflareAdapter({ env }) captures them via closure.

Custom binding names can be overridden through the bindings option.

Vercel-shaped adapter. Accepts injected database configuration, KV store, and file storage. Does not pick one default Vercel product automatically — you supply the resources explicitly.

For file storage, Vercel Blob is the natural fit via createVercelBlobFileStorage(...).

import { Zelavis } from "zelavis";
import { vercelAdapter } from "zelavis/adapters/vercel";
const zelavis = new Zelavis({
adapter: vercelAdapter({
files: { blobStore: myVercelBlobClient },
}),
});
export async function GET(request: Request) {
return zelavis.fetch(request);
}

Netlify-shaped adapter. Netlify Blobs is the natural fit for both KV and file storage:

import { getStore } from "@netlify/blobs";
import { Zelavis } from "zelavis";
import { netlifyAdapter } from "zelavis/adapters/netlify";
const zelavis = new Zelavis({
adapter: netlifyAdapter({
kv: { blobsStore: getStore("zelavis-kv") },
files: { blobsStore: getStore("zelavis-files") },
}),
});

Adapters contribute runtime resources accessible through zelavis.platform.resources:

  • kv — used for dashboard settings persistence
  • files — used for file storage and website page persistence

These resources are not Zelavis services. They are host-level infrastructure capabilities. The Zelavis runtime uses them as fallback persistence when no explicit service configuration is provided.

S3-compatible object storage is not an adapter — it is a storage backend. Use the first-party helper:

import { createS3CompatibleFileStorage } from "zelavis/storage/s3";

Pass the result as the files resource when constructing your adapter.