dokkebi-cli

A client-side serverless framework where the backend runs in the browser

Dokkebi is an innovative framework that compiles backend TypeScript into QuickJS WASM and runs it directly in the browser. APIs work without a server, and database communication is handled securely through an E2E-encrypted proxy.

"Zero-cost MVP operations"

Building and deploying a service consumes too many resources—from architecture design to infrastructure setup. AI has dramatically accelerated development, but the barrier of server management and maintenance costs remains.

Dokkebi starts from a firm philosophy: use the user's resources wherever possible to deliver a smooth service at no cost. Whether you have 10 or 100 services, we bring operating costs for unpredictable MVP-stage products to exactly zero.

Core features and benefits

Zero Cost: Eliminate infrastructure management and server maintenance costs entirely

One-Click Deploy: Deploy and roll back frontend and backend together in one click (Cloudflare environment)

No Server, No Ops: No need to manage traditional server infrastructure—load balancers, port forwarding, Linux hardening, and the like.

Two operating modes

Dokkebi supports two modes tailored to your project's needs.

Serverless Mode: Uses Cloudflare Functions to validate the Dokkebi environment and runs as a pure client-side backend.

Server Mode: Use when E2E encryption, payment verification, or business-logic protection is required, or when you want to avoid cloud vendor lock-in.

A security architecture that reframes the problem

"No server means nothing to hack."

Shipping backend source to the client (browser) may sound reckless at first. Dokkebi does not try to make hacking impossible; instead, it shifts the security paradigm by exponentially increasing the time and cost of attacks until they are no longer worthwhile.

Heavy obfuscation and encryption: Backend logic is compiled to WASM with aggressive encryption and obfuscation.

Whitelist query validation: Unapproved or abnormal queries are blocked at the proxy layer and never reach the database.

Active Defense: Detects anomalous client behavior and blocks access immediately.

Browser
├── Vue / React frontend
└── QuickJS WASM backend (runs in-browser)
       │
       │  ECDH P-256 + HKDF + AES-256-GCM + HMAC-SHA256
       ▼
  DB proxy (/api/_dokkebi/db)
  ┌─────────────────────────────────────────┐
  │ 🖥  Server mode    dok serve → Node.js   │
  │ ☁  Serverless      Cloudflare Pages Fn   │
  └─────────────────────────────────────────┘
       │
       ▼
  DB (Cloudflare D1 / Supabase / Appwrite)

Quick start

npm install -g dokkebi-cli

dok create my-app      # Interactive project scaffolding
cd my-app
dok dev                # Auto build + hot-reload dev server
open http://localhost:5173

Key features

True serverless

Backend runs in the browser as QuickJS WASM—no separate server process
Familiar Express-style API (dokkebi:runtime) for routes, middleware, and DB access
Built-in type-safe query builder (dokkebi-dsl)

Multi-layer security applied automatically

Multiple security layers are applied automatically during build and deploy—no extra configuration required.

Category	Security	Description
Transport encryption	ECDH P-256 + AES-256-GCM + HMAC-SHA256	Forward secrecy, bidirectional encryption, request signing
Replay protection	Nonce + Timestamp (±30s) + timingSafeEqual	Blocks replay and timing attacks
SQL defense	SQL Allowlist + Query Registry + db.raw() blocked	Build-time allowlist, query hash registration, arbitrary SQL blocked
Secret protection	Env Opaque Handle	Sensitive vars never embedded in plaintext in the bundle
Code protection	Dual-protected bundle	JS obfuscation → AES-256-GCM encryption
Data isolation	Tenant Policy (pseudo-RLS)	Per-table session tenant conditions enforced automatically
Access control	Authorization Policy	JWT role-based operation and table-level permission checks
Session protection	OPFS session encryption (PBKDF2 + AES-GCM)	Defends against browser session theft
Active defense	Active Defense Layer (opt-in)	Real-time blocking of anomalous behavior via behavioral analysis
Execution permit	Signed Unlock Token (opt-in)	Worker-signed capability before paid or high-cost features run
Auth hardening	WebAuthn Passkey (opt-in)	Stronger defense against phishing and replay
Deploy safety	Preflight checks + build signing	Pre-deploy security config review, supply-chain traceability
Header protection	CSP · X-Frame-Options auto-applied	Blocks XSS, clickjacking, MIME sniffing

Defense by attack scenario

Attack scenario	Defense stack	Defense flow
🔑 Secret theft	Env Opaque Handle	Build-time auto-transform → runtime Host closure isolation
🌐 Network eavesdropping / tampering	E2E encryption	ECDH key exchange → AES-GCM + HMAC bidirectional encryption
🛡 Code reversing	Dual-protected bundle	JS obfuscation → AES-256-GCM encryption
💉 SQL injection	Triple SQL defense	Allowlist → Query Registry → dangerous syntax validation
👤 Cross-user data access	Tenant Policy (pseudo-RLS)	Session binding → auto-injected WHERE / deny
🍪 Session theft	OPFS session encryption	PBKDF2 100K + AES-GCM + origin salt
🔓 Feature permission bypass	Signed Unlock Token	Short-lived execution permit signed with Worker-only secret

Parallel SELECT (DB read speed)

The browser bootstrap (/api/_dokkebi/db client injected by dokkebi-cli) uses a serial queue for DB calls to preserve replay protection and nonce ordering. However, read-only queries whose string starts with SELECT bypass this queue and can send network requests concurrently, reducing round-trip wait when multiple independent reads overlap.

Stays serial (queued): INSERT / UPDATE / DELETE, SQL starting with WITH (CTEs, WITH … INSERT, etc.), tenant setup, capability channels—paths that need counter and ordering guarantees.
Runtime helper: parallelReads([...]) in dokkebi:runtime bundles multiple read Promises with Promise.all within the same request; use it with the bootstrap behavior above to make parallel SELECT intent explicit in code.

Developer experience

dok dev — one command for build + server + hot reload
dok deploy — one command for build + deploy + domain wiring + security headers
dok policy:scaffold — auto-generate security policies from model/controller analysis
Operations admin (/_dokkebi/_panel) — real-time requests, errors, and security event dashboard
Automatic error collection — WASM errors + browser uncaught exceptions logged automatically
12-language CLI — Korean, English, 日本語, 中文, Deutsch, and more
Upgrade existing projects — dok update safely upgrades without touching user code

CLI commands

Command	Description
`dok create [name]`	Interactive project creation (Vue/React + D1/Supabase/Appwrite)
`dok dev [src]`	Dev server (auto build + hot reload, default port 5173)
`dok build [src]`	QuickJS WASM build + frontend integration
`dok serve [src]`	Production Node.js server (default port 5174)
`dok deploy [src]`	Cloudflare Pages deploy (R2/S3 frontend + domain automation)
`dok migrate [src]`	Apply SQL migrations
`dok update [src]`	Apply latest version to existing project (preserves user code)
`dok security [src]`	Security opt-in interactive (`--status` for text-only)
`dok policy:scaffold [src]`	Auto-generate Tenant/Authorization Policy from model analysis
`dok lang [code]`	Change CLI language (12 languages supported)

See dok <command> --help for detailed options per command.

Backend code example

// backend/controllers/users.controller.ts
import { router, db, use, cors, jwtAuth } from 'dokkebi:runtime';
import { users } from '../models/index.js';

use(cors({ origin: '*' }));
use(jwtAuth(process.env.JWT_SECRET, ['/api/auth/login']));

router.get('/api/users', async (ctx) => {
  const result = await db.select(users).exec();
  return ctx.json(result.rows);
});

router.post('/api/users', async (ctx) => {
  const { name, email } = ctx.body;
  await db.insert(users).values({ id: crypto.randomUUID(), name, email }).exec();
  return ctx.json({ ok: true }, 201);
});

// backend/models/index.ts
import { defineTable, text } from 'dokkebi-dsl';

export const users = defineTable('users', {
  id:         text('id').primaryKey(),
  name:       text('name').notNull(),
  email:      text('email').notNull().unique(),
  created_at: text('created_at').default('CURRENT_TIMESTAMP'),
});

Deployment modes

	Development (`dok dev`)	Server (`dok serve`)	Serverless (`dok deploy`)
Runtime	Node.js (local)	Node.js (server)	Cloudflare Pages Edge
Hot reload	✓	—	—
DB proxy	Node.js	Node.js	Pages Function
Default port	5173	5174	—

Supported databases

DB	proxyMode	Notes
Cloudflare D1	server / serverless	Recommended (serverless-native)
Supabase	server	REST API
Appwrite	server	REST API

Security options — start with what each attack is blocked by

The security section in dokkebi.config.js has several user-toggleable options. One document summarizes which attack each option blocks and how it is applied.

Current project: dok security — in a terminal (TTY), move with arrows + Enter, toggle ON/OFF and levels, see per-item threat summary and required .env/config. Saves patch dokkebi.config.js automatically (failed lines get snippet guidance) + .bak.
Text only: dok security --status (CI / non-TTY). Force TUI: dok security --interactive.
➡ docs/SECURITY_OPTIN.md — opt-in quick reference (option ↔ attack ↔ config, one line each).
➡ docs/SECURITY_OPTIONS.md — per-option attack cases / examples / ops notes, including option ↔ attack mapping table.

Recommended default: enable only capabilities.enabled: true and attestation turns on automatically; client prev-token attachment and recursive unlock are handled automatically. dok build warns if cost-bearing routes lack capability declarations.

Production checklist (external attacker perspective)

We do not assume malicious dependencies or a compromised build machine. This checklist covers what to verify in production assuming only access to the deployed URL—static bundles (JSON·JS·WASM) and public APIs.

Query / SQL boundary

Cloudflare Pages Secret has DOKKEBI_QUERY_MODE=strict (or equivalent fail-closed operation). Do not use auto / learn in production.
dist/dokkebi/query-registry.json is non-empty, and empty-registry deploy is blocked via dok deploy --strict-registry or queryRegistry.strict: true in dokkebi.config.js.
Prefer rawAllowed: false in sql-allowlist.json and avoid db.raw().
Allowed tables and operations are minimal (no unnecessary SELECT *, wide JOINs, or subquery sprawl).

Tenant / authorization (server trust boundary)

Do not authorize from bindSession() or tenant meta sent by the client alone. Restrict real data access via D1 schema/app-level enforcement or separate trusted server verification / RLS (where the platform supports it).
policy (Tenant) in dokkebi.config.js is enabled, and policy.strict is not disabled in production.
authorization rules are defined; operate close to strict when needed (default warn alone may be insufficient).

Minimize exposed surface

If you do not need /_dokkebi/_panel, put it behind routing/IP restrictions or a private network. If you use it, set a long DOKKEBI_ADMIN_PASSWORD and restrict IPs with DOKKEBI_PANEL_ALLOWED_IPS when possible.
Be aware that /api/_dokkebi/log can pollute storage or pressure quotas; use rate limits and monitoring if needed.
dok serve is for local/internal networks only. Do not expose 0.0.0.0 binding to the internet.

Build / deploy quality

Do not disable --preflight on dok deploy; use --preflight-strict to fail deploy on warnings when needed.
Optionally reviewed security.strictCsp: true (trade off with browser/CDN compatibility).
Allowlist external images/APIs/iframes per app via security.cspExtraHosts (e.g. imgSrc: ['https://api.dicebear.com']) — the baseline CSP stays strict. See docs/SECURITY_OPTIONS.md §12.
Reduce frontend XSS (with CSP allowing unsafe-inline / unsafe-eval, XSS can lead to compromise of in-browser execution context).

Assume reconnaissance is possible

Treat /dokkebi/sql-allowlist.json, query-registry.json, etc. as potentially public and confirm design ensures their contents alone cannot reach other users' data.

Plugins

Extend the WASM backend safely. Enable in plugins in dokkebi.config.js.

Plugin	Capability	Security
fetch	External HTTP from WASM	Domain whitelist + concurrent request limit + timeout
bundle	In-browser esbuild-wasm bundling	OPFS sandbox + CDN external

Operations admin IP restriction

/_dokkebi/_panel can be restricted with an IP allowlist by setting security.panelIpGuard: true in dokkebi.config.js and DOKKEBI_PANEL_ALLOWED_IPS in .env or Cloudflare Pages Secrets. Default is false.

// dokkebi.config.js
export default {
  security: {
    panelIpGuard: true,
  },
};

DOKKEBI_ADMIN_PASSWORD=your_secure_password
DOKKEBI_PANEL_ALLOWED_IPS=203.0.113.10,198.51.100.0/24

When security.panelIpGuard is false, DOKKEBI_PANEL_ALLOWED_IPS is ignored. When true but env is empty, dok build prints a warning. Comma-separated IPs or IPv4 CIDR are supported; dok dev, dok serve, and Cloudflare Pages Functions panel share the same config.

Existing projects get panelIpGuard: false default and .env.example DOKKEBI_PANEL_ALLOWED_IPS entry reinforced on dok update.

Signed Unlock Token

Paid features, high-cost AI calls, admin export, and similar should not rely on browser-only if (isPremium)—require a Worker-signed execution permit instead.

// dokkebi.config.js
export default {
  security: {
    capabilities: {
      enabled: true,
      secretEnv: 'DOKKEBI_CAPABILITY_SECRET',
      features: {
        'image.generate': {
          roles: ['premium', 'admin'],
          ttlMs: 10000,
          routes: ['POST /api/ai/image'],
        },
      },
    },
  },
};

With routes set, dok build auto-inserts a guard before the matching Dokkebi runtime route. Users need not call capability.unlock() in handlers manually; passing requests get ctx.capability populated.

You can also declare near controllers via JSDoc:

/**
 * @dokkebi-capability feature:image.generate route:"POST /api/ai/image" roles:['premium','admin'] ttl:10000
 */
router.post('/api/ai/image', async (ctx) => {
  // Bind ctx.capability.token/proof into execution params or server request material
});

For finer manual state binding, call the API directly:

import { capability } from 'dokkebi:runtime';

const unlock = await capability.unlock('image.generate', {
  state: { projectId, promptHash },
  jwt: userToken,
});
if (!unlock.ok) throw new Error(unlock.error);

// token/proof must be used as execution material, not as a simple flag

Set DOKKEBI_CAPABILITY_SECRET in .env or Cloudflare Pages Secrets to a random value of at least 32 bytes. This raises the cost of permission-flag/branch-patch attacks but is not DRM that fully blocks local dumps by already-authorized users.

Capability Chain

You can require a valid token from another capability before issuing a specific one.

features: {
  'auth.verified':  { public: true,  ttlMs: 60000 },
  'image.generate': {
    roles: ['premium','admin'],
    ttlMs: 10000,
    requires: { prev: ['auth.verified'] },
  },
}

const a = await capability.unlock('auth.verified');
const b = await capability.unlock('image.generate', {
  prev: [{ feature: 'auth.verified', token: a.capability.token }],
});

The Worker verifies HMAC signatures, expiry, sid match, and feature match for all prerequisite tokens.

Bundle Attestation

At build time, encrypted bundle bytes are split into 16KB chunks and a SHA-256 manifest is generated. Each session, the Worker sends random chunk indices as a challenge and compares the client response to the manifest. Tampered bundles cannot pass the challenge.

// dokkebi.config.js
security: {
  attestation: {
    enabled: true,
    sampleSize: 4,         // 1–16, default 4
    ttlMs: 5 * 60_000,     // 30s–30min, default 5 min
  },
  capabilities: {
    enabled: true,
    features: {
      'image.generate': {
        roles: ['premium','admin'],
        requires: { attest: true },   // issue only after attest passes
      },
    },
  },
}

When the server returns CAPABILITY_ATTEST_REQUIRED for a capability with requires.attest: true, the client automatically runs the _attest challenge and retries once. No user code changes required.

See SECURITY.md §3.6 for details and limitations.

Requirements

Node.js 20+ — required by Cloudflare Wrangler. dok deploy calls wrangler pages deploy internally, so deploy fails on Node 18. Build/local dev may work on 18, but 20 LTS or newer is recommended.

Installation

# Global install
npm install -g dokkebi-cli

# Or local install
npm install dokkebi-cli
npx dok --help

Change language

dok lang

License

ELv2

Name		Name	Last commit message	Last commit date
Latest commit History 16 Commits
.github/workflows		.github/workflows
docs		docs
example-app		example-app
examples/plugins		examples/plugins
packages		packages
src		src
tests		tests
.DS_Store		.DS_Store
.gitignore		.gitignore
.npmrc		.npmrc
AGENTS.ko.md		AGENTS.ko.md
AGENTS.md		AGENTS.md
LICENSE		LICENSE
README.ko.md		README.ko.md
README.md		README.md
SECURITY.ko.md		SECURITY.ko.md
SECURITY.md		SECURITY.md
icon-512.png		icon-512.png
package-lock.json		package-lock.json
package.json		package.json

Folders and files

Latest commit

History

Repository files navigation

dokkebi-cli

A client-side serverless framework where the backend runs in the browser

"Zero-cost MVP operations"

Core features and benefits

Two operating modes

A security architecture that reframes the problem

Quick start

Key features

True serverless

Multi-layer security applied automatically

Defense by attack scenario

Parallel SELECT (DB read speed)

Developer experience

CLI commands

Backend code example

Deployment modes

Supported databases

Security options — start with what each attack is blocked by

Production checklist (external attacker perspective)

Query / SQL boundary

Tenant / authorization (server trust boundary)

Minimize exposed surface

Build / deploy quality

Assume reconnaissance is possible

Plugins

Operations admin IP restriction

Signed Unlock Token

Capability Chain

Bundle Attestation

Requirements

Installation

Change language

License

About

Topics

Resources

License

Security policy

Uh oh!

Stars

Watchers

Forks

Releases 3

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Packages