Skip to main content

​
Set production secrets

Authenticate Wrangler, then copy the generated environment template.
Set CHARDB_URL to the public URL Wrangler prints for the Worker, usually https://<worker-name>.<account-subdomain>.workers.dev. If you use a custom domain, configure that route before bootstrapping. Replace both secret placeholders.
.env.local
Do not commit .env.local. The bootstrap script sends both secrets through a mode-0600 temporary file, removes it, and never puts a secret in process arguments.

​
First deploy

Create the external resources, then bootstrap the Worker. The bootstrap script runs type checks, tests, and both builds before it uploads.
setup:cloudflare creates or verifies the R2 bucket in wrangler.toml. It does not install an expiry rule: the private content-addressed objects are the authoritative file bytes. Vectorize needs the explicit setup shown in Vectors. deploy:bootstrap uploads the first Worker, waits for the packaged schema identity, and applies the migration.

​
Later deploys

Use the routine release path when the resources already exist. It runs the same checks and builds before upload.
Routine deploy requires an existing Worker and refuses a package or migration mismatch.
Keep CHARDB_ADMIN_TOKEN separate from BETTER_AUTH_SECRET. The first authorizes maintenance operations. The second signs application sessions.

​
Cost boundary

CharDB adds no hosted-service fee. Cloudflare bills Workers, Durable Objects, R2, and Vectorize from the bindings and traffic in your application. One application mutation can cause several Durable Object calls and SQLite row operations. File uploads write one content-addressed R2 object per unique payload digest, so identical payloads share bytes. Those objects do not expire automatically. Bytes left by rejected uploads or deleted files remain billable until provider-wide orphan collection is available. A completed restore also materializes one live key for each restored file until normal deletion removes it. Current evidence measures latency and operation counts, not a complete Cloudflare invoice. It does not collect every Worker CPU-ms, Durable Object duration, R2 GB-month, or Vectorize billing dimension.

​
Recovery boundary

Capture a native SQLite recovery point after a healthy deploy and before a migration:
Store the manifest outside the deployment. Restore validates the current topology, fences new traffic, and restarts the Catalog and every active shard at their recorded Durable Object PITR bookmarks:
Cloudflare retains Durable Object PITR history for 30 days. CharDB keeps authoritative R2 file bodies without automatic expiry. During restore it clears CharDB’s current live R2 keys and tracked Vectorize records in signed, bounded turns, restarts every Durable Object, eagerly rebuilds authoritative files, and requeues authoritative vectors. The same manifest resumes after an unknown result. CharDB does not provide automatic regional failover or a production SLA. Automatic resharding and range merging are unsupported. For recovery, resharding, and availability limits, read Plan ahead. Read Schema migrations before changing a deployed table.