Domain Locker

Last reviewed Sep 13, 2026 · 868 words

I have watched a registrar auto-renewal fail on an expired card and take a company's email offline for 2 days. Domain Locker exists for that failure. It is a self-hosted dashboard, MIT-licensed and from the author of Dashy, that lists every domain you own with its expiry date, registrar, nameservers, DNS records, SSL certificate expiry and WHOIS details, then alerts you well before any of them lapse. It is young, launched in 2024, and it is the first tool I have seen that treats domains as an asset inventory rather than a line item in a monitoring tool.

What gets watched, and how often

Add a domain and Domain Locker fetches its WHOIS or RDAP record, resolves its DNS, and checks the TLS certificate on the apex and common subdomains. From then on it re-checks on a schedule and diffs the results, so you see when a nameserver changed, when a record was added, when a certificate was renewed, and when the registrar record shows a new expiry after a renewal. Each domain carries the fields a spreadsheet would have: registrar, cost, renewal date, tags, notes, linked hosts and subdomains. The dashboard rolls that up into "expiring soon", "certificate issues" and "recently changed" panels, which is the daily-glance view.

The value scales with the number of domains. With 1 domain, a calendar reminder does the job. With 10 or more across 3 registrars, some bought years ago for projects you have forgotten, this is the tool that finds the one whose renewal card expired. That is the buyer: freelancers, small agencies, and homelabbers who have accumulated domains the way other people accumulate Raspberry Pis.

It needs Postgres, so it is not a single container

The catalogue says Docker-only, and in practice that means the app container plus a PostgreSQL container. The upstream compose file wires both, and the only values you must set are the database password and the public URL for links in notifications. The app itself is light; the 256 MB minimum covers it with headroom, and Postgres adds its usual baseline. The project began as a hosted service with a Supabase backend, and the self-hosted build replaced that with plain Postgres, which is why some older documentation and screenshots mention Supabase. You do not need it.

Two operational notes. WHOIS lookups are rate-limited by registries and by some registrars, so a check interval measured in hours is correct and a check every 5 minutes will get you blocked. And because the data comes from public lookups, a registrar that masks WHOIS entirely gives you less; the expiry date still generally comes through via RDAP.

Alerts are the point, so wire them first

Notifications go out over webhooks, email and the common push channels, which means a self-hosted ntfy or a Slack or Discord webhook is a 2-minute setup. Set thresholds at 30, 14 and 7 days for domain expiry and at 14 and 3 days for certificates. Test the channel on day one by adding a domain with a known near expiry, because the whole failure mode this tool prevents is a silent one and an alert channel nobody verified is as good as none. Also send the weekly digest, which is the reminder that the tool itself is still alive.

Where it overlaps with tools you already run

Uptime Kuma can check a certificate's expiry on any HTTPS monitor and will alert on it, and if certificates are your only concern you already have the tool. It does not know about registrars, renewal dates, DNS drift or WHOIS. Wallos tracks renewals and costs as subscriptions, including domains, but knows nothing about the DNS or certificate side. Domain Locker sits between the two and does the full domain-shaped job; the honest reading is that it replaces a spreadsheet more than it replaces either of those. The broader field is on the monitoring category page, and the DNS for self-hosters piece covers the records you will be staring at.

New project, so plan for change

1,500 stars and 2 years of age means the schema, the compose file and the UI have all changed in ways that required reading release notes. Pin the image tag, take a pg_dump before upgrading, and expect the odd breaking change until it settles. The maintainer's track record with Dashy suggests it will be maintained, but a monitoring tool for slow-moving risks is one you will forget about, so make it low-maintenance from the start: pinned tag, automated database dump, and an alert that fires if the container itself stops.

What I'd do

Deploy it with the upstream compose file and Postgres, add every domain I own including the embarrassing ones, set 30/14/7-day expiry alerts to ntfy, and let Uptime Kuma keep handling certificate checks on the services it already watches. For anyone with fewer than 5 domains at one registrar with a working auto-renew, skip it and put the renewal dates in a calendar; for anyone with more, this is the cheapest insurance in the homelab.