A freshly installed DirectAdmin server works, but it is not ready for customers. The panel still runs on a self-signed certificate, there is no firewall, updates are on whichever channel the installer picked, and backups go nowhere. This is the half hour we spend on every new server after the install on AlmaLinux 9, in the order that avoids doing anything twice.
Secure the panel itself
1. A real certificate for the hostname. DirectAdmin can issue a Let's Encrypt certificate for its own hostname, as long as the A record for server1.example.com already points at the server. Make sure the Let's Encrypt client is built, request the certificate, and turn SSL on for the panel:
cd /usr/local/directadmin/custombuild && ./build letsencrypt
/usr/local/directadmin/scripts/letsencrypt.sh request_single server1.example.com 4096
da config-set ssl 1
systemctl restart directadminThe same certificate is used for webmail and phpMyAdmin on the hostname, so this removes the browser warning everywhere at once.
2. Force the hostname. People will still reach the panel by IP, and a certificate for server1.example.com is not valid for an IP address. da config-set force_hostname server1.example.com tells DirectAdmin to use that name in its own links and redirects, so the address in the browser always matches the certificate. Restart the service afterwards.
3. Two-step authentication for admin. The admin login controls every account on the server. Open the User Level of the admin account, then Account Manager → Two-Step Authentication, scan the code with an authenticator app and save the backup codes. We do this before the first customer exists so it is never forgotten.
Give the server its identity
4. Nameservers. Under Admin Level → Server Manager → Administrator Settings, set the two nameservers that every new domain's zone will use, typically ns1.example.com and ns2.example.com. If those names resolve to this server, add the A records for them at your registrar as well. Until this is set, each new domain gets a zone with the wrong NS records and you correct them one by one later.
5. The admin email address. DirectAdmin's message system sends update notices, brute force reports and failed backup warnings to the admin account's address. Check it in the account menu at the top right and change it to a mailbox someone actually reads.
6. Timezone. Cron jobs, log timestamps and PHP's date() all follow the system timezone, so set it before there are logs worth reading:
timedatectl set-timezone Europe/LondonPHP has its own date.timezone setting in each version's php.ini under /usr/local/php8X/lib/; set it there too and restart that version's PHP-FPM service.
Choose how updates arrive
7. Update channel and auto-updates. DirectAdmin has three release channels: current, stable and alpha. Check which one the installer chose and pick deliberately:
da config-get update_channel
da config-set update_channel stable
da config-set autoupdate 1
da updatestable is the right choice for a production server with customers; current gets features such as the 1.709 backup changes sooner. With autoupdate on, the panel updates itself on that channel. CustomBuild is separate: ./build update && ./build versions shows what is behind, and the update guide covers doing it safely.
Firewall and brute force protection
8. Install CSF. ConfigServer Security & Firewall is the standard firewall for DirectAdmin and CustomBuild installs it with one command:
cd /usr/local/directadmin/custombuild && ./build csfIt appears under Admin Level → Extra Features as its own page. Two things to do straight away: add your own office or home IP to the allow list so you cannot lock yourself out, and set TESTING = "0" in the firewall configuration, otherwise CSF flushes its rules every five minutes and protects nothing.
9. Brute Force Monitor. Admin Level → Server Manager → Brute Force Monitor collects failed logins to the panel, mail, FTP and SSH. In Administrator Settings, enable blacklisting of IPs after repeated failed attempts; with CSF installed, the blocked IP is passed to the firewall rather than only to DirectAdmin's own list. The default thresholds are reasonable, and the monitor page shows who is being blocked so you can see it working within a day.
Backups and a test account
10. Backups and a test. Open Admin Level → Server Manager → Admin Backup/Transfer. The default path is /home/admin/admin_backups, which is on the same disk as the data it protects. Point it at a second disk or a remote SFTP destination, schedule it nightly, and remember that since 1.709 the system backup script covers only global configuration files; user homes and databases are the Admin Backup's job. The full picture is in DirectAdmin backups and restore.
Then create one package and one user with a real domain, upload a page, send an email out and back in, request a certificate and restore that user from the first backup. Twenty minutes of testing now finds a broken mail or DNS setting before a customer does. Creating packages and users walks through the account side.
The two things outside the panel
SSH is not DirectAdmin's business, but it is the other way into the server. Create a sudo user, disable root SSH login and move to key-only authentication before the IP is known to anyone. CSF will block the scanners, but a locked door is better than a blocked one.
That is the whole list. On a VPSPioneer managed VPS these ten steps are done before we hand the server over, so the first thing you see is a panel with a valid certificate, a firewall and a working backup.