Hosted demo walkthrough

A Horonomy-hosted, publicly reachable instance running the same self-host artifacts described in the self-host quickstart, populated with a curated synthetic fixture. This is a demonstration environment, not a product: no signup, no multi-tenancy, no billing, and no real data of any kind.

Canonical URL: https://horologium.horo.run/app/w/demo/products/acme-store (fronted by the horologium-edge Cloudflare Worker — the same instance as the unbranded Cloud Run origin, https://horologium-demo-551243130607.us-central1.run.app, which also still resolves directly).

This deployment is reachable at its Product-first workspace route, /app/w/demo/products/acme-store — GET /v1/workspace reports workspace slug demo, product slug acme-store, and data_class: "synthetic".

:::caution Synthetic demonstration data Everything in this environment is synthetic. acme/store, SHOP-412, the refund-window capability — none of it is a real company, repository, or customer. No production credential, proprietary source, or customer data has ever been or will be loaded here. :::

What this is, and isn't

Hosted vs. self-host is configuration and infrastructure only — the exact same container image and the exact same server binary run in both. No business logic forks between the two.

	Self-host	Hosted demo
Compute	docker compose up on your own machine	Managed cloud compute
Database	Local Postgres container	Managed serverless Postgres, free tier
Data	Whatever you seed	The curated golden fixture only — synthetic, never real

What you'll see

The fixture deliberately includes two of the findings described in Integrity states and the evidence model, so a visitor sees a real conflict and a real implemented-not-live state without needing to author scenarios by hand:

• A documentation_conflict finding — Jira, the docs, and the code disagree on the refund window's length (Jira and code say 30 days, the docs say 14), each claim citing its own exact evidence.
• A released_not_live finding — the refund-window change is merged, tagged into version 2.0.0, and running on the beta target, but production is still running version 1.8.0. "Done" in the tracker is not the same fact as "live for customers" — see Reality layers.

Open the capability's timeline to see both transitions (when beta started running 2.0.0, when production's current deployment began) as discrete, dated events rather than a single current-state snapshot — see Product Shape and temporal history.

Using MCP against the hosted demo

No self-host install required — point a coding agent's MCP client at the hosted demo's URL directly. See MCP / coding-agent integration for the exact configuration. No credentials are required.

Security posture

Same posture as self-host without authentication configured (see Security, privacy and data boundaries): every /v1/* read endpoint is reachable by anyone who can reach the URL. This is the intended public demo surface, not an oversight, and it's safe specifically because the data is synthetic. The write endpoint (POST /v1/proposals) is closed here — this deployment runs with HOROLOGIUM_READ_ONLY=true and refuses every write with 403 Forbidden. This environment is never pointed at a database containing anything real.

Cost and availability

This deployment intentionally runs on free-tier infrastructure sized to demo traffic. If it's ever unreachable, it is not a signal about Horologium's production-readiness generally — it's a signal about this specific demonstration environment, which is explicitly out of scope for uptime guarantees during this Public Alpha. See Public Alpha limitations.