Built on Gritiva
Gritiva is not a product we ship and then run something else on. These four services carry real users on the same Scopes, mesh networking and control plane described everywhere else on this site. Several of the postmortems in the documentation were written because of them.
Harmonia — music streaming
A music service with roughly sixteen thousand tracks: catalogue and search services, HLS transcoding, stem separation, and an audio-analysis pipeline that derives tempo, key and mood for every track. Around ten thousand pages are indexed, serving Persian-language search that the global platforms do not cover.
- What it stresses: sustained transcoding load, object storage, and a cache layer that has to survive a cold catalogue.
- What it taught us: the cache-stampede fix in the platform notes came from watching this service stall for several seconds every minute under a sixty-second snapshot expiry.
Listen: harmoniafm.com.
Lumina — film and series
A video platform with a catalogue, watch-together rooms over WebRTC, live channels and native clients on mobile and TV. Video is the least forgiving workload on this list: large files, long-lived connections, and a transcoding queue that competes with everything else on the host.
- What it stresses: disk throughput, TURN relaying for peers behind CGNAT, and per-Scope resource limits that actually hold under load.
- What it taught us: the disk-fill incident write-ups came from a bind mount here filling a fourteen-terabyte volume.
Watch: lumina.gritiva.com.
Rasad — Persian Telegram content intelligence
A B2B intelligence product over a corpus of tens of millions of public Telegram messages, with Elasticsearch, an object store, and worker fleets doing entity extraction, scoring and indexing. It is the most write-heavy service we operate.
- What it stresses: long-running worker queues, search-index memory, and scope isolation between a dozen worker roles on one host.
- What it taught us: the per-Scope cgroup limits exist because one worker fleet could starve every other service on the machine.
See it: rasad.gritiva.com.
FinTrack — personal finance
The smallest of the four, and deliberately so: a single service with a database and a scheduled job. It exists here as the honest counterweight — most workloads are not sixteen thousand tracks or fourteen terabytes, and the platform has to be worth using at that size too.
- What it stresses: nothing much. That is the point — a one-service deployment should not need a control plane built for fifty machines to feel heavy.
Look: finance.gritiva.com.
Why publish this at all?
Because "we use it ourselves" is easy to claim and hard to check. Each service above is public, reachable, and can be inspected right now. The failure modes they produced are written up in the postmortems rather than quietly patched.
Read those: Postmortems.
Frequently asked questions
- Are these customer deployments?
- No. They are our own services. Calling them reference customers would be dishonest — they are dogfooding, which is a weaker claim but a checkable one.
- Do they run on the hosted control plane or self-hosted?
- The same control plane described on the pricing page, on our own hardware. Nothing about their deployment is unavailable to anyone else running Gritiva.
- Can I see the infrastructure behind them?
- The architecture is documented publicly, including the Scope model, mesh networking and the backup and restore design. Specific host names, capacities and credentials are not published, for the obvious reason.
Last updated