Skip to content

Deployment

Jump to bottom
Kritarth-Dandapat edited this page Jul 10, 2026 · 1 revision

Deployment

This page is the owner-facing runbook for standing up your own context-kernel: your own Cloudflare Worker, your own KV namespace, your own curated content. Nobody but you ever sees content/. See Architecture for what each step actually produces, and Security-Model for what the tokens you generate here protect.

Prerequisites

  • A Cloudflare account with a domain (or you can use a workers.dev subdomain for testing).
  • wrangler CLI installed and logged in (wrangler login).
  • Node >= 20.

Steps

1. Install dependencies and create your Worker config.

npm install
cp wrangler.toml.example wrangler.toml

Edit wrangler.toml to fill in the KV namespace IDs (next step) and, optionally, a route under your own domain. This file is gitignored — it's yours, not committed.

2. Create the KV namespace.

wrangler kv namespace create CONTEXT_KV
wrangler kv namespace create CONTEXT_KV --preview

Paste the returned id and preview_id into wrangler.toml.

3. Set your two secrets.

wrangler secret put READ_TOKEN
wrangler secret put WRITE_TOKEN

Generate long random tokens (not memorable passwords) and store them in a password manager. See Security-Model for what each token is allowed to do — the write token is the higher-risk one to lose, hand it out only to servers/agents that need to leave journal notes.

4. Author your real curated content.

cp -r content.example content
#   ...edit content/*.md with your real profile, goals, preferences, etc...

content/ is gitignored on purpose (see CLAUDE.md's "sacred and gitignored" rule) — nothing you write here should ever end up in a commit. Stick to the section files already templated in content.example/ (profile, goals, current-work, resume, writing-prefs, figure-prefs, answer-prefs, skills, env-constants), and leave out contact-heavy fields like phone numbers or a direct email address — add only what an authorized Claude session actually needs to see.

5. Build artifacts and upload them to KV.

npm run build
wrangler kv bulk put artifacts/kv-bulk.json --binding CONTEXT_KV

npm run build reads content/*.md, writes artifacts/kv-bulk.json and artifacts/meta.json. Rerun this (and re-upload) any time you edit content/.

6. Deploy the Worker.

wrangler deploy

This publishes src/worker.ts to Cloudflare, routed under your domain (or workers.dev) per wrangler.toml.

Connecting it to Claude

Add a custom connector / remote MCP server pointing at your deployed Worker's /mcp URL, using your read token as the credential, in whichever Claude surface you use: Claude Desktop's connector settings, the browser chat connector settings, or Claude Code's MCP config. Once connected, Claude can call get_context, list_sections, and get_meta against your curated content.

For any of your own servers/agents that should be able to leave journal notes for later review, add the same connector but with the write token instead — they can then call append_journal (and, since it needs the write scope too, list_journal).

Local development

printf "READ_TOKEN=dev-read\nWRITE_TOKEN=dev-write\n" > .dev.vars
npm run dev

npm run dev runs wrangler dev, which reads .dev.vars for local secrets (also gitignored) instead of Cloudflare's real secret store. Smoke-test with any MCP client, or by hand against the HTTP endpoint per the current MCP transport docs. The mcp-tester subagent in .claude/agents/ is set up to do this smoke test for you: auth gating, read tools, and a write/journal round trip.

Redeploying after a content change

Any time you edit content/*.md:

npm run build
wrangler kv bulk put artifacts/kv-bulk.json --binding CONTEXT_KV

You do not need to redeploy the Worker itself for a content-only change — the Worker reads KV at request time, so a fresh kv bulk put is enough. Redeploy the Worker (wrangler deploy) only when src/ changes.

Promotion workflow (once scripts/promote.ts is implemented)

The intended day-to-day loop, per Design-Decisions (D2): your agents call append_journal as they work; periodically you run the promotion script locally, review what came in, and hand-edit content/*.md for anything worth keeping permanently, then rerun steps 5-6 above. As of this writing scripts/promote.ts is a stub — see Contributing for current build status.

Clone this wiki locally