Why I built domain-manager
I built domain-manager because I was tired of provisioning the same PHP hosting stack by hand for every new site. Create the Unix user, make the web root, wire up nginx, create the MySQL database, sort out PHP-FPM, fix permissions, enable TLS, repeat.
I didn’t need a full hosting panel with mail, DNS, dashboards, reseller features, and a pile of opinionated abstractions sitting between me and the machine. I wanted a very specific thing: a repeatable way to host multiple PHP sites on one Linux server, keep each site isolated enough to be sane, and still have the entire setup remain transparent and editable.
What I actually wanted
I wanted something closer to this:
# Create a new domain, with everything ready to go
./domain-manager add example.com
# List all of the domains
./domain-manager list
# find info and delete domains
./domain-manager info example.com
./domain-manager delete example.com
# Manage MySQL databases
./domain-manager mysql create example.com example_db_name
./domain-manager mysql list example.com --stats
# SSL
./domain-manager enable-ssl example.com --cloudflare
Under the hood, the basic idea of what I wanted was:
- nginx runs on the host
- MySQL runs on the host
- each site gets its own PHP-FPM container through Docker or Podman
- each domain gets its own Unix user
- metadata about domains and databases is stored locally in a file
There’s no need to fully containerise the whole server. nginx on the host is easy to debug. MySQL on the host is easy to manage. System backups stay straightforward.
PHP is where isolation matters most for this kind of setup. Have a website that you want to limit uploads? Simple, just apply SELinux rules to the cgroup that php runs in. Or run php in a container that has only read-only access to the application.
Each domain can run its own PHP-FPM container, so different sites can use different PHP versions without turning the host into a museum of conflicting packages. That’s no need to run a tool like EasyApache to build every version of PHP that you might possibly want to support in the future.
The database workflow had to be part of it
Under the hood, this tool simply creates the database, creates a user with a generated password and grants the right permissions. Listing databases and cleaning things up later should not involve digging through MySQL by hand unless I actually want to.
[root@server ~]# domain-manager mysql list my-website.com --stats
MySQL Databases:
- mywebsite-db (domain: my-website.com) 174.12 MB… with backups that “just work”™
Backups had to be part of the story as well. There’s a simple backup command that packages the site’s files together with its SQL dumps into a compressed archive:
./domain-manager backup example.com
That gives something portable and obvious. A backup is just a backup. It can be inspected, moved, copied, or restored from without needing any elaborate rituals. Yes, cPanel has pkgacct and restorepkg, but this is just easier.
Why transparent infrastructure matters
What I wanted was automation without surrendering the underlying system. domain-manager generates real files on disk and uses the host’s normal primitives: nginx config, Unix users, containers, MySQL and filesystem permissions. If I stop using the tool tomorrow, the server still looks like a normal server.
A lot of hosting tools optimise for hiding the system. I wanted the opposite.
domain-manager generates real nginx configs from templates. The tool writes container definitions from templates and uses just one YAML config file for paths, versions, credentials, and runtime choices. It creates standard (at least to this tool) filesystem layouts. It assumes SSH and SFTP are how users will login and upload files.
Debugging is easier. When something breaks, you’re looking at nginx config, container logs, PHP-FPM config, filesystem permissions, and MySQL state directly.
Version control is realistic. Templates and config can live like ordinary infrastructure code. The generated output is predictable. The system is understandable by anyone who knows Linux, nginx, and PHP.
domain-manager is dumb
There are plenty of things domain-manager does not try to do.
- not a general-purpose hosting business platform
- doesn’t do any kind of mail hosting
- no DNS management for your domains.
Would I recommend this over cPanel for everyone? Absolutely not.
Would I recommend it for developers and sysadmins who already manage Linux servers and want just a tiny bit of convenience? Maybe. Especially because that’s why I built this tool in the first place. It’s just a small orchestration layer for the boring parts of self-hosting PHP sites.
And honestly, that’s enough.
Download the code here: https://github.com/timgws/domain-manager.
