This is the one application in the series that fails on arithmetic rather than configuration, because every upload multiplies into several renditions and every view streams the whole file back out. The peer-to-peer delivery helps in one specific case and not the case most instances have. Here is how to plan for all three costs, and which renditions to switch off.
Video is the one self-hosted workload where the naive deployment fails on economics rather than on configuration. The software installs cleanly. Then a single 4K upload becomes four renditions, an hour of CPU, several gigabytes of storage, and a bandwidth bill that scales with every viewer.
The Three Costs, and Their Order
Plan against all three before installing, because sizing for one and not the others is how a PeerTube instance becomes an unpleasant surprise.
Transcoding CPU. Every upload is re-encoded into several resolutions. This is the most CPU-intensive thing on the server by a wide margin, and it happens in bursts when people upload.
Storage. The original plus each rendition. A one-hour 1080p video with four renditions lands in the low single-digit gigabytes; the same at 4K is several times that.
Bandwidth. The one that ends projects. Every view streams the full file, so a hundred people watching an hour of 1080p is a few hundred gigabytes leaving your server.
| Instance | vCPU / RAM / SSD | Monthly on per-resource pricing |
|---|---|---|
| Personal, occasional uploads | 4 / 8 GB / 250 GB | $20.38 |
| Small channel, regular uploads | 8 / 16 GB / 1 TB | $45.76 |
| Community instance, many uploaders | 16 / 32 GB / 2 TB | $91.52 |
At MassiveGRID's per-resource rates of $2.87 per CPU core, $0.80 per GB of RAM and $0.01 per GB of SSD per month, the middle row is $22.96 plus $12.80 plus $10, less 20% on annual billing. CPU is what shortens the transcoding queue; storage is what determines how long you can keep uploading.
P2P Is the Differentiator, Within Limits
PeerTube's distinguishing feature is that viewers help serve the video. The player uses WebTorrent, so a popular video watched by many people simultaneously is partly delivered between browsers rather than entirely from your server.
This genuinely reduces bandwidth and it is worth being precise about when. It helps when many viewers watch the same video at the same time, because that is when peers have the segments each other needs. It does not help for a long tail of videos each watched by one person occasionally, which is what most instances actually have.
So treat P2P as a discount on your best case rather than as the bandwidth plan. Size the server for the traffic you would pay for without it, and be pleased when it costs less.
Federation adds the other half of the story: instances follow each other, so videos appear in each other's directories. Note that following an instance means your users can watch its videos, not that you store them, so federation costs you little and expands what your instance offers considerably.
Install With Docker Compose
sudo apt update && sudo apt install -y docker.io docker-compose-plugin ffmpeg
sudo mkdir -p /opt/peertube && cd /opt/peertube
curl -o docker-compose.yml https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/docker-compose.yml
curl -o .env https://raw.githubusercontent.com/Chocobozzz/PeerTube/master/support/docker/production/.env
sudo docker compose up -d
sudo docker compose logs peertube | grep -i 'root password'Read the compose file and the env file before starting them, and set the domain, the database password and the SMTP details in .env first. The root password is generated on first boot and printed once to the logs; capture it then, because retrieving it afterwards means a CLI reset.
The domain is not changeable later without breaking federation, in the same way as any federated application. Decide it before the first video is uploaded.
Tune Transcoding to Your Hardware
The defaults enable more renditions than most instances need, and each one costs CPU on upload and storage forever.
transcoding:
enabled: true
threads: 4
concurrency: 1
resolutions:
'480p': true
'720p': true
'1080p': true
'1440p': false
'2160p': false
hls:
enabled: true
web_videos:
enabled: falseFour decisions in there. Turning off 1440p and 2160p removes the two most expensive renditions, and for most content nobody misses them. concurrency: 1 keeps a queue of uploads from saturating the machine and making the web interface unusable. HLS is what enables adaptive quality and P2P and should stay on. And disabling the legacy web video format halves storage per video, at the cost of compatibility with very old players.
Where transcoding is the bottleneck, PeerTube supports remote runners: a separate machine that takes transcoding jobs off the queue. That is the right way to scale this, because it lets you rent CPU for the bursts rather than sizing the whole instance for them.
Our guide to running a Jellyfin media server covers transcoding mechanics in more depth, including hardware acceleration, which applies to the same ffmpeg underneath.
Object Storage for the Videos
Beyond a personal instance, keeping videos on the server's disk stops working: you cannot grow the disk indefinitely and backups become impractical.
PeerTube supports S3-compatible object storage for videos and playlists, which decouples storage growth from the instance and lets a CDN sit in front of the delivery path. That last part is what makes a popular instance viable, since a CDN absorbs the bandwidth that P2P does not.
Two caveats. Egress from object storage is charged per gigabyte by most providers, so you have moved the bandwidth cost rather than removed it. And the migration from local to remote storage on a running instance is a bulk copy with a cutover, so it is easier decided at the start. Our guide to object storage charges covers the four cost axes that matter.
What You Need to Decide Before Opening
The technical work is finite. Two policy questions are not, and both belong before launch.
Who can upload. Open uploads on a public instance means hosting whatever anyone sends, with the storage cost and the legal exposure that implies. Most instances should be invite-only or single-channel, and per-user quotas exist for the ones that are not.
What you will remove and how fast. A published policy and a working contact address, decided in advance rather than composed under pressure. Instances that handle this badly get defederated, which undoes the point of federating.
Infrastructure for Video
Video is bandwidth-heavy and bursty in CPU, which is an awkward shape to buy: sizing for the transcoding peak wastes money the rest of the time.
MassiveGRID's per-resource pricing at $2.87 per CPU core, $0.80 per GB of RAM and $0.01 per GB of SSD per month lets you buy the shape rather than a tier, and a separate instance for remote transcoding runners can be rented for the bursts. A Linux VPS covers the application, HA cloud storage the video library, and the platform underneath runs Proxmox high-availability clustering with automatic failover over Ceph storage replicating every block three times across independent NVMe drives, with always-on DDoS mitigation in front of a public endpoint that will attract attention.
Instances can be ordered across a partner footprint of more than 700 datacenters in 85 metros, 30 countries and six continents, with auto-provisioning in New York, London, Frankfurt and Singapore, which for video means placing the server near the audience rather than across an ocean from it.