Problem
Today you need Docker knowledge to try omadia at all, and even with Docker the default stack builds from source and runs multiple services (see #336). That blocks both "just let me look at it" evaluators and "I'd self-host but I don't do Docker" adopters. These are two different funnels and shouldn't be solved with one mechanism.
Constraint to respect
omadia is single-tenant + BYO-key + own-your-data by design, and multi-tenant is explicitly out of scope for v1. A cheap "we host it for everyone" demo works against that architecture, so the hosted path has to be either ephemeral/isolated or a non-running guided tour — not a shared multi-tenant instance.
First proposals (ranked by leverage/effort)
1. Prebuilt images + minimal-core compose (low effort, prerequisite)
- Publish
middleware and web-ui images to GHCR; switch compose to image:.
- Ship a minimal core (
middleware + web-ui + postgres) as the default; move kroki/mermaid/minio/ollama behind real opt-in profiles.
- Result: first run goes from "build + model pull" to "pull + start"; far smaller footprint. This also unblocks proposal 2.
2. One-click cloud deploy template (medium effort — the actual no-Docker answer)
- Add a Railway / Render / Fly template ("Deploy" button) so a non-Docker user gets their own instance with an LLM key, no local Docker.
- For this path, swap the Ollama embedding sidecar for an API-based embedding (Ollama in a PaaS is memory-heavy and cold-pull-awkward).
- Depends on proposal 1.
3. Interactive demo / tour on omadia.ai (low–medium effort, highest reach)
- A clickable recorded walkthrough (e.g. Arcade/Storylane), no backend.
- Lets people see the prompt → run → audit-receipt flow without installing anything. Decoupled from infra, can ship independently.
Out of scope for "first steps" (note for later)
- Ephemeral per-session hosted sandbox (real run, no install) — high effort, you eat the token cost + need isolation/abuse handling.
- Native installer / single-process mode with sqlite-or-in-memory KG fallback — postgres+pgvector is the blocker; in-memory KG exists but loses state.
Suggested sequencing
1 → 2 → 3 in parallel. Defer the sandbox/native-installer work until demand isn't covered by the above.
Problem
Today you need Docker knowledge to try omadia at all, and even with Docker the default stack builds from source and runs multiple services (see #336). That blocks both "just let me look at it" evaluators and "I'd self-host but I don't do Docker" adopters. These are two different funnels and shouldn't be solved with one mechanism.
Constraint to respect
omadia is single-tenant + BYO-key + own-your-data by design, and multi-tenant is explicitly out of scope for v1. A cheap "we host it for everyone" demo works against that architecture, so the hosted path has to be either ephemeral/isolated or a non-running guided tour — not a shared multi-tenant instance.
First proposals (ranked by leverage/effort)
1. Prebuilt images + minimal-core compose (low effort, prerequisite)
middlewareandweb-uiimages to GHCR; switch compose toimage:.middleware+web-ui+postgres) as the default; movekroki/mermaid/minio/ollamabehind real opt-in profiles.2. One-click cloud deploy template (medium effort — the actual no-Docker answer)
3. Interactive demo / tour on omadia.ai (low–medium effort, highest reach)
Out of scope for "first steps" (note for later)
Suggested sequencing
1 → 2 → 3 in parallel. Defer the sandbox/native-installer work until demand isn't covered by the above.