Shared preview demos
Seven of the twelve Flareo modules have a live, click-to-try preview at s-<slug>-demo.preview.flareo.dev. These are shared demo instances — anyone visiting sees the same instance, so don't enter real credentials.
Available previews
| Module | URL |
|---|---|
| Vaultwarden | s-vaultwarden-demo.preview.flareo.dev |
| Uptime Kuma | s-uptime-kuma-demo.preview.flareo.dev |
| Gitea | s-gitea-demo.preview.flareo.dev |
| Linkwarden | s-linkwarden-demo.preview.flareo.dev |
| ntfy | s-ntfy-demo.preview.flareo.dev |
| AdGuard Home | s-adguard-home-demo.preview.flareo.dev |
| Caddy | s-caddy-demo.preview.flareo.dev |
How the demos work
- Each preview runs on a single Hetzner CX41 (8 vCPU, 16 GB RAM) as a Docker container behind Caddy.
- Caddy terminates TLS using a wildcard certificate obtained via ACME DNS-01 against Cloudflare.
- Every 24 hours at midnight UTC, a systemd timer wipes all persistent volumes and recreates the containers. Whatever you set up during the day is gone at 00:00 UTC.
Why shared, not personal
A real per-user isolated preview requires Firecracker microVMs or similar; that's on our Horizon 3 roadmap (months 5-9 of the product). For the MVP, shared demos are honest: you see exactly what Flareo publishes, running on the infrastructure we describe, with the limitations clearly labeled.
What you should NOT do
- Don't sign up with an email you care about. The Vaultwarden sign-up is public; anyone can create an account. Your email goes into a shared database that resets daily.
- Don't store real secrets. The password manager demo is exactly that — a demo.
- Don't expect persistence. Everything resets every 24 hours. That's the feature, not a bug.
Why the other five modules aren't in previews
- Home Assistant needs USB/Bluetooth passthrough to be meaningful.
- Immich requires a GPU and 4+ companion containers to demo well.
- Jellyfin streams video, and the shared network link to the preview host would saturate.
- Nextcloud has a 2+ GB first-boot time that makes the demo feel broken.
- Paperless-ngx runs a memory-hungry OCR worker that doesn't fit alongside the others on a single CX41.
Module pages for these show Preview unavailable · local only. These modules run in the catalog and verify identically to any other — the only thing missing is the click-to-try demo VM, because they'd need per-user isolation that the current shared demo host can't provide. Personal previews are on the roadmap for Pro-tier deployments; the shared public demo stays free and stays focused on lightweight modules.
Want to test with your OWN data?
Use the CLI's ephemeral run mode. The shared demo is for click-around; if you want to actually evaluate a module against your real workflow, run it locally:
flareo run vaultwarden
# pulls verified image, allocates a fresh isolated volume,
# binds a random local port, prints the URL
# auto-stops after 60 minutes (configurable with --ttl-minutes)
# Ctrl-C cleanly tears down; nothing persists
Your machine is the substrate. The data never leaves your laptop. The container runs in the foreground; closing the terminal stops it cleanly.
flareo run uptime-kuma --port 8081 --ttl-minutes 30
This is what the "try with my own data" workflow actually looks like today. We don't host per-user previews because the operational and security tradeoffs aren't worth it at our scale; running locally is the honest answer.
See flareo run --help or /docs/cli-reference#flareo-run-v030 for full flag documentation.
Next steps
- Once you've clicked around a preview, install the CLI and run the module yourself.
- Understand what the previews prove and don't prove about the underlying images.