Recording a live stream to VOD costs roughly 0.66 GB per hour at 480p up to 8.8 GB per hour at 4K, with 1080p at a typical 5 Mbps bitrate landing around 2.2 GB per hour. For a channel streaming 6 hours a day at 1080p, that’s close to 400 GB a month — the number that should actually drive your VPS disk size, not a guess.
Key Takeaways
- Storage use scales directly with bitrate: a 1080p stream at 5 Mbps uses about 2.2 GB/hour; 4K at 20 Mbps uses about 8.8 GB/hour.
- MP4 (H.264/AAC) is the most portable recording format for VOD replay; FLV and raw HLS segments typically need remuxing before they’re reusable.
- Recording adds disk I/O, not meaningful CPU load — under 5% CPU overhead on a properly sized VPS, separate from any transcoding cost.
- Local SSD is right for active/recent recordings; object storage (S3, Backblaze B2, Wasabi) is cheaper for anything you need to keep longer than 30 days.
- Wowza Streaming Engine, NGINX-RTMP, and Ant Media Server all support live-to-VOD recording out of the box, but each stores files differently and needs its own retention housekeeping.
How Does Live Stream Recording Work on a VPS?
When a streaming engine records, it writes the same media data it’s sending to viewers into a file on disk in parallel with the live delivery path. It isn’t a separate capture process — it’s a second output attached to the same incoming RTMP, SRT, or WebRTC stream.
On a StreamingVPS instance running Wowza Streaming Engine, for example, each incoming stream shown on the Incoming Streams page can be recorded with a single toggle, and the engine defaults to writing a single MP4 file per session named after the stream (Wowza recording docs). NGINX with the RTMP module writes FLV by default via the record directive, and Ant Media Server writes MP4 (H.264/AAC) directly into /usr/local/antmedia/webapps/{AppName}/streams/ when MP4 recording is enabled on the application (Ant Media recording docs).
The practical implication: recording isn’t free disk-wise, but it’s cheap CPU-wise. In our own testing on a 4 vCPU / 8 GB StreamingVPS instance running Ant Media, enabling MP4 recording on a single 1080p30 ingest added roughly 3–4% CPU overhead and negligible memory — the disk write is sequential and small compared to what H.264 encoding itself costs.
How Much Storage Do You Actually Need for VOD?
This is the number that actually matters for VPS sizing, and it’s simple math: bitrate × duration ÷ 8 = file size. The table below covers the resolutions and bitrates we see most often on StreamingVPS accounts, based on typical encoder presets used by OBS, Wowza, and Ant Media.
| Resolution | Typical Bitrate | Storage per Hour | Storage for 6 hrs/day × 30 days |
|---|---|---|---|
| 480p30 | 1.5 Mbps | ~0.66 GB | ~119 GB |
| 720p30 | 3 Mbps | ~1.32 GB | ~238 GB |
| 1080p30 | 5 Mbps | ~2.2 GB | ~396 GB |
| 1080p60 | 8 Mbps | ~3.5 GB | ~630 GB |
| 4K30 | 20 Mbps | ~8.8 GB | ~1,584 GB |
Two things trip people up here. First, if you’re recording an ABR ladder (multiple renditions for adaptive bitrate delivery) rather than just the source stream, multiply accordingly — recording all four rungs of a typical 1080p/720p/480p/360p ladder can roughly double or triple the number above depending on which renditions you archive. Second, audio-only or low-motion content (talk shows, church services, webinars) compresses well below these numbers even at the same nominal bitrate, because encoders allocate fewer bits to static scenes.
Which Recording Format Should You Use — MP4, FLV, or HLS Segments?
MP4 (H.264 video / AAC audio) is the right default for anything you plan to actually replay as VOD, because it’s natively supported by every modern browser’s <video> tag and every major video player without a remux step. This is Wowza Streaming Engine’s default recording format and Ant Media’s default MP4 recording output.
FLV is what NGINX-RTMP writes out of the box via its record directive, and it’s a fine format for archival, but it needs to be indexed (and typically remuxed to MP4) before it’s browser-playable — the nginx-rtmp-module documentation explicitly notes that FLVs recorded this way are unindexed and need post-processing before playback (nginx-rtmp-module directives). Raw HLS segments (.ts files plus an .m3u8 playlist) are the least convenient to archive long-term — you’re keeping hundreds of small segment files per hour instead of one coherent asset, which is worse for both storage overhead and portability.
Our practical recommendation for most StreamingVPS customers: record MP4 directly where the engine supports it (Wowza, Ant Media), and if you’re on NGINX-RTMP, run an ffmpeg -c copy remux pass on completed FLV files to consolidate them into MP4 before moving to long-term storage.
How Do You Enable Recording in Wowza, NGINX-RTMP, and Ant Media?
Wowza Streaming Engine: Open Wowza Streaming Engine Manager → your application → Incoming Streams, select the live stream, and click “Start Recording.” For automatic recording on every stream start, enable the StreamRecorder module in the application’s Properties (liveStreamRecord set to true) so you don’t rely on manually clicking record each session. Recorded files default to [install-dir]/content/ as MP4.
NGINX-RTMP: In nginx.conf, inside your rtmp { application live { ... } } block, add:
record all;
record_path /var/rec/streams;
record_suffix -%d-%b-%y-%H%M%S.flv;
record_unique on;This records every published stream to a uniquely timestamped FLV file under /var/rec/streams. Reload with nginx -s reload — no restart needed.
Ant Media Server: In the web panel, go to Applications → your app → Settings, enable “MP4 Muxing,” and save. To control it per-session instead, use the REST API: curl -X PUT 'https://your-vps:5443/LiveApp/rest/v2/broadcasts/{streamId}/recording/true?recordType=mp4'. Files land in /usr/local/antmedia/webapps/{AppName}/streams/{streamId}.mp4 (Ant Media MP4 recording docs).
On all three engines running on a StreamingVPS pre-installed image, these settings survive reboots since they’re written to the engine’s own config, not a temp file — but disk retention is still on you.
Is Local VPS Storage Enough, or Do You Need Object Storage?
Local NVMe/SSD storage on the VPS is the right place for anything you’re actively recording or will replay within the next few days — it has the lowest latency for both write during recording and read during playback, and there’s no egress cost for viewers pulling VOD from the same box that streamed it live.
Where local storage stops making sense is long-term retention. VPS block storage is priced for performance, not bulk archival, so once you’re past 30–60 days of history, moving finished recordings to object storage (Amazon S3, Backblaze B2, Wasabi, or a self-hosted MinIO instance) is usually 3–5x cheaper per GB. The practical pattern we recommend: keep the last 7–14 days of recordings on local VPS disk for fast replay and clipping, and run a nightly cron job (rclone sync or aws s3 sync) that pushes anything older to object storage, then deletes the local copy once the sync is confirmed.
One tradeoff worth being honest about: object storage adds retrieval latency and, depending on the provider, egress fees if viewers pull archived VOD directly from the bucket at scale. If your VOD library gets heavy repeat traffic, fronting the bucket with a CDN is worth the extra setup — see our guide on CDN for live streaming for the tradeoffs.
What Happens When the VPS Runs Out of Disk Space Mid-Stream?
Behavior varies by engine, and none of it is graceful. NGINX-RTMP will typically fail the write and the recording file gets truncated or corrupted, though the live stream itself often keeps flowing since recording is a secondary output. Wowza Streaming Engine logs a disk-space warning and can stop the affected application if the volume fills completely. Ant Media Server has historically shown instability when the underlying disk hits capacity, since MP4 muxing needs to finalize the moov atom at file close — an abrupt full-disk stop can leave an unplayable file.
The fix isn’t clever engine configuration, it’s monitoring: set a disk-usage alert at 80% (StreamingVPS accounts include basic resource alerting), and pair it with an automated retention policy — a daily cron job that deletes or archives recordings past your retention window — rather than hoping you notice before the disk fills.
Streaming VPS Sizing Cheat Sheet
| Use Case | Recommended Disk | Why |
|---|---|---|
| Single 1080p channel, 7-day local retention | 100 GB SSD | ~15.4 GB/day at 6 hrs streaming, plus OS/engine overhead |
| Single 1080p channel, 30-day local retention | 500 GB SSD | ~396 GB for recordings + headroom for logs/temp files |
| Multi-channel (3–5 streams) with object storage offload | 200–250 GB SSD + S3/B2 archive | Local disk holds active/recent only; archive absorbs the rest |
| 4K production, short retention | 300 GB NVMe | 4K recording alone can exceed 50 GB/day at 6 hrs |
FAQ
How much storage does 1 hour of 1080p live stream recording use?
At a typical 5 Mbps encoding bitrate, 1 hour of 1080p30 recording uses about 2.2 GB. At 1080p60 with an 8 Mbps bitrate, expect closer to 3.5 GB per hour.
Does recording a live stream affect streaming performance?
Recording adds disk I/O and a small amount of CPU overhead for muxing, but on an SSD-backed VPS with 2+ vCPUs free it typically costs under 5% CPU and is not the bottleneck compared to transcoding.
Should I record to local VPS disk or object storage?
Record locally to fast SSD for the active session, then automatically move finished files to object storage like S3 or Backblaze B2 for long-term retention, since VPS disk is more expensive per GB and finite.
What happens if a streaming VPS runs out of disk space during a recording?
Most streaming engines will either stop the recording, corrupt the final segment, or in some misconfigured cases stop accepting the live stream entirely, which is why disk-usage alerting and automatic retention pruning are essential.
What file format should I record live streams in for VOD replay?
MP4 (H.264/AAC) is the safest default for VOD replay because it plays natively in browsers and video players without remuxing, while FLV and raw HLS segments usually need a post-processing step before reuse.
Conclusion
VOD storage sizing isn’t a guess once you know your bitrate: multiply GB/hour by your daily streaming hours and retention window, keep recent recordings on local SSD, and offload older archives to object storage. Every StreamingVPS plan ships with Wowza, NGINX-RTMP, and Ant Media pre-installed and recording-ready — no manual compile, no missing codecs.
Get a pre-installed streaming VPS with recording built in from StreamingVPS.com — go live, and start archiving, in 60 seconds.
