Getting Started with ServerNet: The First 24 Hours After Purchasing Your Service

You've Bought the Service; Now What?

The welcome email has arrived, the access credentials are waiting in your user panel, and your domain still doesn't point to the new server. This is exactly the moment when most day-one errors occur—not due to technical faults, but because of the wrong order of tasks. If you set up DNS before changing the default password, you'll have a publicly accessible site that anyone can log into with the default password. If you install SSL after the full migration, users will see certificate errors and leave.

The right order is: security first, then DNS, then the certificate, then backup. Let's go through it in that order.

Step One: Change the Default Password, Before Anything Else

Hosting services are typically delivered with a temporary password or one displayed in the panel. Anyone with access to your panel or email could see this password. The first thing you do after logging in is change it. Not after lunch, not after DNS setup. Right now.

On Linux hosting, this is done through the account management section in the panel. The new password should be at least 12 characters long and include a mix of uppercase letters, lowercase letters, numbers, and symbols. If you use SSH, enable public key authentication after changing the password:

ssh-keygen -t ed25519 -a 100
ssh-copy-id user@your-server-ip

An ed25519 key is a better choice than RSA-4096; it's shorter, faster, and provides the same security. After the key is copied, disable password authentication:

sudo nano /etc/ssh/sshd_config
# PasswordAuthentication no
sudo systemctl restart sshd

Here's where people make mistakes: many only change the hosting password and leave the default database or FTP passwords untouched. If your service includes phpMyAdmin or FTP, those also have default passwords. Change them all. Don't use a single shared password for everything; if one is compromised, the rest are too.

Step Two: DNS Setup, with TTL in Mind

Before changing any DNS records, check the TTL (Time To Live) of the current record. If the TTL is 86400 seconds (24 hours), some users will see the old site for up to 24 hours after the change. If you've planned ahead, reduce the TTL to 300 seconds (5 minutes) 24 to 48 hours before the migration. If you're migrating right now, do this and wait.

In your domain management panel, point the A and AAAA records to the new server's IP. For ServerNet Linux hosting, you'll find the IP in the "Service Information" section of your user panel. Set up the following records:

example.com. 300 IN A 185.10.xx.xx
www.example.com. 300 IN A 185.10.xx.xx
example.com. 300 IN AAAA 2a00:xxxx:xxxx::1

If you have email on this domain, migrate the MX and SPF records as well. Forgetting the MX records means your emails won't reach the inbox after the migration, and you typically won't see any errors either. The emails just get lost.

After making the changes, don't just wait and stare at the screen. Use a DNS checker service to see how the records have propagated from different parts of the world. It usually takes between 5 minutes and 2 hours.

Step Three: Installing the SSL Certificate

Once DNS has settled on the new server, it's time for the SSL certificate. If you do this before DNS, the certificate issuance process (especially the HTTP-01 method) will fail because the Let's Encrypt server can't reach your domain.

For Linux hosting, there's usually an "SSL/TLS" option in the panel that automatically issues and installs a Let's Encrypt certificate. If you're using a VPS and managing the web server yourself, use certbot:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

After installation, enable the HTTP to HTTPS redirect. In nginx, this is done in the site's configuration file:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

One note: Let's Encrypt certificates expire every 90 days. Enable automatic renewal and make sure the corresponding cron job is working. After the initial installation, run the following command to test automatic renewal:

sudo certbot renew --dry-run

If the output doesn't include Congratulations, automatic renewal isn't working, and your site will show certificate errors in 90 days.

Step Four: The First Backup, Before You Touch Anything

Most people take a backup at the very end. That's a mistake. Take the first backup before installing anything. Why? Because if something goes wrong after installing WordPress or WooCommerce, you'll want to revert to a clean state, not a half-configured system.

On Linux hosting, there's usually a backup option in the panel that backs up files and the database separately. If you're using the command line:

mysqldump -u username -p database_name > /backup/db_$(date +%Y%m%d).sql
tar -czf /backup/files_$(date +%Y%m%d).tar.gz /var/www/html

Don't keep the backup on the same server. If the server goes down, the backup goes with it. Have at least one copy on cloud storage or another server. Do this with rsync to an external destination:

rsync -avz /backup/ user@backup-server:/backups/

Also, test the restore process. A backup that can't be restored isn't a backup; it's a dead file. Create a test database and restore the backup into it. If it doesn't work, now is the time to find out—not on Friday night when the site is down.

Step Five: Final Checklist and Documentation

After these four steps, your site is technically ready. But there's one more step that most people skip: documentation. Write down the access credentials, server IP, file paths, database name, and DNS settings in a secure file. Do this now, not three months from now when you've forgotten what the database password is.

To find your service access credentials, see the guide to finding hosting and server service access credentials. If you haven't enabled two-factor authentication (2FA) on your user account, do it right now. The user account security guide for cloud and hosting services covers exactly this topic.

If you're migrating from another host, read the complete checklist for migrating to ServerNet without service interruption. This checklist includes items not covered in this article, such as email migration and cron job configuration.

Where People Go Wrong: The Order of Tasks

The most common mistake I see in the first 24 hours is this: someone changes DNS, installs SSL, brings the site online, and then remembers they haven't changed the default password. The result? An accessible site with a default password. Bots start scanning your IP within less than an hour after DNS propagates. The first thing they try is default combinations like admin/admin and root/toor.

The sign of this happening: one morning you find strange files in public_html, or your database has a new table you didn't create. By then, it's already too late.

Choosing Between Speed and Security

There's a real trade-off: if you do all these steps carefully, it might take 2 to 3 hours. If you're in a hurry and want the site up right now, you'll be tempted to change DNS first and do the rest later. Don't do it. A site that comes online 3 hours late is better than a site that gets hacked on day one.

The only situation where changing the order makes sense: if your site is a simple landing page with no user data and you want to test right now that the server works. In that case, change DNS, put up a test page, and then do the rest. But only if you've already changed the default password at that very first moment.

Frequently Asked Questions

How long does DNS propagation take after a change?

Usually between 5 minutes and 2 hours. It's faster if you've reduced the previous TTL. If the TTL was 24 hours, some users will see the old site for up to 24 hours. Use DNS checker services to monitor the status.

Can I install SSL before changing DNS?

No. The HTTP-01 method used by Let's Encrypt requires the domain to point to your server. If DNS still points to the previous server, certificate issuance will fail. DNS first, then SSL.

Where should I keep the backup?

Not on the same server. Keep a copy on cloud storage, another server, or at least a separate disk. If the server goes down, a backup on the same server is lost too. And remember: test the backup, don't just create it.

What happens if I don't change the default password?

Bots will scan your IP within less than an hour after DNS propagates and try default combinations. If they succeed, they'll place malicious files on your site or corrupt the database. This happens on day one or two, not after a month.