Example applications

This catalog describes the self-hosted local demonstration. Its addresses and seeded resources belong to that demo; a managed account is not automatically populated with these applications. Use Connect Wrangler when adapting an example for your own organization.

A fresh appliance deploys progressively richer examples through the same Wrangler API used by tenant applications. They are product examples, not privileged Ansible workloads: Ansible provisions the platform, while make examples-deploy creates tenant resources and sends application code through Wrangler.

Sum canary

sum is the deliberately small compute baseline. It validates request routing and JSON execution without a data-service dependency:

curl -sS -H 'content-type: application/json' \
  -H 'Host: sum.t-bd7662a5eeb4.workers.ermahgerd.localhost' \
  -d '{"a":20,"b":22}' http://127.0.0.1:8080/sum

Order desk

Open https://order-desk.t-bd7662a5eeb4.workers.ermahgerd.localhost:8443. The static interface and HTTP API are one Worker; background fulfillment is a second Worker.

1. POST /api/orders validates an order, records its short-lived status in KV, and durably sends the complete order to order-events.
2. order-processor consumes the message at least once. It writes the immutable JSON transaction to the order-archive R2 bucket, updates the operational SQLite database through its D1 binding, and publishes the completed status to KV.
3. The browser polls the status capability, then shows the database-backed order list and a link to the R2 archive returned through the API Worker.

The consumer uses deterministic object keys and database upserts. Reprocessing the same queue message therefore converges on one order and one archive object rather than duplicating business state. The example demonstrates a useful at-least-once consumer; it is not a distributed transaction across R2, SQLite, and KV.

Key files:

• examples/order-pipeline/api — HTTP API and static UI.
• examples/order-pipeline/processor — queue consumer.
• examples/order-pipeline/migrations — operational schema.

Photo publishing workflow

Open the management surface at https://photo-studio.t-bd7662a5eeb4.workers.ermahgerd.localhost:8443 and the public collection at https://photo-gallery.t-bd7662a5eeb4.workers.ermahgerd.localhost:8443. The application is three Workers with deliberately different jobs:

1. photo-studio accepts JPEG and PNG uploads up to 64 MiB, lets an editor maintain titles and alternative text, exposes processing failures for retry, and controls publication.
2. photo-processor consumes photo-processing queue messages. It reads the original from R2, validates it against the example’s 64-megapixel policy, calls the native Images binding, and writes WebP thumbnail and display renditions while preserving aspect ratio. When the organization has a Fireworks provider, it analyzes a compact JPEG rendition through the Worker’s AI binding and stores a validated description, suggested alternative text, categories, and tags.
3. photo-gallery exposes only ready, published catalog entries and streams their immutable renditions from R2. The browser never receives an R2 credential.

The photo-gallery R2 bucket owns image bytes and the photo-catalog database is the authoritative editorial and processing catalog. Queue messages contain only a photo identifier and revision. Derived object keys are revisioned, so a delayed retry cannot overwrite the output of a newer edit or retry. A photo remains invisible on the public site until processing succeeds and an editor publishes it. AI enrichment is best-effort and never prevents an otherwise valid photograph from becoming ready. The model is constrained with JSON Schema and its response is independently validated; categories and tags are stored in indexed relational tables rather than an opaque blob. Editors can review and adopt suggested alternative text, while the public gallery can be filtered by generated category or tag.

The workflow uses real image transformations rather than browser display resizing. The Worker’s declared Images binding is an organization-scoped capability; application code receives no internal service credential. The platform’s Access service protects photo-studio for owners and administrators while photo-gallery remains public. make examples-test uses an application-scoped local service token to exercise the editorial workflow without weakening the browser policy.

Key files:

• examples/photo-gallery/studio — uploads and editorial workflow.
• examples/photo-gallery/processor — queue consumer and native image transforms.
• examples/photo-gallery/gallery — public, read-only collection.
• examples/photo-gallery/migrations — shared catalog schema.

EmDash compatibility application

examples/emdash-blog is the released EmDash Cloudflare blog scaffold, not a platform-specific port. It is deliberately not part of the bootstrap application set: run make emdash-check when you want to exercise the larger compatibility contract. The check uses normal Wrangler resource discovery, provisioning, secret, deploy, and repeat-deploy paths. See Run EmDash.

Durable counter

durable-counter is a normal Wrangler application with one native SQLite-backed Durable Object class. Named counters retain values through code deployments and shard restarts; the same class demonstrates an alarm, native RPC, and WebSocket hibernation handlers. Its stable placement and lifecycle history are visible in the Worker’s Durable Objects tab. See Durable Objects.

Documentation site

ermahgerd-docs publishes this repository’s guides with Cloudflare Nimbus, including search, screenshots, architecture diagrams, and Markdown discovery. It uses a normal assets-only Wrangler deployment, without a private platform deployment path. See Publish the documentation site.

Deploy and verify

make up deploys and exercises the canary, orders, photos, Durable Objects, and documentation on a newly provisioned appliance. Against an already provisioned VM:

make examples-deploy  # idempotently create resources, deploy, and run E2E checks
make examples-test    # exercise the existing deployments without changing them

The deployment creates order-events, order-events-dlq, order-archive, order-operations, order-status, photo-processing, photo-processing-dlq, photo-gallery, and photo-catalog in the bootstrap organization. They appear in the console like tenant-created resources and consume the same quotas. Re-running deployment preserves their data; make destroy removes the entire disposable appliance.