Emby is a media server for video, music, live TV and books with its own apps for TVs, phones and consoles. It sits between Plex and Jellyfin: self-hosted and account-optional like Jellyfin, but closed source with a paid Premiere unlock like Plex.
Our verdict on Emby#
Emby is the option people land on rather than choose. It went closed source at 3.5.3 in 2018, and Jellyfin is the fork of 3.5.2 that kept going, so the two still feel like relatives. Current stable is 4.9.5.0 (18 May 2026) with 4.10 in beta. The pitch is that Emby Premiere is a licence, not a platform tax: roughly $4.99/month, around $54/year, or $119 lifetime, and it unlocks hardware transcoding, mobile sync, cover art, DVR and the mobile apps. Nothing about your server phones home for permission to play locally, which is where it beats Plex post-2025. The tradeoff is a smaller ecosystem than Plex and no source you can audit or fork, which is exactly why Jellyfin exists. If you are paying anyway, compare a $119 Emby lifetime against a $249.99 Plex Pass lifetime, then compare both against $0.
Who Emby is for#
Choose it if
- You want Plex-style polish and DVR without Plex's cloud account sitting in the authentication path.
- You tried Jellyfin, hit a client or metadata problem you could not solve, and are willing to pay once to make it go away.
- You are running on an ARM64 NAS or SBC and want first-party hardware transcoding support with a licence rather than a subscription.
Look elsewhere if
- Source availability matters to you: builds are not reproducible and the build scripts are closed, so a fork is not an option if the project changes direction.
- You are not going to buy Premiere, in which case Jellyfin gives you hardware transcoding and mobile apps for free.
- You need broad third-party client support: the Emby app ecosystem is smaller than Plex's and smaller than Jellyfin's on some TV platforms.
What running it actually looks like#
One container. The official images are emby/embyserver for amd64 and emby/embyserver_arm64v8 for ARM64, published as separate repositories rather than a single multi-arch manifest, so a compose file copied from an x86 guide will pull the wrong image on a Pi. Mount /config for the database, metadata and licence state, and media read-only. Ports 8096 HTTP and 8920 HTTPS. First run is a wizard: language, an admin user, then libraries. Hardware transcoding requires an Emby Premiere key plus device passthrough, and Emby uses a GIDLIST environment variable to add supplementary groups rather than compose group_add, so you set GIDLIST to your host's render and video group IDs alongside --device /dev/dri:/dev/dri. Upgrades are a tag pull and have been undramatic across the 4.8 and 4.9 series.
Resource profile#
- Memory
- 350 MB idle, around 900 MB in ordinary use. The .NET server plus its library database at rest; scans, chapter image extraction and concurrent transcodes are what move the number.
- CPU and acceleration
- Direct play is cheap. Transcoding is the cost, and hardware acceleration through Quick Sync, NVENC or VAAPI is gated behind an Emby Premiere licence, so an unlicensed server transcodes on CPU only.
- Storage growth
- Artwork, chapter thumbnails and subtitle extractions under the config directory grow with the library; transcode temp needs several GB per active session and should not live on the container overlay.
- Operational load
- 2 of 5, Light. Single container, SQLite database, directory-copy backup, upgrades that rarely break. The extra point over a 1 is licence state to keep track of, plus device passthrough for transcoding that has to be re-checked after host driver updates.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Back up the whole config directory (/config in the container, /var/lib/emby on a package install). It holds data/library.db and the other SQLite files, config/*.xml including your server settings and users, plugins/, and metadata/ with downloaded artwork. The transcoding temp directory and cache/ are regenerable, so exclude them. Stop the container before copying the SQLite files, since a live copy can catch a partial write. Artwork returns from a rescan; watch state, users and collections do not. Your Premiere key is tied to the account rather than the config directory, so a restore onto new hardware needs the key re-entered, not recovered from backup.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
Hardware transcoding is licensed, not just configured
Passing /dev/dri into the container does nothing without an active Emby Premiere key. The UI will show the acceleration options, and transcodes will still run on CPU. Confirm licence state in Settings, Premiere before you spend an evening debugging VAAPI. On ARM64 this bites hardest because the alternative, software transcoding on an SBC, is usually not viable at all.
ARM64 is a different image, not a different tag
Emby publishes emby/embyserver for x86_64 and emby/embyserver_arm64v8 for ARM64 as separate Docker Hub repositories. Pulling emby/embyserver on a Raspberry Pi or ARM NAS either fails or gives you an exec format error rather than a clean architecture mismatch message. Set the image name per host instead of assuming the manifest sorts it out.
Group passthrough uses GIDLIST
Emby's container adds supplementary groups from the GIDLIST environment variable, which is not how Jellyfin or most other images do it. If you copy a Jellyfin compose fragment using group_add, device access may still fail because the Emby entrypoint sets up its own user. Find the host render and video GIDs and pass them as a comma-separated GIDLIST value.
Closed since 3.5.3, and that is the whole Jellyfin story
Emby relicensed at 3.5.3 in 2018 and moved open components into plugins. Jellyfin is the fork of the last open version, 3.5.2. This matters operationally because community tooling, plugins and scripts written for one often do not work on the other despite the shared ancestry, and Emby releases cannot be built or patched by you if something breaks.
Specifications#
- Category
- Media servers and libraries
- Licence
- Proprietary (Proprietary)
- Written in
- C# / .NET
- First release
- 2015
- Maturity
- Mature
- Datastore
- SQLite
- Default ports
8096,8920- Ships as
- docker, deb/rpm package, NAS package, native binary
- arm64 builds
- Yes
- Identity
- LDAP only. An LDAP plugin exists and works; there is no first-party OIDC, so anything IdP-shaped means a forward-auth proxy in front of the web UI, which native clients then bypass.
- Replaces
- Plex, Netflix, Jellyfin
- Project site
- emby.media
- Source
- github.com/MediaBrowser/Emby.Releases
- Documentation
- support.emby.media/support/home
Alternatives to Emby#
Everything else in media servers and libraries, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Audiobookshelf | 2, Light | 200 MB | GPL-3.0 |
| Calibre-Web | 2, Light | 120 MB | GPL-3.0 |
| Jellyfin | 2, Light | 280 MB | GPL-2.0-only |
| Jellyseerr | 2, Light | 220 MB | MIT |
| Kavita | 2, Light | 250 MB | GPL-3.0 |
| Plex Media Server | 2, Light | 400 MB | Proprietary |
Where Emby comes up elsewhere#
Head to head
Migration guides
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.