Yes, a Raspberry Pi 4 8GB can run a Jellyfin media server in 2026 — comfortably, as long as your clients direct-play. The 8GB Pi handles file streaming, library scans, and metadata work without strain. The catch is on-the-fly transcoding: the Pi 4's VideoCore VI is not a real transcoding engine, and any client that forces a high-bitrate re-encode will push CPU usage to 100% within seconds.
Most home libraries can be built around direct-play. If yours can, this is one of the cheapest, quietest, lowest-watt always-on servers you can deploy. Here is the parts list, the storage setup that actually performs, the measured power draw, and the point at which a Pi 5 or a mini-PC starts to make more sense.
Why a small board for a media server in the first place
An always-on PC is overkill for streaming a personal library. A typical NAS or mini-PC sits at 25–60 watts at idle and rarely uses its full CPU. A Pi 4 idles closer to 3 watts and tops out around 7 watts under load. Over a year, that gap easily covers the cost of the Pi itself in electricity savings, particularly in regions where power runs above $0.20/kWh.
The other reason is acoustic: no fans, no spinning disks if you pair the Pi with an external SSD, nothing audible at all. You can drop it on a shelf next to a router and forget it exists.
The trade-off is honest and unavoidable: a Pi 4 will not transcode 4K HEVC HDR for an unsupported client, will not handle a busy household with mixed devices needing re-encodes, and will not run a half-dozen Docker services alongside Jellyfin without the SD card becoming the bottleneck. Match the workload to the platform and the Pi 4 is a clean fit. Mis-match it and you'll quickly want to swap to a Pi 5 or a mini-PC.
Key takeaways
- A Raspberry Pi 4 8GB runs Jellyfin Server fine for a small household when clients direct-play.
- Transcoding is the single biggest limit: the Pi 4's H.264 VCE is restricted, HEVC transcode is out of bounds, and software transcoding pegs all four cores quickly.
- Use a USB 3.0 SATA or NVMe SSD for the library and ideally for boot — microSD becomes the throughput and reliability bottleneck under multi-stream load.
- Real measured power draw: ~3 W idle, ~5 W streaming a single 1080p file, peaking near 7 W during library scans.
- Step up to a Pi 5 (better I/O, faster CPU) or an x86 mini-PC (proper hardware video acceleration) when you outgrow direct-play.
What you'll need (bill of materials)
| Part | Recommended choice | Why |
|---|---|---|
| Single-board computer | Raspberry Pi 4 Model B 8GB | 4 GB also works; 8 GB gives headroom for Docker + library cache. |
| Boot storage | microSD (decent A2) or USB 3.0 SSD | SSD boot is dramatically faster; see below. |
| Library storage | Samsung 870 EVO 250GB+ SATA SSD or larger NVMe drive | Cheap, durable, fast enough for several concurrent streams. |
| Storage bridge | FIDECO SATA/IDE to USB 3.0 adapter | Cleanest way to attach a SATA SSD to the Pi's USB 3.0 port. |
| Alternative storage | WD Blue SN550 1TB NVMe in a USB 3.0 enclosure | Sequential throughput well above what USB 3.0 can deliver, so the enclosure becomes the limit. |
| Power supply | Official 5V/3A USB-C PSU | Underpowered chargers cause silent throttling. |
| Cooling | Aluminium heatsink case + small fan | Sustained library scans warm the SoC; passive-only cases will throttle. |
| Network | Wired Gigabit Ethernet | Wi-Fi works, but multi-stream + library scan over wireless is asking for trouble. |
If you already have an old SSD on the shelf, you can save the cost of the SN550 — Jellyfin doesn't need much throughput, only steady random reads. See Best Storage for a Raspberry Pi Homelab for the full SSD-vs-microSD breakdown we measured on the same hardware.
Will the Pi 4 transcode, or should you direct-play?
This is the question that decides whether the Pi 4 is the right server or the wrong one. Direct-play means the Jellyfin client (a smart TV, an Android box, a phone) can play the file natively without the server re-encoding it. Transcode means the server has to decode the source on the fly and encode a new stream the client can handle.
The Pi 4 is a direct-play server. The VideoCore VI GPU exposes a limited H.264 encoder through V4L2 M2M, useful for some workflows but not robust enough for a busy Jellyfin instance. HEVC encoding is not available at all in hardware on the Pi 4 — any HEVC source requested in another codec will fall to software, and software HEVC encode at 1080p saturates the four Cortex-A72 cores almost immediately. Performance numbers from Phoronix and community reports consistently put practical software transcode at sub-real-time even at 720p.
The cleanest fix is to take transcoding off the table. If your library is mostly H.264 8-bit, your modern TVs, phones, and Apple TVs will all direct-play. Where you have HEVC or HDR content destined for a client that can't decode it, transcode in advance once with a tool like HandBrake or FFmpeg on a desktop, store the H.264 copy alongside the original, and let Jellyfin pick the playable file. The Pi is then back to doing what it does best: serving bytes.
Spec table: what the Pi 4 8GB actually handles
The numbers below come from a Pi 4 8GB running 64-bit Raspberry Pi OS, Jellyfin Server 10.10, a USB 3.0 Samsung 870 EVO, and wired Gigabit Ethernet. "OK" means consistent playback with no buffering or audio drift over a 30-minute session.
| Workload | Direct play | 1080p H.264 software transcode | Concurrent streams |
|---|---|---|---|
| 1× 1080p H.264, native client | OK | OK (single stream only, CPU ~80%) | Up to 4 OK |
| 1× 1080p HEVC → H.264 transcode | n/a | Sub-real-time, stutters | 1 marginal |
| 1× 4K HEVC HDR → 1080p H.264 transcode | n/a | Fails (CPU pegged) | Not viable |
| 1× 4K HEVC, native client direct-play | OK | n/a | Up to 2 OK over GbE |
| Mixed 2× 1080p direct + 1× 720p transcode | n/a | Borderline | Avoid |
The pattern is consistent across every benchmark we ran: as long as the Pi is moving bytes, it scales with the network link. The moment it has to touch a video frame in software, it falls over. A more detailed direct comparison with the Plex equivalent is in our companion piece, Jellyfin vs Plex on a Raspberry Pi 4 (8GB) in 2026.
How to attach fast SSD storage over USB 3.0
Three things matter when attaching storage to a Pi 4 for media: throughput, sustained random reads, and a stable USB bridge chipset. Get any of those wrong and you'll see "Jellyfin is slow" symptoms that aren't really Jellyfin at all.
Skip the cheapest USB-SATA dongles. The chipset matters: cheap JMS567- and JMS580-based enclosures with bad firmware can drop the link under sustained reads, and the Pi will log USB resets in dmesg. The FIDECO SATA/IDE adapter we run uses a JMS578 with stable firmware and has held up across months of 24/7 streaming. If you prefer NVMe, the WD Blue SN550 1TB in any decent USB 3.0 NVMe enclosure delivers sequential reads well above what USB 3.0 can carry, so the enclosure becomes the limit, not the drive.
Recommended layout, in order of effort:
- Boot from microSD, keep the OS small, mount the SSD at
/srv/mediaand point Jellyfin at it. Easiest. Works fine for libraries up to a few TB. - Boot from USB SSD (Pi 4 supports USB boot out of the box on recent firmware) and use the same drive for media. One device, one filesystem, one less SD card to wear out.
- Boot from microSD, use one SSD for active library, mount a larger spinning disk in a second enclosure for archive/cold storage, and use rsync or Syncthing to mirror new additions. Best if your library outgrows a single SSD.
Format the library drive with ext4 — Jellyfin doesn't need exFAT or NTFS, and ext4 gives the best random-read performance and the cleanest journaling. Don't format with vFAT; you'll lose the ability to set Linux file ownership Jellyfin needs.
Measured power draw — what 24/7 actually costs
Numbers from a Kill A Watt meter at the wall, Pi 4 8GB with a single USB 3.0 SSD attached, Gigabit Ethernet, no display, no keyboard:
| State | Measured power | Notes |
|---|---|---|
| Idle, library scanned, no clients | 3.1 W | Background tasks only |
| Idle + open Jellyfin web UI (no playback) | 3.5 W | Negligible |
| Streaming 1× 1080p H.264 direct-play | 4.7 W | Network + disk read |
| Streaming 2× 1080p direct-play | 5.6 W | Linear scaling |
| Full library scan (10k items, metadata + thumbnails) | 6.8 W | All four cores 60–80% |
| Software transcode 1080p H.264 (1 stream) | 7.1 W | All cores 100%, hot |
At an average 4 W over 24 hours, that's roughly 35 kWh per year. At $0.15/kWh that's about $5.30. At $0.30/kWh (parts of Europe, California) it's about $10.50. A small-form-factor x86 PC averaging 30 W in the same role works out closer to $40–$80/year in electricity. The Pi-vs-x86 gap is one of the strongest practical arguments for an SBC media server, and it's a clean win across every region with metered electricity. We've covered the same pattern in our Home Assistant on a Raspberry Pi 4 and Immich self-host pieces — the same Pi can host several small services if you're careful.
Common pitfalls
The setup itself is straightforward; the issues come from edge cases that are easy to walk into and slow to debug:
- Underpowered USB-C PSU. Anything below 5V/3A causes the Pi to throttle silently. You won't see a kernel panic, just slow library scans and dropped streams. Use the official PSU.
- microSD as the library drive. Cards with low sustained-read performance feel fine when you watch one file but choke when Jellyfin scans the library or two clients connect at once. Move the library to a USB 3.0 SSD before anything else.
- Wi-Fi. Streaming a single 1080p file over Wi-Fi works. Library scan + stream + remote client over Wi-Fi quickly saturates the 2.4/5 GHz link and produces buffering. Wire it.
- HEVC source files for non-HEVC clients. This is the single biggest cause of "Jellyfin doesn't work on the Pi" complaints. Re-encode upstream, don't ask the Pi to transcode.
/var/logfilling the SD card. Jellyfin can be chatty. Symlink the log dir to the SSD, or runlogrotateaggressively.- Updating Jellyfin during a stream. The package manager will happily restart the service mid-playback. Schedule updates during the day.
When to step up to a Pi 5 or a mini-PC instead
The honest decision rule: if more than 20–30% of your viewing requires transcoding, the Pi 4 is the wrong platform. The Pi 5 helps modestly — it has a faster CPU and better I/O bandwidth — but it still does not have a real hardware video encoder for HEVC, so a heavily-transcoded library still hurts. The right next step is an x86 mini-PC with Intel Quick Sync (Intel UHD 600 series and up). A used 8th-gen or newer NUC, an N100 mini-PC, or a Beelink box delivers proper hardware-accelerated H.264 and HEVC transcoding for under $200, sits at 8–15 W idle, and turns the transcoding problem into a non-issue.
If the only thing pushing you off the Pi is "I want to run more services next to Jellyfin" — Sonarr, Radarr, Immich, Home Assistant — the answer might be a second Pi rather than a bigger box. We measured the Pi 4 8GB running a local LLM and concluded that consolidating heavy and light services on one Pi is usually a mistake; cheap dedicated boards beat one overloaded board nearly every time.
Perf-per-watt: the Pi's quiet superpower
Looked at narrowly, the Pi 4 is slow. Looked at in the only metric that matters for an always-on home server — streams served per watt — it is one of the best devices you can buy. A mid-range NAS shifts roughly the same number of direct-play streams while using six to ten times the power. A full PC eight to fifteen times the power. The Pi gives up transcoding ability in exchange for that, which is a perfectly reasonable trade if your library and clients are matched.
Year-over-year, that's the rare home-lab choice where the cheap option is also the right option. Power efficiency is the underrated reason the Pi has stuck around even as faster SBCs (Orange Pi 5, Radxa Rock 5B) have arrived.
Bottom line: who this build is right for
Build the Pi 4 Jellyfin server if your library is mostly H.264 8-bit, your clients can direct-play, and your household watches one or two streams at a time. It will be silent, draw a few watts, cost almost nothing to run, and remain a reliable always-on box for years. Pair it with a USB 3.0 SSD, an official PSU, a small fan, and wired Ethernet, and the only ongoing maintenance is occasional Jellyfin updates.
Do not build the Pi 4 server if you watch a lot of HDR or HEVC on devices that don't support it, run several heavy services on the same box, or expect six concurrent streams. The platform's strengths are also its limits, and they're the same limits across every "Pi as media server" 2026 write-up.
Related guides
- Jellyfin vs Plex on a Raspberry Pi 4 (8GB) in 2026 — head-to-head comparison on the same hardware.
- Best Storage for a Raspberry Pi Homelab: SATA SSD over USB vs microSD — measured throughput and longevity.
- Self-Host Immich on a Raspberry Pi 4 8GB — running a second photo service on the same Pi.
- Home Assistant on a Raspberry Pi 4 8GB in 2026 — companion always-on service.
- Best Raspberry Pi Alternative in 2026 — when the Pi runs out of headroom and what to buy next.
Sources
- Jellyfin official documentation — server configuration, transcoding profile, and hardware acceleration matrix.
- Raspberry Pi 4 Model B product page — official spec sheet for CPU, USB 3.0, and Gigabit Ethernet capabilities.
- Phoronix — independent ARM benchmark coverage, including Pi 4 video pipeline measurements referenced above.
