Warracker: a self-hosted warranty register built on Flask and Postgres
🛡️ Warracker is an open source, self-hostable warranty tracker to monitor expirations, store receipts, files. You own the data, your rules!
At a glance
- What is it?
- Warracker stores product warranties, receipts and claim histories in a Postgres database you run yourself, with reminders pushed through Apprise. It is a small, opinionated app that trades polish for data ownership.
- Who is it for?
- Adopt Warracker if you already run Docker Compose and a Postgres instance and you want warranty records, receipts and claim statuses in a database you control. Skip it if you want a hosted service with no server to maintain, or if you need a calendar feed, which the roadmap still lists as unchecked.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly JavaScript, 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 paperwork problem Warracker is aimed at
Warranty coverage is a records problem disguised as a shopping problem. A receipt lives in an email inbox, the serial number is on a sticker on the underside of a device, the coverage window is a line in a PDF, and the claim process starts with a phone call months later. Nothing about that is hard, but it is spread across four places that do not talk to each other.
Warracker's answer is a single Postgres-backed register. Each record holds a purchase date, a duration, notes, product photos with thumbnail previews, and one or more serial numbers. Receipts, invoices and manuals are uploaded as files rather than linked. The README describes the target user as individuals and teams, and the feature list backs that up: multi-user accounts, admin controls, and a global warranty view gated by role-based permissions. The claim tracking feature extends the record past expiry into statuses, dates and resolutions, which is the part most spreadsheet setups never bother with.
If you have ever stood in a store with a dead kettle and no idea whether the coverage ended three weeks ago, that is the scenario this project is built around.
Postgres, Flask and a volume for uploads
The stack is deliberately unglamorous. The README lists HTML, CSS and JavaScript on the front end, Python with Flask on the back end, PostgreSQL for storage, Nginx as the web server, and Docker Compose for containerization. There is no separate API layer described, no message queue, and no object storage service. Uploaded documents land in a Docker volume.
That shape matters for how you operate it. Because Postgres is a first-class dependency rather than an embedded database, backup is two separate jobs: dump the database, and copy the uploads volume. The Compose example in the README makes this explicit by declaring two volumes, one named for the uploads path and one for the Postgres data directory. Restoring only the database gets you records pointing at files that no longer exist.
Notifications run through Apprise. The README claims alerts for upcoming expirations via email or 100+ push services including Discord and Slack, and the Apprise project is what provides that breadth. The trade-off is that Apprise is a separate moving part: if your notification URL is malformed or the target service rejects the payload, the failure surfaces in Apprise rather than in Warracker's own interface. The README does not describe a retry or delivery log, so treat notification delivery as something to verify rather than assume.
Bringing it up with Docker Compose
The README's setup section assumes Docker and Docker Compose are already installed. The Compose file it gives defines two services. The application service uses the image ghcr.io/sassanix/warracker/main:latest, publishes port 8005 on the host mapped to port 80 in the container, mounts the named volume warracker_uploads at /data/uploads, and loads environment variables from a .env file. It depends on the database service with the condition service_healthy, and restarts unless stopped.
The database service uses postgres:15-alpine, mounts postgres_data at /var/lib/postgresql/data, and defines a healthcheck running pg_isready with the POSTGRES_USER and POSTGRES_DB variables interpolated from the environment. The healthcheck interval is 5s with a 5s timeout and 5 retries. That is what makes the depends_on condition meaningful: the app container waits until Postgres answers.
Both services read from the same .env file, which is where you set the Postgres credentials and whatever the application needs. The README does not enumerate the application's environment variables, and the Compose snippet is truncated at the volumes block, so the exact key names for OIDC, SMTP or currency settings are not visible in the material supplied. You will need to read the .env example in the repository before your first start. Port 8005 is a host-side choice, not a fixed requirement; change the left side of the mapping if it collides.
Paperless-ngx integration and what it changes
The feature table lists a Paperless-ngx integration that stores and manages documents directly in Paperless-ngx with file-level control. This is the most interesting design decision in the project, because it splits the document store from the warranty register.
In the default configuration, uploads live in the warracker_uploads volume and the database holds the metadata. With Paperless-ngx in the picture, the documents live in a system that already does OCR, tagging and full-text search, and Warracker keeps the warranty-specific fields. For anyone already running Paperless-ngx, that avoids a second pile of scanned PDFs. For anyone who is not, it adds a dependency and a second service to keep alive. The README does not explain how to configure the connection, whether it uses an API token, or what happens to existing volume-stored files when you switch. That is a gap worth checking in the repository before you plan a migration.
The integration is also the clearest sign of who the project is for. It assumes a self-hosting habit already exists, rather than trying to create one.
Where Warracker is the wrong tool
The project describes itself as in active development, with the core described as stable and advanced enhancements still being worked on. That phrasing is honest, and it should shape your expectations. This is not a system with a long support tail.
The release history is short. Versions 1.0.0, 1.0.1 and 1.0.2 all landed within about a week of each other in late October 2025, which is the shape of a project that has just crossed into a 1.x line rather than one that has been stable for years. The roadmap confirms the direction: calendar integration is the one item still unchecked, while authentication, settings, status page, reminders, email notifications, tags, CSV import and export, OIDC SSO, admin controls, Paperless-ngx integration, localization, claim tracking and audit trail are all marked done.
Two concrete limits follow. First, there is no calendar feed, so if your workflow depends on warranty expirations appearing in an existing calendar client, Warracker will not do it yet. Second, the notification path is one-directional: the README does not describe a way to acknowledge or snooze an alert from the receiving end, so reminder fatigue is managed by whatever timing settings the app exposes, not by per-item control.
There is also a scale question the README does not answer. A household or a small team tracking a few hundred items is well within the described feature set. Nothing in the material suggests the project was designed for asset inventories in the thousands, and no performance characteristics are given.
How it compares with a spreadsheet and with hosted trackers
The honest alternative for most people is a spreadsheet. A Google Sheet with columns for product, purchase date, duration and receipt link costs nothing, needs no server, and is instantly shareable. What it does not do is send itself a reminder, hold the receipt file alongside the row, or track a claim through resolution. Warracker's value is exactly those three things, and it is worth being clear that you are paying for them with a Postgres instance and a Docker host.
The other alternative is a hosted warranty or home-inventory service, where someone else runs the database and you get an app. The difference in approach is not features, it is custody. Warracker's pitch is that you own the data and your rules apply, which means the uptime, the backups and the upgrade timing are yours too. A hosted service moves that work to a vendor and takes the data with it.
Within the self-hosted category, the thing that distinguishes Warracker from a generic asset tracker is the claim lifecycle. Tags and categories exist in plenty of tools; statuses, dates and resolutions for an in-progress warranty claim are more specific to this problem. If you never file claims, you are using a subset of the app.
Licence, upgrade path and the cost you actually pay
Warracker is licensed under AGPL-3.0. The practical consequence for most self-hosters is nil: run it for your household or your internal team and the copyleft obligations do not reach you. The obligations attach when you distribute a modified version or expose one as a network service to other users, at which point the source of your modifications has to be available under the same terms. If you plan to fork Warracker into something you offer to customers, read the licence text yourself rather than relying on a summary. Nothing here is legal advice.
The upgrade path is a container pull. The Compose file pins the image tag to main:latest, which means a restart can move you to a new build without a deliberate decision. If you want reproducible upgrades, pin a version tag instead and change it when you choose. The database is postgres:15-alpine, also a moving tag within the 15 line, so major-version Postgres upgrades are not automatic and will need a dump and restore rather than a tag change.
Maintenance cost is the part people underestimate. You are responsible for Postgres backups, for the uploads volume, for the Apprise endpoint, and for the reverse proxy in front of port 8005 if you expose it beyond your LAN. The README does not describe a migration tool or a schema version command, so before upgrading across a release boundary, take a database dump. That is a one-line habit that turns a bad upgrade into an inconvenience.
Editorial conclusion
Adopt Warracker if you already run Docker Compose and a Postgres instance and you want warranty records, receipts and claim statuses in a database you control. Skip it if you want a hosted service with no server to maintain, or if you need a calendar feed, which the roadmap still lists as unchecked. Before committing, verify that the Apprise notification path reaches your chosen endpoint, confirm the CSV export round-trips your existing spreadsheet columns, and read the AGPL-3.0 terms if you intend to expose a modified build to other users.
Community notes