AVideo can grow from a small private site to a large video network. There is no per-viewer or per-stream license ceiling in the platform; the server, bandwidth, and services you choose determine practical capacity.

Answer these questions:

1. Will this server encode uploaded videos?
2. Will it transcode live streams into multiple qualities?
3. How many people may watch at the same time?
4. What bitrate will viewers receive?
5. Will media stay on this server or use external storage/CDN?
6. How much content will be retained?

If you do not know yet, begin with the recommended small-production setup below. You can add Encoders, Live servers, CDN delivery, and remote storage as demand grows.

These are planning examples, not guarantees:

Storage requirements depend on the number of videos, duration, resolutions, HLS output, original-file retention, thumbnails, and backups. Do not size storage from the upload file alone; one source video can produce several output files.

The former hardware page described an administrator's working reference server with 8 CPU cores, 16 GB RAM, and a 450 GB SSD. This is still useful as a concrete example of a balanced single server, but it is not a universal requirement or a promise of a specific viewer count.

The former page gave 4 CPU cores, 4 GB RAM, and 120 GB disk as a simple minimum and recommended 8 GB RAM for better processing. Those values are useful as historical orientation, not a guarantee that a production workload fits.

For example, the old guide suggested at least 50 GB free for one 5 GB 4K MP4 job and 100 GB for the comparable HLS job. Treat this as a conservative planning example, then replace it with measurements from your own Encoder profile.

• A currently supported Ubuntu LTS release is recommended for a new installation.
• PHP 8.1 or later is required by the current AVideo codebase.
• A supported MySQL-compatible database and the PHP MySQL extension are required.
• Apache with URL rewriting is the standard documented web-server setup.
• FFmpeg is required for video/audio processing.
• HTTPS is strongly recommended and required by many browser features.

Use the Ubuntu 24.x installation guide for a new server. Control panels such as cPanel or Plesk may change paths, users, PHP versions, and web-server configuration; generic commands may not apply to them.

Open only the ports used by your design. Exact live/WebRTC ports depend on the installed service.

WebRTC can require additional TCP/UDP signaling and media ranges. Follow the WebRTC plugin documentation and firewall design rather than opening a broad range without a reason.

CPU determines encoding and live-transcoding speed. Creating more resolutions uses more CPU. A faster CPU does not increase viewer delivery capacity if the network is already full.

Memory is used by PHP, the database, FFmpeg jobs, caching, and the operating system. Large or concurrent encoding jobs can require substantially more memory than ordinary page views.

Use SSD storage for the application, database, cache, and active encoding workspace. Monitor both free bytes and free inodes. Keep backups on separate storage; a backup on the same disk does not protect against disk failure.

Viewer capacity is usually limited by outbound bandwidth when media is served directly.

A rough estimate is:

required outbound Mbps ≈ simultaneous viewers × average delivered bitrate in Mbps

For example, 100 viewers receiving an average 3 Mbps stream need about 300 Mbps before protocol overhead and other site traffic. A “1 Gbps” port does not guarantee a sustained 1 Gbps allowance; check the hosting plan's transfer and fair-use limits.

AVideo CDN can serve repeated media requests away from the origin. CDN Storage adds managed remote capacity and integrated CDN delivery.

AVideo supports unlimited simultaneous live streams and unlimited viewers at the software level. This is a strong advantage: you can keep expanding without a fixed per-stream platform limit. The real capacity comes from input bitrate, transcoding, CPU speed, disk speed, and outbound bandwidth.

For a large live event, combine the Live plugin with AVideo CDN. Test the intended quality and audience before the event, then keep extra capacity for a sudden surge.

The older guide reported a real-world planning experience of approximately 100 simultaneous viewers on a 100 Mbps connection and 1,000 viewers on a 1 Gbps connection when adaptive live qualities were used. That implies an average delivery near 1 Mbps per viewer and does not apply to every broadcast. A 5 Mbps 1080p stream, for example, fits far fewer viewers. Use the actual bitrate table in the Live plugin guide, leave overhead capacity, and load-test before selling an audience limit.

See Adaptive Bitrates on Livestream and the Live Plugin guide.

Consider separate servers or managed services when:

• Encoding makes the website slow.
• Live transcoding competes with uploads.
• The database or media disk is a single point of failure.
• Viewer traffic approaches the server's sustained network limit.
• Maintenance on one component must not stop everything else.

Measure first. Separating services adds cost and more connections to configure and monitor.

The following screenshots are from an earlier 4K test. The interface may look different today, but the example still shows why temporary working space matters.

One 40 MB source produced several qualities:

The two-minute source generated up to seven qualities in that test: 2160p, 1440p, 1080p, 720p, 480p, 360p, and 240p.

The HLS working total included the generated qualities, original/chunked temporary data, and an archive/transfer file used by that workflow. These exact temporary files can differ in a current release, but the example explains why “my source is only 40 MB” is not enough for disk planning.

The earlier guide showed the working-space calculation in more detail:

The same file can briefly exist in more than one place. This is why you must plan for peak processing space, not only the final library size.

You can reduce disk and encoding work by selecting only the resolutions your audience needs in CustomizeAdvanced.

As the site grows, separate the Streamer, Encoder, Live server, storage, and database so each part can scale independently.

How many viewers fit on my server? Divide usable outbound Mbps by the average delivered video bitrate, then leave capacity for overhead and other traffic. CPU is important for encoding/transcoding, but network is usually the direct-delivery limit.

Does adding RAM make encoding faster? It prevents memory pressure, but FFmpeg speed is usually driven more by CPU/GPU, the selected codec/qualities, and storage performance after enough RAM is available.

How much disk does one upload need? More than the source size. Allow room for the original, temporary work, thumbnails, MP4/HLS outputs, and backups. The 4K example above shows how one 40 MB input produced much larger working/output totals.

Can the Streamer and Encoder share one server? Yes for a small site, but an encoding job can compete with PHP, database, and playback. Separate them when uploads affect visitor performance.

What should I check when traffic grows suddenly? Measure origin bandwidth, CPU, storage, and cache behavior. Consider AVideo CDN for delivery and CDN Storage when local disk growth is also a problem.