{"id":212,"date":"2026-06-05T19:54:06","date_gmt":"2026-06-05T19:54:06","guid":{"rendered":"https:\/\/blog.offshorekaka.in\/?p=212"},"modified":"2026-08-27T05:43:34","modified_gmt":"2026-08-27T05:43:34","slug":"offshore-dedicated-server-setup-checklist","status":"publish","type":"post","link":"https:\/\/offshorekaka.in\/blog\/offshore-dedicated-server-setup-checklist\/","title":{"rendered":"Offshore Dedicated Server Setup Checklist"},"content":{"rendered":"
\n

Server Guides<\/span><\/p>\n

The day your dedicated server arrives<\/h2>\n

A dedicated server hands you the whole machine and nothing else. No panel, no stack, no firewall, no backups. Everything a shared host used to do quietly in the background is now yours to set up, and the order you do it in matters.<\/p>\n

This is the sequence we use on a new offshore dedicated server<\/a>, from first login to a site serving traffic with monitoring and backups behind it.<\/p>\n

\n
Time<\/strong>Two to three hours end to end.<\/span><\/div>\n
Do first<\/strong>Check you got the hardware you paid for.<\/span><\/div>\n
Do last<\/strong>Point DNS at it.<\/span><\/div>\n<\/div>\n<\/div>\n
On this page<\/strong>Check the hardware<\/a>Base system<\/a>Lock it down<\/a>Stack or panel<\/a>Deploy and go live<\/a>Before you call it done<\/a>FAQ<\/a><\/div>\n

Check the hardware first<\/h2>\n

Do this before you build anything on top. Providers make mistakes, and finding out three weeks later that you are on a spinning disk instead of NVMe is an annoying conversation to have.<\/p>\n

lscpu | grep -Ei 'model name|^cpu(s)|thread|core'\nfree -h\nlsblk -d -o NAME,SIZE,ROTA,MODEL\ncat \/proc\/mdstat<\/code><\/pre>\n
\"lsblk
ROTA 0 is solid state. If you paid for NVMe and see ROTA 1, raise it now.<\/figcaption><\/figure>\n
Check the CPU model against what was advertised, that the RAM total matches, and that the disks are the type and size you ordered. cat \/proc\/mdstat<\/code> tells you whether software RAID is assembled. A dedicated server delivered with an unassembled second disk is common enough to be worth checking.<\/p>\n
Base system<\/h2>\n
apt update && apt upgrade -y\nhostnamectl set-hostname server.yourdomain.com\ntimedatectl set-timezone UTC<\/code><\/pre>\n
Set the timezone to UTC and leave it there. Every log on the machine gets timestamped with it, and when you are correlating a web server log against a database log against a provider status page at 2am, having everything in one timezone saves real time.<\/p>\n
Add the hostname to \/etc\/hosts<\/code> as well, or a lot of software will complain about not being able to resolve it, including the mail daemon.<\/p>\n
Lock it down before it is public<\/h2>\n
Do this before the site exists, not after. The IP is already being scanned.<\/p>\n
adduser deployer\nusermod -aG sudo deployer\nufw default deny incoming\nufw default allow outgoing\nufw allow OpenSSH\nufw allow 80\/tcp\nufw allow 443\/tcp\nufw enable\napt install fail2ban -y\nsystemctl enable --now fail2ban<\/code><\/pre>\n
\"UFW
The firewall as it should look before anything else goes on the machine.<\/figcaption><\/figure>\n
Then switch SSH to key only. The full sequence, including the config override that catches people out on modern Ubuntu, is in our SSH hardening guide<\/a>. The order is not negotiable: create the user, test sudo, add the key, test the key, then disable passwords.<\/p>\n
Stack or panel<\/h2>\n
Decide this once, because switching later means rebuilding.<\/p>\n
A control panel<\/strong> if you host client sites, need email accounts, or want someone else to be able to manage it. cPanel and WHM is the standard and it costs money. aaPanel and CyberPanel are free alternatives. Install a panel on a clean<\/em> machine, before any web server exists, because they all want to own nginx, MySQL and PHP and they fight anything already installed.<\/p>\n
A plain stack<\/strong> if this box runs your own applications and you are comfortable on the command line. Less overhead, fewer moving parts, no licence:<\/p>\n
apt install nginx mariadb-server php-fpm php-mysql -y\nsystemctl enable --now nginx mariadb\nmysql_secure_installation<\/code><\/pre>\n
Do not skip mysql_secure_installation<\/code>. It sets the root password, drops the anonymous users and removes the test database, all of which exist by default and none of which should.<\/p>\n
\"Terminal
Record these. In six months you will want to know what this box was built with.<\/figcaption><\/figure>\n
Then confirm nothing is listening that should not be:<\/p>\n
\"ss
MySQL on 127.0.0.1 rather than 0.0.0.0 is the line to check.<\/figcaption><\/figure>\n
Deploy and go live<\/h2>\n
    \n
  1. Create the vhost<\/strong> and put the site files in place.<\/li>\n
  2. Restore or import the database<\/strong>, then update the credentials in the site config.<\/li>\n
  3. Test by IP or a temporary hostname<\/strong> before touching DNS. Every page, not just the homepage.<\/li>\n
  4. Issue the certificate.<\/strong> certbot --nginx -d yourdomain.com -d www.yourdomain.com<\/code>. This needs DNS pointing at the server, so on a migration you may need a DNS challenge instead.<\/li>\n
  5. Then change DNS<\/strong>, having lowered the TTL a day earlier. Our DNS propagation guide<\/a> explains why that day matters.<\/li>\n<\/ol>\n
    Before you call it done<\/h2>\n
    This is the part that gets skipped, and it is the part that matters in six months.<\/p>\n