--- title: "Example applications" --- > Documentation Index > Fetch the complete documentation index at: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/llms.txt > Use this file to discover all available pages before exploring further. # Example applications 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: ```sh 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 . 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`](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/order-pipeline/api) — HTTP API and static UI. * [`examples/order-pipeline/processor`](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/order-pipeline/processor) — queue consumer. * [`examples/order-pipeline/migrations`](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/order-pipeline/migrations) — operational schema. ## Photo publishing workflow Open the management surface at and the public collection at . 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](/images/) is an organization-scoped capability; application code receives no internal service credential. The platform's [Access service](/application-access/) 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`](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/photo-gallery/studio) — uploads and editorial workflow. * [`examples/photo-gallery/processor`](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/photo-gallery/processor) — queue consumer and native image transforms. * [`examples/photo-gallery/gallery`](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/photo-gallery/gallery) — public, read-only collection. * [`examples/photo-gallery/migrations`](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/photo-gallery/migrations) — shared catalog schema. ## EmDash compatibility application [`examples/emdash-blog`](https://github.com/nullbytelabs/ermahgerd/blob/main/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](/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](/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](/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: ```sh 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. Source: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/examples/index.mdx