Movary: a self hosted movie tracker you can run with Docker

What Movary tracks and who it is for

Movary records what you watched and what you thought of it, then turns that list into statistics: most watched actors, directors, genres, languages and years. It is built for people who already run a media server and want the viewing history to live on their own hardware rather than inside a commercial service. The README describes it as "the central hub to track, rate and explore your movie watch history" and lists user management, so a household can share one instance with separate accounts.

The project also treats data ownership as a feature rather than a side effect. Users decide who can see their data, and the README states they can export, import or delete their data and their accounts at any time. Metadata from sources such as themoviedb.org and imdb can be stored locally, which matters if you do not want every page load to reach out to a third party.

The README carries its own warning: the project is "still in an experimental (but usable) state", with more work planned before a 1.0 release. That sentence should shape how you deploy it.

How the pieces fit: PHP app, SQLite or MySQL, TMDB as the metadata source

Movary is a PHP application. The repository root holds composer.json, a src/ directory, templates/, public/ and a bin/ directory with a console entry point, which is the layout of a conventional PHP web app rather than a single static binary. The Docker build is defined in build/Dockerfile with a production target, and docker-compose.yml exposes the app on port 8080 inside the container, mapped to ${HTTP_PORT:-80} on the host.

Storage is a choice you make at configuration time. The .env.example file documents DATABASE_MODE with sqlite or mysql as the values, DATABASE_SQLITE pointing at storage/movary.sqlite by default, and a separate block of MySQL settings including host, port, name, user, password and charset. There is also DATABASE_DISABLE_AUTO_MIGRATION, which the example file describes as disabling automatic database migrations on container startup. That single flag is the difference between a container that upgrades its own schema when it starts and one that does not.

The metadata layer depends on The Movie Database. TMDB_API_KEY is described in .env.example as the only functional mandatory value, and TMDB_ENABLE_IMAGE_CACHING controls whether poster and backdrop images are cached locally. Without that key the application has no source for movie metadata, so this is not an optional integration you can defer.

Installing Movary with Docker and adding your first movie

The repository ships docker-compose.yml, so the shortest path is to clone the repository, create your environment file from the example, and fill in the TMDB key. The .env.example header states the key is the only mandatory value and points to https://www.themoviedb.org/settings/api for obtaining it.

git clone https://github.com/leepeuker/movary.git
cd movary
cp .env.example .env

Open .env and set TMDB_API_KEY. Leave DATABASE_MODE unset to stay on SQLite, or uncomment the MySQL block if you already run a database server. The Makefile includes .env, so the values are read from that file when you use the make targets.

make up

That target runs docker compose up -d. With the default HTTP_PORT the interface answers on port 80 of the host; set HTTP_PORT in .env if something else already owns that port. The MySQL variant of the same step is make up_mysql, which layers docker-compose.mysql.yml on top of the base file.

Once the container is running, open the site, create the first account, and add a movie by searching for its title. Because TMDB supplies the metadata, the search results come from that catalogue rather than from anything you typed into a local file. If you want your existing history in place before you start rating, the README lists import support for Trakt, Letterboxd and Netflix, and export back to those platforms, so the migration path does not require re-entering years of viewing by hand.

Automatic play tracking from Plex, Jellyfin, Emby and Kodi

The feature that separates Movary from a spreadsheet is the scrobbler. The README states it automatically adds new plays and ratings from Plex, Jellyfin, Emby or Kodi. In practice this means your media server reports a play and Movary writes a history entry, so the list stays current without you opening the web interface.

Plex needs extra configuration. The .env.example file lists PLEX_IDENTIFIER, described as required for Plex authentication and generated with a command such as openssl rand -base64 32, plus PLEX_APP_NAME. It also exposes PLEX_VALIDATE_URL_SAFE, which the file describes as SSRF protection that blocks localhost, private IPs and internal DNS. That default is worth reading carefully before you change it: a Plex server on your own LAN is exactly the kind of address the protection is designed to refuse, so anyone pointing Movary at a private address will have to think about that flag rather than assume the integration is broken.

The scrobbler also only knows what the server tells it. If you watch on a device that never reports to Plex, Jellyfin, Emby or Kodi, nothing appears in Movary and you are back to entering the play yourself.

The pre-1.0 problem and the upgrade cost it creates

The README is unusually direct about this: the project is experimental but usable, features will be added and improved before 1.0, and that "can lead to sudden breaking changes from time to time", with the advice to keep release notes in mind when updating. The release history supports the idea of steady movement: 0.71.0, 0.71.1 and 0.72.0 shipped between late March and late May 2026, and the last push to the repository was on 2026-09-08.

For a self hosted tool that stores years of viewing history, the practical consequence is that you should not treat an upgrade as a background operation. The automatic migration flag means a container restart can alter your schema. Take a copy of the SQLite file, or a database dump if you use MySQL, before you pull a new image. The Makefile even includes a db_mysql_import target that copies a dump into the container, which suggests the maintainers expect that workflow.

A second limitation is scope. Movary is a movie tracker. The README talks about films, actors, directors and genres; it does not present itself as a general media library manager for series, books or games. If your watch history is mostly episodic television, the statistics you get will reflect that only insofar as the metadata source models it.

The third constraint is the TMDB dependency. Every metadata lookup, and every image unless caching is enabled, depends on an external service and a personal API key. If that key is revoked, rate limited or the service changes its terms, the catalogue side of Movary degrades even though your own history stays in your database.

Movary against Trakt and hosted trackers

The obvious alternative is Trakt, which Movary itself treats as an import and export source. The difference is where the record lives. Trakt is a hosted service: you get an account, an API and a social layer, and your history sits on their infrastructure under their terms. Movary is the inverse. You run the container, you hold the SQLite file or the MySQL database, and the README's emphasis on exporting, importing and deleting your own data is the point of the project rather than a feature bolted on.

That trade is real in both directions. Trakt works from any device with a browser and needs no server, no API key of your own and no upgrade planning. Movary needs a host, a TMDB key and attention at every version bump, and in exchange it gives you a private instance that can serve several accounts, cross-post to Mastodon, and keep metadata on your own disk.

Letterboxd and Netflix appear in Movary as import and export sources rather than as competitors, which is the sensible framing: they are where your history currently lives, and Movary is where you move it. If you want a hosted social product with no maintenance, Movary is the wrong tool. If you want the file, it is the right one.

Licence, maintenance and what to check before you deploy

Movary is released under the MIT licence, which is permissive: it allows use, modification and redistribution provided the copyright notice and licence text are preserved. That is a low-friction choice for a self hosted application, and it means you can fork or patch the code without a copyleft obligation on your changes. It says nothing about the terms attached to the TMDB API key or to the metadata and images you pull through it, which are governed by that service's own terms, not by the MIT grant. If you plan to run a public instance, that distinction is the one to check with someone qualified, because the repository licence does not cover third party data.

On maintenance, the last push was on 2026-09-08 and the most recent release in the repository listing is 0.72.0 from 2026-05-22. The project is not archived. There is a documented release cadence of roughly one minor version per month or two across the versions listed, and the README points to GitHub issues, GitHub discussions and a Discord server for bugs and questions. The upgrade cost is therefore not abandonment risk but change risk: pre-1.0 breaking changes, an automatic migration step you can disable, and release notes you are expected to read.

Before you deploy, confirm three things. That you can create a TMDB API key. That you have decided between the default SQLite file at storage/movary.sqlite and the MySQL configuration, because moving later is a migration rather than a setting. And that you have a backup routine for whichever store you chose, since that file or database is the entire value of the instance.

Editorial conclusion

Adopt Movary if you want your watch history in a database you control and you already run Plex, Jellyfin, Emby or Kodi. Skip it if you need a stable API surface or a hosted service with no server to run. Before you commit, verify that you can obtain a TMDB API key, decide between the default SQLite file and MySQL, and read the release notes for the version you install, because the README states breaking changes can occur before 1.0.

Frequently asked questions

Official sources

1. Issues
2. leepeuker/movary on GitHub
3. License: MIT
4. README
5. Releases