Domain Locker: Centralized Tracking and Monitoring for Your Domain Portfolio

The Problem: Losing Track of Domains Across Registrars

Domain portfolios tend to accumulate across multiple registrars, often with inconsistent renewal dates and varying DNS and SSL providers. The result is a situation where the owner misses a renewal because it was at a registrar they check infrequently, discovers an expired SSL certificate after users report browser warnings, or cannot remember which hosting provider backs a given domain.

Domain Locker solves this with a central dashboard that adds any domain name and automatically fetches all associated data: SSL certificates, hosting providers, registrar details, IP addresses, subdomains, and DNS records. It then monitors those values continuously and sends configurable alerts when something important changes or an expiration date approaches.

The README states the goal directly: the aim is to give complete visibility of your domain name portfolio in one central place, so you will never lose track of a domain, miss an expiration, or forget which registrar and providers each domain uses.

What Domain Locker Tracks Per Domain

For each domain added to Domain Locker, the application automatically fetches and stores a comprehensive set of data. The README lists: SSL certificates, hosting providers, registrar details, IP addresses, subdomains, and DNS records. Beyond the static data snapshot, it provides detailed metrics and analysis for each domain.

The monitoring layer tracks website health, security, and performance on an ongoing basis. Uptime monitoring runs every 15 minutes via an internal scheduled job at `/api/domain-monitor`. This is not a ping check; the README describes it as monitoring website uptime, performance, and health.

Change tracking records the history of domain configuration. If a domain's nameservers change, or if the registrar is transferred, that change appears in the history view.

Valuation data is also tracked: the README lists purchase prices, renewal costs, and domain valuation as features. This is specifically useful for domain investors who want to track cost basis and estimated value across a portfolio.

Configurable alerts and webhook notifications mean the monitoring data can push to external systems. Import and export functionality, along with API data access, round out the data portability story.

Running Domain Locker: Managed Service or Docker

The README offers two paths. The first is the managed instance at domain-locker.com, where the starter plan is free, requires no setup, and needs only a Google, GitHub, or email login. This is the simplest option.

The second path is self-hosting via Docker. The one-line command:

docker run -p 3000:3000 -v domain-locker-data:/data lissy93/domain-locker

This starts the application on port 3000 with data stored in a named Docker volume. The README notes that all you need is Docker; the app handles its own scheduled jobs internally.

The Docker Compose file at the repository root provides a declarative version:

  app:
    image: lissy93/domain-locker:latest
    environment:
      DL_ENV_TYPE: selfHosted
    ports:
      - "${DL_APP_PORT:-3000}:3000"
    volumes:
      - domain_locker_data:/data

Setting `DL_ENV_TYPE` to `selfHosted` activates the self-hosting configuration. The port defaults to 3000 but can be overridden with the `DL_APP_PORT` environment variable.

Unofficial deployment packages are also available: a Helm chart on Artifact Hub, an Umbrel app, a Proxmox VE community script, and a TrueNAS app. These are community-maintained and not directly supported by the project author.

Database Configuration: SQLite by Default, Postgres Optional

The default database is SQLite, stored at `/data` in the container (mounted as a volume). No additional database service is required for a single-user self-hosted deployment.

For users who prefer Postgres, setting all five Postgres environment variables switches the storage backend:

DL_PG_HOST='localhost'
DL_PG_PORT='5432'
DL_PG_USER='postgres'
DL_PG_PASSWORD='changeme2420'
DL_PG_NAME='domain_locker'

The `.env.sample` file documents these variables. The README notes that all five must be set together; if any are missing, the app falls back to SQLite. A separate `docker-compose.postgres.yml` file in the repository provides a compose configuration that includes a Postgres service alongside the Domain Locker container.

The app uses AnalogJS, a meta-framework built on top of Angular, for server-side rendering. The tech stack is Node.js 22 with Angular 19. Developers who want to run from source follow four steps documented in the README: clone the repository, install dependencies with `npm install --legacy-peer-deps`, copy `.env.example` to `.env`, and start the dev server with `npm run dev`.

The Three Built-In Scheduled Jobs

Domain Locker handles its own scheduling: there is no external cron daemon required. Three jobs run at fixed intervals.

The domain updater at `/api/domain-updater` runs daily to keep domain data up to date and trigger notifications. This is the job that detects expiration dates approaching and sends configured alerts.

The domain monitor at `/api/domain-monitor` runs every 15 minutes to check website uptime and performance. This is the uptime monitoring layer.

The cleanup job at `/api/cleanup-monitor-data` runs weekly to aggregate old monitoring data. This prevents the uptime history from growing unbounded.

All three jobs are started automatically when the container starts. The README does not document how to adjust their intervals. For users who need a different monitoring frequency, the app does not expose interval configuration through environment variables in the documented portion of the README.

Comparison with DomainMod

DomainMod is the most commonly cited self-hosted alternative for domain portfolio management. It is a PHP and MySQL web application that tracks domains, registrars, SSL certificates, and renewal dates.

The practical differences between the two are in architecture and scope. DomainMod is PHP-based and requires a LAMP or LEMP stack to self-host. Domain Locker is a Node.js Docker image that ships with all dependencies and requires no separate stack setup beyond Docker.

Domain Locker goes beyond static portfolio tracking by adding continuous monitoring: uptime checks every 15 minutes, performance data, and change history. DomainMod is primarily a record-keeping database without a built-in monitoring loop.

Domain Locker also provides a free managed cloud instance at domain-locker.com, which DomainMod does not offer. For users who want zero self-hosting overhead, that is a significant difference.

The trade-off is that Domain Locker is newer software: the first stable release (v0.1.4) was in February 2026. DomainMod has a longer track record.

Release Cadence and Licensing

Domain Locker v0.3.0 was released on 2026-09-23, five days before this article was written. The release history shows active development: v0.1.4 in February 2026, v0.2.0 in June 2026, and v0.3.0 in September 2026. The last push to the repository matches the v0.3.0 release date.

The project uses Angular 19 with AnalogJS, pnpm for package management, and builds with Vite. The Dockerfile stages the build on Node 22 Alpine and strips esbuild from the final image (noting a CVE as the reason).

The license is MIT. The author, Alicia Sykes, has published the code under MIT licensing. The software can be used, modified, and redistributed freely for personal or commercial use. The free managed instance at domain-locker.com is a separate hosted service; its terms are not MIT-licensed, but using the self-hosted Docker image imposes no licensing cost.

Editorial conclusion

Domain Locker is the right tool for a developer or domain investor who owns more than a handful of domains across multiple registrars and wants a single place to catch expiration dates, SSL lapses, and unexpected DNS changes. The free managed instance at domain-locker.com is the lowest-friction starting point; the self-hosted Docker image makes sense for users who prefer not to share their domain inventory with a third-party service. Teams evaluating self-hosting should run `docker run -p 3000:3000 -v domain-locker-data:/data lissy93/domain-locker` and confirm the scheduled monitoring jobs start correctly before committing to a production setup.

Frequently asked questions

Official sources

1. License: MIT
2. lissy93/domain-locker on GitHub
3. Project website
4. README
5. Releases