Run EmDash | ermahgerd

ermahgerd carries the released EmDash Cloudflare blog scaffold under examples/emdash-blog. It is not a platform-specific rewrite. Its normal Astro build and Wrangler deployment exercise static assets, D1, R2, session KV, Images, Worker secrets, scheduled events, and outbound networking together.

Deploy it

Start from the provisioned appliance, then run the compatibility check:

make status
make emdash-check

The check builds the released scaffold, lets Wrangler discover and provision its named D1 database, R2 bucket, and session KV namespace, installs the encryption key through wrangler secret put, and performs a second ordinary deployment. It verifies that maintenance deployment inherits the existing bindings rather than creating replacement resources and that the cron trigger remains active.

Open the CMS setup surface at:

https://emdash-blog.t-bd7662a5eeb4.workers.ermahgerd.localhost:8443/_emdash/admin

Complete the setup wizard to seed the blog and enroll a real passkey on your device. The CMS owns its schema and migrations; ermahgerd supplies the D1-compatible database boundary. The compatibility check deliberately does not enroll a synthetic credential that would leave the example administrator inaccessible afterward.

Maintain it

After setup, use the same project commands expected by the scaffold:

cd examples/emdash-blog
npm run deploy

When invoking Wrangler outside the Make target, point it at the organization:

export CLOUDFLARE_API_BASE_URL=http://127.0.0.1:9090/client/v4
export CLOUDFLARE_ACCOUNT_ID=11111111-1111-4111-8111-111111111111
export CLOUDFLARE_API_TOKEN=local-development-token
npm run deploy

Use normal commands to rotate the write-only encryption secret:

printf '%s' "$EMDASH_ENCRYPTION_KEY" | npx wrangler secret put EMDASH_ENCRYPTION_KEY

The generated Worker upload is approximately 18 MiB. The appliance’s explicit 128 MiB deployment-request bound leaves room for this and similarly substantial framework bundles while still limiting control-plane buffering.

EmDash is a compatibility application, not part of make up’s small bootstrap set. Its resources remain organization-owned and appear in the same console, quota, telemetry, and lifecycle surfaces as manually created resources.