The full OTT service
Catalogue, search, recommendations, entitlements, billing, pay-per-view, live channels and the native apps for web, phone and television.
The whole platform, on hardware you own
Application, origin, encoding and delivery, all inside your own perimeter. No metered egress, no per-minute transcoding, no vendor holding the keys to your catalogue. Declared in Terraform from the first commit, so the estate is reproducible before it is live.
When on-premises is the right answer
You already have rack space, your traffic is regional, and metered egress is the line item you want to delete entirely.
Streaming has an unusual cost shape: the expensive parts are the predictable ones. Egress, transcoding and storage grow smoothly with your audience, which is exactly the profile that suits owned capacity and exactly the profile that public-cloud pricing punishes. Elasticity is worth paying for when load is spiky and cheap when it is steady — and steady is what a catalogue is.
This pattern puts every tier on your own hardware, virtualised with Proxmox, with live and video-on-demand served from separate edge machines. That split matters more than it sounds: a live surge and a long-tail catalogue want opposite cache behaviour, and sharing one machine means the surge evicts everything the catalogue needs.
How it fits together
The estate as delivered — every tier named, every boundary drawn.
Untrusted — the public internet
- Web player
- Mobile apps
- TV apps
- Contribution
TLS terminates here and nowhere else
- traefik-edge
- CrowdSec
- Live path
- VOD path
Reachable only through the edge, or through the bastion for operators
- app-core
- content-api
- search-api
- session-authz
- billing
- key-delivery
- recommendation
- bastion
A match-night surge cannot evict the back catalogue
- live-transcode
- live-origin
- vod-transcode + GPU
- vod-origin-cache
- upload-api
- job-scheduler
- RabbitMQ
- MinIO
State lives inside the perimeter
- MariaDB
- Redis
- Elasticsearch
- ClickHouse
- Redpanda
- OpenBao
Declared entirely in code — the estate rebuilds from the repository
- Proxmox VE
- Terraform
- Ansible
- Pipeline → registry
- Prometheus
- SigNoz
- Grafana
- Loki
What is actually delivered
Not a licence and a wiki page. A running system, in your estate, with the people who own it trained on it.
The virtualised estate
A Proxmox platform with isolated guests per service, GPU passthrough for encoding, S3-compatible object storage and a full observability stack.
The edge, compiled for the job
Range-aware caching so a mid-film seek is served from disk, geographic awareness, HTTP/3, and a token check on every single segment.
Everything as code
The whole estate in Terraform and a GitOps pipeline. There is no manual console step anywhere in the delivery path, by design.
Content and secret containment
Encrypted streams, expiring signed tokens re-checked at the edge, and secrets in a vault rather than in a config file or a wiki.
A team that can run it
Runbooks written against your estate, a walkthrough of every failure mode we designed for, and a support line that stays open afterwards.
Tier by tier
| Tier | Runs on | Scales by | Fails over to |
|---|---|---|---|
| Application | Isolated guests on Proxmox | Adding guests, then nodes | Restart on a peer node |
| Live edge | Dedicated host | Adding edge hosts behind DNS | VOD edge, degraded |
| VOD edge | Dedicated host | Adding edge hosts behind DNS | Origin direct, degraded |
| Origin | MinIO on local disk | Adding drives, then nodes | Erasure-coded set |
| Encoder | GPU passthrough guest | Queue depth, then GPUs | Queued, not dropped |
| Control plane | Terraform + Git | Not applicable | State is in Git |
The honest trade-offs
Every architecture buys something and pays for something. Here is the bill for this one.
What you gain
No egress meter, no per-minute transcode bill, no per-session analytics licence. The marginal cost of one more viewer approaches the cost of the bandwidth itself.
What you take on
Hardware, power, and a peering or transit relationship. This pattern rewards predictable regional traffic and punishes unpredictable global traffic.
Where it stops
Serving a distant continent from one region is a physics problem, not a software one. At that point the answer is the hybrid pattern, not a bigger box.
The things people ask first
How much hardware does this actually need to start?
Less than most people expect. The reference estate runs eighteen isolated guests on a single 2U node, with delivery on separate machines. The right starting size depends on your concurrency and bitrate ladder, which is the first thing a discovery call establishes.
What happens when one server is not enough?
You add a node. Every service is containerised behind its own address and the estate is declared in Terraform, so capacity is a variable rather than a redesign. Object storage is already S3-compatible for exactly this reason.
Who operates it after handover?
Your team, if you want that — that is what the runbooks and the training are for. Or we keep operating it under a managed agreement. Both are supported and the technical delivery is identical either way.
Can we move to the hybrid pattern later?
Yes, and this is a common path. Because the whole estate is Terraform, moving the application tier to AWS is a change of provider target for that tier, not a rewrite of the platform.
Show us the rack
Send the hardware you already have and the traffic you already serve. The first thing you get back is an architecture and an honest answer about whether this pattern fits.