Raspberry Pi 4 8GB as a Jellyfin Media Server: Real Limits

Can a Raspberry Pi 4 8GB actually run a Jellyfin server for your family?

Yes, with a caveat. As of 2026, a Pi 4 8GB handles direct-play 1080p H.264 to two or three viewers cleanly. It collapses on 4K HEVC software transcoding because the BCM2711 has no H.265 hardware encoder. Build the library around direct-play and the Pi 4 is fine; rely on transcoding and it is not.

The Pi 4 8GB as a low-power always-on media box

The Raspberry Pi 4 Model B 8GB is the cheapest credible 24/7 self-hosted media server you can buy new in 2026. Idle power draw sits around 3-4 W at the wall and peaks near 7-8 W under full CPU load, per Raspberry Pi Foundation power figures and community measurements published on the Raspberry Pi product page. That puts the annual electricity bill for a Pi 4 Jellyfin box at roughly the cost of a single restaurant meal — orders of magnitude below a recycled tower PC or a NAS appliance running x86 silicon.

The Pi 4 8GB's headline silicon is the Broadcom BCM2711, a quad-core ARM Cortex-A72 clocked at 1.5 GHz (firmware-overclockable to 1.8-2.0 GHz with adequate cooling). It pairs with 8 GB of LPDDR4-3200 SDRAM — enough headroom for Jellyfin, its SQLite metadata database, a reverse proxy, Tailscale, and a handful of supporting containers without swap thrashing. The board exposes two USB 3.0 ports (the channel that matters for external storage), two USB 2.0 ports, Gigabit Ethernet on a dedicated PCIe lane (not muxed through USB as on the Pi 3B+), and dual micro-HDMI. There is no PCIe slot, no SATA, and no NVMe on the board itself; storage strategy has to route over USB 3.0 or, less ideally, a microSD card.

The practical takeaway: the Pi 4 8GB has enough RAM, enough CPU for media metadata and HTTP fan-out, and enough I/O for one well-fed Gigabit pipe. What it does not have is a modern hardware video encoder. That single gap shapes everything that follows in this synthesis.

Key takeaways

• Direct-play 1080p H.264 to two or three concurrent clients works reliably on a Pi 4 8GB; CPU sits in the single-digit-percent range because the Pi is moving bytes, not re-encoding pixels.
• The BCM2711 has H.264 hardware decode via V4L2 M2M but no hardware H.265 (HEVC) encoder and no AV1 acceleration. Any forced transcode to H.264 runs on the four A72 cores in software.
• One software 1080p H.264 transcode pins all four cores at or near 100% load per community measurements on r/selfhosted and lawrencesystems write-ups; a second concurrent transcode is not viable.
• 4K HEVC to H.264 software transcoding is not realistic on a Pi 4 — expect buffering, dropped frames, and client timeouts.
• Use a USB 3.0 SSD (not microSD) for the library and Jellyfin metadata. SATA SSDs in a UASP-capable USB enclosure are the sweet spot for cost, reliability, and throughput.
• When the household graduates to mixed 4K libraries or three-plus simultaneous transcodes, step up to an Intel N100 mini PC for hardware QuickSync encode; the Pi 4 stays as a hand-off Pi-hole or backup node.

What you will need

A Pi 4 Jellyfin build is intentionally short on bill of materials. The minimum viable list, as of 2026:

• Raspberry Pi 4 Model B 8GB — the 4GB and 2GB SKUs work but leave less headroom for parallel containers; the 8GB is the model worth buying for a server role.
• Official Raspberry Pi 5.1V/3A USB-C power supply, or an equivalent that won't trip undervoltage warnings under sustained USB-disk load.
• A 32 GB or 64 GB A2-rated microSD card for the boot/OS volume only — not for the media library.
• A 1 TB or 2 TB SATA SSD plus a UASP-capable USB 3.0 enclosure or bridge. The SanDisk Ultra 3D 1TB SATA SSD and the Crucial BX500 1TB SATA SSD are the two cheapest reliable choices in their class; pair either with a FIDECO SATA-to-USB 3.0 adapter for a direct connection, or drop the SSD into a fanless 2.5" USB enclosure.
• A heatsink case or the official Pi 4 active cooler. A 24/7 server in a closed cabinet will thermal-throttle without one. The official Raspberry Pi documentation warns about throttling above 80 C and hard-caps the SoC at 85 C.
• A Gigabit-capable wired network port. Wi-Fi works for trivial use but adds latency and jitter that hurt direct-play seek performance.

Optional but recommended: a small uninterruptible power supply (a USB-C UPS HAT or a desktop UPS) to survive utility blips without microSD corruption, and a Tailscale or WireGuard tunnel for remote streaming.

How many concurrent streams can a Pi 4 handle?

The honest answer separates the two cases.

Direct-play streams. When a Jellyfin client supports the source file's container, video codec, audio codec, and subtitle format natively, the server just opens the file and pipes bytes. CPU load on the Pi 4 sits in the single-digit percent range per the Jellyfin documentation and matches community measurements posted on r/selfhosted. In this mode, the Pi 4 8GB can comfortably feed 3-5 simultaneous 1080p direct-play sessions before Gigabit Ethernet or your upstream WAN becomes the cap. A typical 1080p Blu-ray remux runs 20-35 Mbps; five concurrent streams of that bitrate cleanly fit a 1 Gbps LAN.

Transcoded streams. The picture inverts the moment Jellyfin must re-encode. One software H.264 1080p transcode (the common fallback when a client cannot direct-play HEVC) saturates the four A72 cores. A second simultaneous transcode is not realistically supported — you get dropped frames, client-side buffering loops, or the second viewer's session hangs the first. Per Jellyfin's own hardware-acceleration guidance, the Pi 4's transcoding ceiling is roughly one 1080p H.264 stream at a time, and that is with low complexity HDR-free source material.

The practical concurrency number is therefore conditional: 3-5 simultaneous direct-play viewers, but only one transcode at a time. Designing client apps and library encoding around direct-play is the single biggest knob you can turn.

Why hardware transcoding is the real bottleneck

A modern Intel iGPU (Alder Lake-N N100, 12th-gen UHD 730, 13th-gen UHD 770) has QuickSync fixed-function blocks that can encode H.264 and HEVC at multiple streams' worth of throughput while burning a few watts. The Pi 4's BCM2711 does not. Its VideoCore VI GPU has an H.264 decode block that Jellyfin can target through Linux's V4L2 M2M API, but the encode side of the same block is anemic and not exposed through Jellyfin's official acceleration matrix as of 2026 — the Jellyfin hardware acceleration docs list V4L2 M2M on Pi as decode-only for practical purposes, with H.265 unsupported on encode.

What that means in real life:

• Decode-only acceleration helps a little. If a client can take an H.264 stream but the source is H.264 in a container the client cannot demux, Jellyfin can hardware-decode and then re-mux (no re-encode) — that path is cheap.
• Any encode runs on the CPU. A 4K HEVC source heading to an iOS app that only takes H.264 1080p means: software decode of HEVC (already CPU-heavy) plus software encode to H.264 (also CPU-heavy). On four 1.5 GHz A72 cores, that is sub-real-time. You watch the buffering wheel.
• Audio transcoding is fine. Re-encoding EAC3 or TrueHD down to AAC stereo is cheap on the CPU and the Pi handles it without breaking direct-play of the video track.

The upshot: pre-encode your library to formats your clients direct-play, or accept that one transcode at a time is the ceiling. There is no firmware update that fixes this; it is a silicon limitation of the BCM2711.

Spec table: Pi 4 8GB and storage stack

In 2026 the cheapest reliable storage build is a 1 TB SATA SSD (SanDisk Ultra 3D or Crucial BX500) connected through a UASP USB 3.0 bridge such as the FIDECO SATA-to-USB 3.0 adapter. UASP matters: it lets the kernel queue SCSI commands over USB, which is the difference between ~80 MB/s and ~350 MB/s on the same drive.

Benchmark table: direct-play vs transcode CPU load

The table below summarizes community-measured CPU load on a Pi 4 8GB running Jellyfin 10.9.x on Raspberry Pi OS Bookworm 64-bit. Numbers vary with source bitrate, audio codec, and subtitle burn-in; treat them as orders of magnitude, not absolutes.

Figures synthesized from r/selfhosted Pi 4 Jellyfin threads (2024-2026), lawrencesystems published Pi 4 media-server measurements, and the Jellyfin GitHub issue tracker where Raspberry Pi performance regressions are routinely benchmarked.

Storage: USB SSD vs microSD for library and metadata

The single biggest mistake a first-time Pi 4 media-server build makes is putting the Jellyfin metadata database — or worse, the library — on the microSD card. Three reasons not to:

1. Endurance. Consumer microSD cards are rated for far fewer program-erase cycles than even budget SATA SSDs. Jellyfin's SQLite database is rewritten on every scan; sustained writes wear the card out in months. Reddit's r/selfhosted has a steady drumbeat of "Pi died after 14 months" posts that almost always trace back to the boot microSD.
2. Throughput. A good A2 microSD tops out near 80-100 MB/s read in real-world Pi 4 conditions. A SATA SSD over UASP USB 3.0 sustains 350-400 MB/s. For a Jellyfin library scan over thousands of files, the difference is hours.
3. Power-loss resilience. Power-loss events corrupt microSD cards far more often than they corrupt SSDs with capacitor-backed write caches. Even a basic SATA SSD on a UPS-backed Pi gives you years of headroom.

The recommended pattern: boot from a small USB SSD or pair a microSD for the boot partition with a much larger USB SSD for /var/lib/jellyfin (the metadata) and a mount for the media library itself. The 1 TB tier is the price-per-gigabyte sweet spot in 2026 for both the SanDisk Ultra 3D and Crucial BX500 — either delivers consistent sequential reads well above the Pi's USB 3.0 ceiling and is rated for hundreds of TBW. Spinning USB HDDs work but draw more power, generate more heat, and click audibly during library scans; SSDs are the modern default.

If the library outgrows 1 TB, two options: a larger single SSD (2 TB or 4 TB), or a USB-powered 2.5" HDD for cold storage with the SSD reserved for hot files and metadata. Avoid USB hubs in the storage path unless the hub is powered — bus-powered hubs are the second most common cause of mystery Jellyfin disconnects on Pi 4 builds, after undervoltage.

Network and Tailscale for remote streaming

The Pi 4's Gigabit Ethernet on a dedicated PCIe lane is the right interface for streaming. Wire the Pi to a switch; treat Wi-Fi as out-of-band management only. A single 1080p H.264 direct-play stream uses 5-15 Mbps; a 4K HEVC direct-play stream uses 30-80 Mbps. Five concurrent 4K direct-play streams comfortably fit within a Gigabit LAN, but a single 4K HDR remux pushed across a typical residential WAN upload (often 10-30 Mbps in 2026) will not direct-play remotely — it has to transcode, and the Pi 4 cannot.

For remote access without exposing port 8096 to the public internet, Tailscale is the path of least resistance: install the Tailscale client on the Pi, install it on remote clients, and the encrypted mesh handles NAT traversal and authentication. WireGuard works similarly if you prefer self-managed keys. Either approach avoids the operational cost of running a reverse proxy and a Let's Encrypt cert refresh loop just for family streaming.

Install path: Docker vs apt

Two supported install paths exist on Raspberry Pi OS Bookworm. The official Jellyfin documentation supports both.

Apt repository. Add the Jellyfin team's Debian repo, install jellyfin, and the service runs under systemd. Upgrades are apt upgrade. Simpler for a single-purpose box.

Docker / docker-compose. Pull the official jellyfin/jellyfin image (multi-arch, includes arm64), mount the media directory and a config volume, and run. Easier to reset, easier to back up, plays well with other containers (Tailscale, Sonarr, Radarr) on the same Pi. Recommended if the Pi is going to host more than just Jellyfin.

Either way, set the V4L2 M2M acceleration toggle in the Jellyfin dashboard for H.264 decode and verify the /dev/video10 (or equivalent) device shows up in dmesg. Do not enable HEVC acceleration — it is not supported on Pi 4 and turning it on causes silent fallback or transcode failures depending on the Jellyfin version.

What works well

• Always-on availability. The Pi 4's 3-4 W idle draw and silent fanless operation (with a good heatsink case) make it the right shape for a 24/7 service.
• Direct-play to modern TVs and the Jellyfin Android/iOS apps. When the source codec matches the client, the Pi 4 is invisible — files just play.
• One household, two viewers, 1080p library. This is the canonical happy path: a Pi 4 with a 1 TB SATA SSD over USB 3.0 serving a few people who watch on smart TVs.
• Audio passthrough or simple AAC re-encode. Cheap on the CPU, leaves video direct-play intact.
• Library and metadata management. Jellyfin's scanner, chapter detection, and TheTVDB/TMDB metadata lookups run fine.

What does not work well

• 4K HEVC to H.264 on-the-fly transcode. Don't try it. Re-encode the library if a client cannot direct-play 4K HEVC.
• Multiple concurrent transcodes. One at a time is the ceiling; design around direct-play.
• Subtitle burn-in at scale. Forced burn-in on PGS or ASS subtitles eats CPU. Prefer clients that render text subtitles themselves.
• HDR tone-mapping. The Pi 4 lacks the silicon to tone-map HDR to SDR in real time; the result is washed-out output or transcode failures.
• High-bitrate 4K remux to remote clients on slow WAN. Bandwidth, not the Pi, is the limit — but the failure surface is the same.

When to step up to an N100 mini PC

The natural upgrade target in 2026 is an Intel N100 mini PC (or its N97/N305 siblings). Reasons to graduate:

• The household routinely needs more than one transcoded stream at a time.
• The library is mostly 4K HEVC and clients are mixed (some can direct-play, some cannot).
• HDR tone-mapping matters for a TV-and-iPad household.
• The DLNA/AirPlay endpoints in use force-transcode despite codec compatibility.

An N100 with 16 GB of RAM, an NVMe SSD, and QuickSync hardware encode runs Jellyfin with 4-6 simultaneous transcoded streams, including 4K HEVC -> 1080p H.264, while drawing 8-15 W idle and 25-30 W under sustained transcode load — still cheap to run, but with the hardware encode block the Pi lacks. The Pi 4 then becomes a backup node, a Pi-hole, a Home Assistant box, or a guest-room secondary Jellyfin instance.

Plex on the same hardware

Plex Media Server runs on the Pi 4 8GB through the official Linux ARM64 build and behaves similarly to Jellyfin for direct-play: 3-5 concurrent 1080p H.264 viewers are fine. Plex's transcoding pipeline imposes the same BCM2711 limits — one software transcode at a time, no usable HEVC encode. Plex layers in optional paid features (Plex Pass for hardware acceleration, mobile sync, DVR) and a more polished mobile experience; Jellyfin is free, open-source, and self-contained. For a homelab build, either works on the same Pi 4 hardware envelope. The choice is a UX and licensing question, not a hardware one.

Bottom line

As of 2026, the Raspberry Pi 4 Model B 8GB is a credible Jellyfin server for a small household that plans around direct-play. Pair it with a SanDisk Ultra 3D 1TB or Crucial BX500 1TB SATA SSD on a FIDECO USB 3.0 adapter, wire it to Gigabit Ethernet, cool it adequately, and it will quietly serve 3-5 simultaneous 1080p streams for years on a few dollars of electricity a month. Push it into 4K HEVC software transcoding and it breaks. Know which side of that line your library and clients sit on, and the Pi 4 8GB is the right hardware. If you sit on the wrong side, an N100 mini PC is the next step.

Related guides

• Buying guide: Best mini PCs for home servers (2026)
• Buying guide: Best SATA SSDs for NAS and homelab (2026)
• Category: Raspberry Pi boards and accessories
• Category: Self-hosting and homelab hardware

FAQ

Can a Raspberry Pi 4 8GB transcode 4K video?

Real-time 4K transcoding is beyond a Pi 4's practical ability, and pushing it leads to buffering and dropped streams. The Pi 4 shines when clients direct-play files in formats they already support, so no transcoding is needed. If your devices need on-the-fly 4K transcoding, a mini-PC with a modern iGPU is the better choice for a smooth experience.

How many simultaneous streams can the Pi 4 serve?

When clients direct-play compatible files, a Pi 4 8GB can comfortably feed several streams because it is mostly moving bytes off storage and over the network. The moment it must transcode, its CPU saturates fast and concurrency collapses to roughly one stream. Design your library and client apps around direct-play to maximize how many viewers it supports.

Should I store my media on microSD or a USB SSD?

Use a USB SSD for the media library and metadata, not the microSD card. SSDs over USB 3.0 are faster, far more durable under constant access, and avoid the corruption risk that kills microSD cards used as primary storage. A 1TB SATA SSD in a USB enclosure or adapter gives a Pi 4 a reliable, roomy media volume.

Does the Pi 4 need active cooling for a media server?

For a 24/7 server, add at least a heatsink and ideally a small fan or a cooling case, because sustained network and disk activity keeps the SoC warm and can trigger thermal throttling in an enclosed box. Good cooling keeps performance consistent and extends the board's life. A quality power supply is equally important to avoid undervoltage warnings.

When should I choose a mini-PC over a Pi 4 instead?

Step up to a mini-PC when you need reliable transcoding, multiple concurrent transcoded streams, or hardware video acceleration for incompatible client devices. A Pi 4 is ideal for low-power, direct-play setups and learning self-hosting cheaply. If your household streams diverse formats to many devices at once, a small x86 box with an iGPU is the more capable long-term server.

Citations and sources

• Jellyfin official documentation: https://jellyfin.org/docs/
• Jellyfin hardware acceleration matrix: https://jellyfin.org/docs/general/administration/hardware-acceleration/
• Jellyfin Linux installation guide: https://jellyfin.org/docs/general/installation/linux
• Jellyfin client compatibility reference: https://jellyfin.org/docs/general/clients/
• Raspberry Pi 4 Model B product page: https://www.raspberrypi.com/products/raspberry-pi-4-model-b/
• Raspberry Pi official documentation (thermal and cooling): https://www.raspberrypi.com/documentation/computers/raspberry-pi.html
• Jellyfin GitHub repository and issue tracker: https://github.com/jellyfin/jellyfin
• Tailscale (remote-access mesh used for off-LAN streaming): https://tailscale.com/
• Phoronix (Linux performance and benchmarking reference for ARM SBCs): https://www.phoronix.com/

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.