Movary: a self-hosted watch history that survives the shutdown of the service you used to track it
Self hosted web app to track and rate your watched movies
At a glance
- What is it?
- Movary is a PHP web app that stores your movie watch history, ratings and statistics on your own server, with importers for Trakt, Letterboxd and Netflix and a scrobbler for Plex, Jellyfin, Emby and Kodi. It is explicitly pre-1.0, and the README warns that updates can break things.
- Who is it for?
- Adopt Movary if you already run Plex, Jellyfin, Emby or Kodi and want the watch history and ratings to live in a database you control, and if you accept a pre-1.0 project where the README tells you to read release notes before every update. Skip it if you need a stable API contract, a signed release cadence, or if nobody on your side is willing to run a PHP container with a database and keep it patched.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is ownership of a watch history, not the act of rating a film
Rating a film takes ten seconds. Keeping the record of that rating for a decade is the hard part. Trakt, Letterboxd and Netflix all hold that record for you, and each of them can change its terms, its API or its pricing, or simply stop. The Movary README frames the project around that: users can decide who can see their data and export, import or delete the data and their accounts at any time. The stated goal is a central hub to track, rate and explore your movie watch history, hosted by you for yourself and others. That places the target user somewhere specific. It is not someone who wants a social feed of film opinions. It is someone who already has a library on Plex, Jellyfin, Emby or Kodi, has years of plays scattered across services, and wants one place where the numbers add up. The README lists statistics such as most watched actors, directors, genres, languages and years, which only become meaningful when the history is complete and stays in one store. A user with forty plays in a spreadsheet is not the audience. A user who has migrated between three trackers is.
What the repository shows about how it is built
Movary is a PHP web application with a Docker image published as leepeuker/movary. The README points to docs.movary.org/install/docker for installation and to api.movary.org for the HTTP API, so the intended deployment is a container plus a database, reached through a browser. The feature list describes several distinct data paths rather than one. Third-party integrations import and export history and ratings from platforms like Trakt, Letterboxd and Netflix. A scrobbler adds new plays and ratings automatically from Plex, Jellyfin, Emby or Kodi, which means those servers push events into Movary rather than Movary polling them. Metadata, described as coming from sources such as themoviedb.org and imdb, can be stored locally, so the app can resolve titles without calling out on every page load. Cross-posting to Mastodon is a separate outbound path, and the PWA packaging means the same web front end can be installed on a phone. The README also mentions user management, so a single instance can serve more than one person. What the supplied material does not specify is the database engine, the queue or job mechanism behind the scrobbler, or the schema. Those details live in the documentation and the source, not in the README, so treat any assumption about them as unverified.
Running it: the Docker path and the settings that matter
The README does not inline a compose file. It links to docs.movary.org/install/docker, and the published image is leepeuker/movary on Docker Hub, so the concrete commands come from that page rather than from the repository front page. Two configuration areas are visible from the feature list. First, the metadata source: because themoviedb.org and imdb are named as sources, an API key for at least one of them is part of setup, and the option to store metadata locally is a deliberate choice you make rather than a default you can ignore. Second, the scrobbler: connecting Plex, Jellyfin, Emby or Kodi is what turns Movary from a manual log into an automatic one, and it is the step most likely to need attention, since the server has to be able to reach Movary and the credentials have to be entered on both sides. The demo at demo.movary.org, with the credentials testUser@movary.org and testUser, is the cheapest way to see the dashboard, the statistics views and the import screens before you commit a server to it. The API at api.movary.org is documented separately, which matters if you plan to script imports or read your own history out.
The pre-1.0 warning is the most important line in the README
The README states plainly that the project is in an experimental but usable state, that more features are planned before a 1.0 release, and that this can lead to sudden breaking changes from time to time, with the advice to keep the release notes in mind when updating. That is not boilerplate. It is a description of the upgrade contract you are accepting. The release history supports the reading: 0.72.0 in May 2026, 0.71.1 in April, 0.71.0 in March. A patch release between minor versions suggests fixes are shipped quickly, but the 0.x numbering means no compatibility promise exists yet. The practical consequence is that a Movary instance is not a set-and-forget service. You either pin the image tag and update on your own schedule after reading the notes, or you accept that a pull of latest can change behaviour under you. The second limitation is scope. Movary tracks films. The README talks about movies, actors, directors, genres and languages, and nothing in the supplied material describes television seasons or episodes, so anyone whose library is mostly series should check that against the docs before assuming it fits. The third is operational: a PHP app with a database, outbound calls to metadata providers, inbound webhooks from media servers and an optional Mastodon connection is a small service to run, and it needs backups like any other.
Where Movary sits next to a hosted tracker and next to a media-server dashboard
The obvious alternative is to keep using Trakt or Letterboxd and not run anything. The difference is not features, it is the failure mode. With a hosted tracker, the record lives on someone else's infrastructure and your access depends on their API and their continued operation. Movary inverts that: the database is yours, the importers exist to pull the history in, and the README's promise that users can export, import or delete their data and accounts is the exit door. The cost is that you now own uptime, upgrades and backups. A second alternative is the statistics view built into a media server or a tool that reads the server's own database, such as the dashboards people run alongside Jellyfin or Plex. Those are attractive because there is nothing extra to feed: the plays are already there. The trade-off is that they can only ever know what that one server saw. Ratings you gave on Letterboxd in 2019, plays from a Netflix account, a cinema trip, a DVD: none of that is in the server's database. Movary's importers are precisely the answer to that gap, and its scrobbler keeps the automatic path working afterwards. If your history is genuinely confined to one media server and always will be, the simpler tool wins. If it is not, the import layer is the reason to run Movary.
Licence, maintenance and what an upgrade actually costs you
Movary is MIT licensed, which is permissive: you can run it, modify it and redistribute it, subject to the terms of that licence, and the repository ships a LICENSE file the README links to. This is not legal advice, and if you plan to redistribute a modified version or bundle it into something commercial, read the licence text itself. Maintenance cost has two parts. The first is the application: with releases landing roughly monthly across the 0.71 and 0.72 line, staying current means reading release notes and testing an upgrade, and the README's own warning means you should not assume an upgrade is inert. The second is the surrounding stack: PHP runtime, database, image updates and the metadata API keys. Because metadata can be stored locally, there is a choice to make about how much the instance depends on external services, and that choice affects both resilience and how much storage the database consumes. None of this is unusual for self-hosted software, but it is real work, and the honest framing is that Movary trades a subscription or a hosted account for a small service you operate. The repository is not archived and the last push recorded is September 2026, so the project is active rather than abandoned.
Who should install it, and what to check before you do
Install Movary if you run Plex, Jellyfin, Emby or Kodi, you have history on Trakt, Letterboxd or Netflix that you would rather not lose, and you are comfortable running a PHP container with a database and keeping it updated. The scrobbler plus the importers is the combination that makes the effort pay off, and the statistics views are the payoff once the history is consolidated. Do not install it if you need a frozen API, a 1.0 stability promise, or if the media you track is mostly television rather than film. Before you commit, do three things. Open the demo with the credentials in the README and check that the dashboard and statistics show what you expect. Read the docs.movary.org/install/docker page and confirm the database and metadata requirements fit your host. Then check the release notes for 0.72.0 against whatever version you plan to run, because in a project that tells you breaking changes happen, the notes are the specification.
Editorial conclusion
Adopt Movary if you already run Plex, Jellyfin, Emby or Kodi and want the watch history and ratings to live in a database you control, and if you accept a pre-1.0 project where the README tells you to read release notes before every update. Skip it if you need a stable API contract, a signed release cadence, or if nobody on your side is willing to run a PHP container with a database and keep it patched. Before you commit, install the demo instance or your own copy, run one Trakt or Letterboxd import against a throwaway account, and confirm on the 0.72.0 release notes whether the import mapping and the database schema changed since the version you are reading about.
Community notes