SDK - Zeroko

SDK

Deploy an existing project with its own build, for the main JavaScript frameworks.

Agents deploy by writing a deployment themselves. A project you already have deploys with its own build: an adapter for its framework turns the build into a deployment and, with your workspace's address and a token, deploys it. There's no CLI to install, and nothing changes in how you develop.

Package	For
`@zeroko-io/vite`	Vite: sites, single-page apps, and an API beside the front end
`@zeroko-io/nitro`	Nuxt, SolidStart, TanStack Start
`@zeroko-io/sveltekit`	SvelteKit
`@zeroko-io/astro`	Astro
`@zeroko-io/react-router`	React Router, framework mode
`@zeroko-io/next`	Next.js, through OpenNext
`@zeroko-io/core`	Backends: Hono, Express, Koa; and the bindings' types for all

The SDK is open source, MIT, at github.com/zeroko-io/sdk, with an example app for each framework.

Installing

The packages are on GitHub Packages, which asks for a GitHub token even for public packages. Tell npm where they are, with a token that reads packages (read:packages), in your project's .npmrc:

text

@zeroko-io:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}

What the service is: zeroko.json

At the project's root, kept in the repository:

json

{
  "service": "shop",
  "bindings": { "DB": "db", "UPLOADS": "files", "JOBS": "jobs" },
  "crons": [{ "schedule": "0 3 * * *", "payload": { "task": "cleanup" } }],
  "vars": { "GREETING": "hello" }
}

The fields are a deployment's: service is its name, and its address. Without one, the package's name is used. A build with public files gets the ASSETS binding on its own. An adapter's options, if you pass any, go over the file's.

Where it goes: .env

The workspace's address and a token, in .env (or .env.local, or the environment). Keep them out of the repository: the build refuses a zeroko.json that has either, so that a repository can't send your token somewhere else.

ZEROKO_URL=https://acme.zeroko.space
ZEROKO_TOKEN=zk_...

Deploying

npm run build

The build writes the deployment to .zeroko/deployment.json, the same JSON an agent sends. With ZEROKO_URL and ZEROKO_TOKEN set, it deploys it, and says the service's address:

text

zeroko: 41 files in .zeroko/deployment.json
zeroko: shop v3 is live at https://shop--acme.zeroko.space

Without them, it only writes the file: an agent, or anything that can POST it, can deploy it. The same build deploys from CI: set both as the job's secrets.

Bindings in TypeScript

@zeroko-io/core has the bindings' types: Database, Files, Jobs, Realtime, Assets and ServiceBinding, and Service for a module's default export. Types only: nothing of it ends up in the service unless you import a runtime helper.

import type { Database, Files } from "@zeroko-io/core"

type Env = { DB: Database; UPLOADS: Files }

Each framework hands the bindings to your code its own way: see each one's page.

Limits

A deployment is up to 2000 files and 50 MB, with its public files. Source maps aren't deployed. Server code runs on workerd: code that compiles code at runtime (eval, new Function) doesn't run.

PreviousOperate NextVite