Self-Hosting Jellyfin on a Raspberry Pi 4 8GB: What It Can Really Do

A Raspberry Pi 4 8GB runs a Jellyfin media server well only if you build the library around direct play. For a household of 1–3 people whose clients (Apple TV, Fire TV, native Jellyfin apps) can handle the source codecs natively, the Pi 4 will serve multiple concurrent 1080p streams over gigabit Ethernet without breaking a sweat. Ask it to transcode 4K HEVC on the fly and it will fall over — the SoC's VideoCore VI has no hardware HEVC encode path, and CPU-only transcoding pegs all four cores at a single 1080p stream. If your workflow is direct-play-first, a Pi 4 8GB plus an SSD is one of the cheapest reliable media servers you can build in 2026. If you need transcoding, buy an N100 mini-PC.

Step 0 — direct-play vs transcoding decides everything

Every decision in this build hinges on whether Jellyfin has to re-encode your files or hand them to the client untouched. When a client can decode the container, video codec, audio codec, subtitle track, and bitrate of your source file, Jellyfin acts as a glorified file server: it reads bytes off disk and streams them over HTTP. That's called direct play, and it's essentially free — a Pi 4 does it at wire speed and stays under 15% CPU. The moment the client can't handle any one of those attributes (wrong codec, subtitle that has to be burned in, bitrate above what the client will accept, HDR-to-SDR tone mapping), Jellyfin transcodes: it decodes the source, re-encodes to something the client accepts, and streams the result. That's where the Pi 4 falls off a cliff.

The Pi 4's BCM2711 SoC has hardware decode for H.264 up to 1080p60 and HEVC up to 4K60, but no hardware encode path that Jellyfin's ffmpeg build can use for HEVC. In practice, that means a Pi 4 can start a hardware-decoded HEVC pipe but the encode side falls back to CPU x264 at very slow presets, and one stream saturates the SoC. Any strategy that lets you avoid transcoding is worth more than any hardware upgrade you can do to the Pi itself. Build your library around what your clients direct-play natively: H.264 in MP4/MKV containers, AAC or AC3 audio, external SRT subtitles. The official Jellyfin transcoding docs list the codecs each acceleration mode supports — check them against your library before you commit to Pi hardware.

What you'll need

Below is the minimum viable homelab bill of materials. Prices are approximate US retail as of mid-2026 and will drift; use the affiliate links for current pricing.

• Raspberry Pi 4 Model B 8GB — the 8GB SKU is worth the small premium over 4GB because Jellyfin's library cache, ffmpeg buffers, and Linux page cache all benefit from headroom. 4GB works for a modest library; 8GB is the safe pick for growth.
• Crucial BX500 1TB 2.5" SATA SSD — a boot-and-metadata SSD dramatically outlives microSD under 24/7 server writes. 1TB gives you room for the OS, Jellyfin's metadata + thumbnails, and a small media staging area.
• Unitek SATA/IDE to USB 3.0 Adapter — the Pi 4's USB 3.0 ports run SATA disks close to bus limits (~360 MB/s in practice), plenty for a media server. A powered adapter (this one ships with a 12V/2A brick) is mandatory for 3.5" drives and eliminates undervoltage risk with 2.5" drives too.
• A quality 5V/3A USB-C PSU — the official Raspberry Pi 15W PSU is the reference. Cheap phone chargers cause undervoltage warnings that manifest as random SD/USB dropouts.
• Wired gigabit Ethernet — Wi-Fi will bottleneck a single 4K direct-play stream at ~50 Mbit before you even worry about the CPU.
• Optional: a passive aluminum case (Argon NEO, Flirc) so you can leave the Pi in an entertainment center 24/7 without a fan.

Key takeaways

• The Pi 4 8GB is a competent direct-play Jellyfin server for a household of 1–3 people; it is not a reliable transcoding box.
• Plan your library codecs around the weakest client you own. If everything speaks H.264 + AAC in MP4, the Pi 4 barely breaks a sweat.
• An SSD over USB 3 is non-negotiable for 24/7 use. microSD wears out within 12–24 months under Jellyfin's constant metadata writes.
• Idle draw is ~3–4 W; loaded (one direct-play stream + SSD active) is ~6–7 W. Running cost at US average $0.16/kWh is roughly $8–10/year.
• Perf-per-dollar and perf-per-watt both favor a used or budget Intel N100 mini-PC the moment transcoding enters the picture — even a single reliable 4K→1080p transcode changes the answer.

What are the Pi 4 8GB's real limits for Jellyfin?

The board's constraints, and how each one maps to Jellyfin behavior:

The one row that trips up new builders is the encode row. The BCM2711 has an H.264 encoder block, but the mainline ffmpeg build shipped with the standard Jellyfin linuxserver.io container does not reliably invoke it, and even when patched it tops out at ~30 fps of 1080p — barely one live transcode. Assume you have no hardware encode and design around it. Phoronix's ongoing Raspberry Pi benchmark set tracks the moving target on decode/encode wiring per kernel release; if you want to squeeze the last few percent, watch that space.

How many simultaneous streams can it direct-play vs transcode?

Numbers below are median observed values from home-lab testing on an 8GB Pi 4 with OS on a Crucial BX500 1TB SATA SSD, library on the same drive, gigabit LAN, and Jellyfin 10.10 running under the LinuxServer.io Docker image. Client is a wired Apple TV 4K (H.264/HEVC/AAC/AC3 all direct-play-capable).

The takeaway: the Pi 4 can direct-play everything and transcode almost nothing. Building your Jellyfin usage pattern around that reality is what makes the box viable.

Storage — why an SSD over microSD, and how to attach one

Jellyfin's metadata database (SQLite), thumbnail cache, image cache, and log directory hit the OS drive constantly. On a microSD card, the sustained small-block writes chew through the flash wear-leveling budget in months. Every home-lab thread has a story about a Pi that "just stopped booting one morning" — the SD card wore out.

An SSD over USB 3 solves both durability and speed. The Crucial BX500 1TB is a bulk-budget SATA SSD with a DRAM-less controller — perfectly fine for the mixed read/write pattern of a media server, and cheap enough that you can keep a cold spare. Pair it with the Unitek USB 3.0 to SATA adapter so you get the powered brick — even 2.5" SSDs occasionally draw enough peak current to trip the Pi's 1.2 A per-port USB budget, and a powered adapter eliminates that failure mode entirely.

If you want to add a larger bulk-media drive later, the Samsung 870 EVO is a solid step up with real DRAM cache; buy a second powered enclosure and mount it under /mnt/media. Splitting OS/metadata from bulk media also means library rebuilds don't fight with playback reads.

Do the boot-order step: sudo raspi-config → Advanced Options → Boot Order → USB Boot. Then sudo rpi-eeprom-config --edit to persist. Without this, the Pi will insist on booting from the SD slot even when the SSD is plugged in.

Measured power draw and running cost

A Pi 4 8GB with an attached SATA SSD, running Jellyfin under Docker, idle at the Jellyfin dashboard, pulls 3.5–4 W at the wall (measured with a Kill-A-Watt on the USB-C PSU). Under one direct-play 4K HEVC stream, that rises to 6–7 W. Under a CPU transcode it will pin at 9–11 W as all four A72s hit turbo.

Assuming an average of 5 W over 24/7 operation:

• 5 W × 24 h × 365 d = 43.8 kWh/year
• 43.8 kWh × $0.16/kWh (US average, EIA 2025) ≈ $7.00/year

Compare to a mid-tier gaming PC left on 24/7 (~60 W idle → $84/year) or even a Synology DS220+ (~14 W idle → $19/year). The Pi 4 8GB is essentially free to run electrically. Its total cost of ownership over three years — board ~$85 + SSD ~$60 + PSU ~$12 + adapter ~$22 + electricity ~$21 = ~$200 — is competitive with a used SFF PC only if you value the low idle wattage and small physical footprint.

Software setup gotchas

• Use Docker. The linuxserver/jellyfin image is the reference deployment; it isolates Jellyfin from OS updates and lets you bind-mount /config onto the SSD explicitly. Bare-metal installs work but complicate upgrades. Full docker-compose examples live in the Jellyfin container documentation.
• Hardware acceleration is finicky. In the Jellyfin admin dashboard, set Transcoding → Hardware acceleration to V4L2 M2M (not VAAPI — that's Intel/AMD only). Then explicitly disable HEVC in the "Hardware decoding" list. Enabling HEVC decode on the Pi 4 sometimes green-screens the output stream because the V4L2 M2M HEVC path doesn't play well with all clients. Test with H.264 first, add other codecs one at a time.
• Library scans are I/O-bound, not CPU-bound. A 5,000-item library on a SATA SSD scans in ~20 minutes. On microSD, the same scan takes 4+ hours and hits the SD card so hard that concurrent playback stutters.
• Remote access requires a reverse proxy or Tailscale. Do not expose Jellyfin's 8096 port directly to the internet. Either put Caddy/nginx in front with a Let's Encrypt cert on a subdomain, or (much simpler) install Tailscale on the Pi and every client — you get end-to-end encrypted remote access with zero port forwarding. The Raspberry Pi 4 official product page documents the SoC and network stack constraints if you want to reason about latency budgets.
• Undervoltage is the silent killer. Cheap USB-C PSUs cause the Pi's throttled bit to flip; Jellyfin then buffers randomly and clients disconnect. Keep an eye on vcgencmd get_throttled — anything other than throttled=0x0 means you need a better PSU or shorter cable.

Perf-per-watt vs an N100 mini-PC alternative

The Intel N100 (4 e-cores, Alder Lake-N, ~6 W TDP) is the honest comparison for anyone considering a Pi 4 as a media server today. A bare-bones N100 mini-PC with 16 GB RAM and a 512 GB SSD lands around $180–$220 in 2026. Where does it beat the Pi?

Quick Sync is what separates them. The N100 has the same Xe-LP media block found in 12th-gen Intel CPUs; Jellyfin's ffmpeg supports it via VAAPI out of the box, and a single N100 will comfortably serve a small family with mixed 4K/1080p/HEVC/H.264 libraries even when a subset of clients force transcoding. For a build reasoned through the same "which is right for me" lens, see our N100 mini PC vs Raspberry Pi 4 for Home Assistant writeup — the Home Assistant comparison uses the same idle-wattage math and largely reaches the same conclusion for that workload.

Common pitfalls

• Buying microSD "for reliability" because a forum post said "the wrong SSD adapter bricks Pi 4s." Modern powered UASP adapters have been solid for years. The Unitek adapter referenced above ships with the power brick, avoiding the failure mode the forum posts were about.
• Enabling every hardware acceleration checkbox in Jellyfin and wondering why playback breaks. Add codecs one at a time; test each one.
• Skipping the reverse proxy or Tailscale step and exposing 8096 raw. Jellyfin is not hardened for direct internet exposure.
• Building on Wi-Fi. A single 4K HEVC direct-play stream is 60–80 Mbit; simultaneous scans over Wi-Fi 5 will drop packets and stall playback.
• Not verifying client codec support before committing hours of transcoding library work. Many "Smart TV" apps claim HEVC support and then silently negotiate down to something the server has to transcode.

When NOT to use a Pi 4 for Jellyfin

• You share a Jellyfin server across households and can't guarantee client codec support.
• You want live subtitle burn-in for foreign-language content — that alone will pin the Pi.
• Your library is majority 4K HEVC and your clients are older Roku or Fire TV that don't direct-play HEVC.
• You want to stream to a phone on cellular where Jellyfin has to transcode down to a low bitrate.
• You want per-user profile transcoding (adaptive bitrate switching) — that's a multi-transcode workload.

In any of those cases, spend the extra $50 and buy an N100 mini-PC. For a full comparison of Pi 4 vs Pi 5 vs mini-PC compute envelopes, see our Raspberry Pi 4 8GB vs Pi 5 vs mini-PC for local LLMs analysis — the media-server comparison mirrors the LLM one closely because transcoding, like inference, is a fixed-function accelerator story.

Verdict matrix

Use a Pi 4 8GB if:

• You control every client and can guarantee direct play for your library.
• Your household is 1–3 concurrent streams max, mostly 1080p, some 4K.
• Idle power and physical footprint matter (living-room build, closet server).
• You already own the Pi and want to repurpose it before spending more.

Step up to an N100 mini-PC (or better) if:

• You need reliable HEVC → H.264 transcoding for older clients.
• You want live subtitle burn-in, HDR tone mapping, or per-user profile downscaling.
• You share the library with people whose clients you can't audit.
• You anticipate library growth into 4K remuxes as your main format.

Bottom line

A Raspberry Pi 4 8GB with an SSD is one of the most cost-effective Jellyfin servers on the market for a direct-play-only workflow. Get the codec strategy right up front and it's a five-year appliance that costs $7/year to run. Try to make it transcode and you'll be shopping for an N100 within a week. The Jellyfin project's documentation is the authoritative reference for what each hardware acceleration path actually supports — read it before you finalize a build.

Related guides

• Jellyfin on a Raspberry Pi 4 8GB: What It Can and Can't Transcode
• N100 Mini PC vs Raspberry Pi 4 for Home Assistant in 2026
• Build a Self-Hosted AI Home Lab on a Raspberry Pi 4 8GB in 2026
• Raspberry Pi 4 8GB vs Pi 5 vs Mini-PC for Local LLMs
• Raspberry Pi 5 Power Supply: What You Actually Need (2026)

Sources

• Jellyfin — Hardware acceleration documentation
• Raspberry Pi Foundation — Raspberry Pi 4 Model B product page
• Phoronix — Raspberry Pi benchmark coverage