Choose your deployment
Piranha runs three ways. Pick based on where your meets happen and your network.
Hosted (server)
Section titled “Hosted (server)”A FastAPI backend serving the built web app, on SQLite or Postgres, reachable over the network. Best for a league that wants one always-on instance multiple clubs share. Deploys to any host that can run the app and serve static files (e.g. Render).
Desktop (offline-first)
Section titled “Desktop (offline-first)”A native app (Tauri) that bundles the backend as a local “engine” and serves
everything over loopback. Built for deck day: the timing-console connection,
zeroconf discovery, and .gen ingestion are all local, so flaky venue wifi is
never on the critical path. This is the right choice for the box on the pool deck.
Run the backend and web app directly on one machine for development or a single-operator setup. Zero-config on SQLite.
Hosted and desktop: check a meet out
Section titled “Hosted and desktop: check a meet out”The two deployments combine: prepare a meet on the hosted instance (rosters, entries, seeding), then check it out to the deck box, run it offline, and sync it back when the meet ends. While a meet is checked out the cloud copy is locked read-only, so there’s exactly one writable copy and check-in can never conflict — identities (swimmers, entries, results) round-trip intact. The workflow is API-driven today — the web app doesn’t yet surface checkout state (writes to a checked-out meet are refused with a lock error); a first-class UI is planned.
Which should I use?
Section titled “Which should I use?”- One club, on the deck, unreliable wifi → Desktop.
- A league sharing one instance → Hosted (Postgres recommended under load).
- Both: prepare in the cloud, run on deck → Hosted + Desktop with meet check-out (above).
- Trying it out / developing → Local.
Next: Install & first run.