Getting started with ServerNet cloud servers

Why a Cloud Server and Where to Start?

If you've ever worked with shared hosting, you're certainly familiar with its limitations: limited resources, no root access, and dependence on the settings of other users on the same server. A cloud server eliminates these limitations and gives you a dedicated virtual machine where you can install any software, open any port, and change any setting. However, getting started with a cloud server can be confusing if you don't follow the right path.

In this guide, we assume you've registered in the ServerNet user panel and want to create your first instance. Our goal is to take you from zero to having an active cloud server with a secure SSH connection. We'll go through all the steps with technical details and real examples so that at the end, you'll know exactly what you've done and why.

Step One: Choosing the Right Image for Your Cloud Server

An image in the cloud server world is the operating system installed on your virtual disk. Choosing the image is the most important initial decision because changing it after setup will be time-consuming and troublesome.

Linux Distributions: The Primary and Secure Option

For most use cases, a stable Linux distribution such as Ubuntu 22.04 LTS or Debian 12 is the best choice. These distributions receive regular security updates and have extensive documentation. If you're not familiar with Linux, Ubuntu is a safer choice due to its large user community and quick responses on forums.

Important note: Choose LTS (Long-Term Support) versions, not regular ones. For example, Ubuntu 24.04 LTS is supported until 2029, while non-LTS versions only have 9 months of support, forcing you to upgrade sooner.

Ready-Made Application Images

If you don't want to start from scratch, ServerNet offers ready-made images such as WordPress, LAMP Stack, or Docker. These images have the necessary software pre-installed, and you just need to do the initial configuration. However, keep in mind: these images may have specific software versions that don't align with your needs. If your project is specialized, choose a bare Linux image and install the software yourself.

Common Mistake: Choosing an Image Without Checking Architecture

Some users select a 32-bit image on a server with a 64-bit architecture. This causes severe limitations on usable memory (maximum 4 GB) and incompatibility with many modern applications. Always choose the amd64 or x86_64 image, unless you have a very specific reason for a different architecture.

Step Two: Determining Instance Size and Resources

The instance size determines how much CPU, RAM, and storage space you have. Choosing correctly here helps you save costs and prevents server slowness or crashes.

Calculating Your Actual Needs

For a small website or blog, an instance with 1 vCPU and 1 GB RAM is sufficient. But if you want to run a MySQL or PostgreSQL database on the same server, consider at least 2 GB RAM, because databases are memory-intensive. For Node.js or Python applications that run multiple processes simultaneously, 2 vCPU and 4 GB RAM is a logical starting point.

A rule of thumb: if your average RAM usage exceeds 80% over a week, it's time to upgrade. You can check this with the free -h command in Linux.

Storage: SSD or HDD?

ServerNet uses SSD disks for its cloud servers, which have much higher read and write speeds compared to HDDs. If you have a database or an application with heavy I/O, definitely choose SSD. To start, 20 to 40 GB of space is usually sufficient. You can increase the disk size later, but decreasing it is usually not possible, so allocate a bit more space than your current needs.

Common Mistake: Choosing Too Small a Size to Save Money

Many users choose the smallest possible size to reduce costs. But if your server constantly runs out of memory and has to use Swap (virtual memory on disk), performance drops dramatically. In this case, not only does speed decrease, but your services may also be killed due to Out of Memory errors. It's better to choose an appropriate size from the start to avoid having to migrate to a larger instance later.

Step Three: Creating the Instance and Network Settings

After choosing the image and size, it's time to create the instance. In the ServerNet panel, select the "Create Instance" option and follow these steps:

1. Specify the instance name (e.g., web-prod-01). Consistent naming helps you manage multiple servers more easily in the future.
2. Choose the region. The closest region to your users will provide the best network latency.
3. Add an SSH key or receive a temporary password. Using an SSH key is much more secure than a password.
4. Accept the default network or select a private network if you've created one.

Do You Need a Static Public IP?

Each cloud server instance receives a public IP. If you want to connect your website or API to a domain, place this IP in the A record of your domain. For example:

example.com. 3600 IN A 185.10.10.10
www.example.com. 3600 IN A 185.10.10.10

If you're using IPv6, also add the AAAA record. Note that changing the IP after creating the instance may require updating DNS records.

Step Four: Initial Connection via SSH

After the instance is created and its status changes to Running, you can connect to it via SSH. If you used an SSH key, run the following command in your terminal:

ssh -i ~/.ssh/mykey.pem root@185.10.10.10

If you used a password, the command is simpler:

ssh root@185.10.10.10

On first login, the system will ask you to enter the password. After logging in, immediately run these commands to keep the system up to date:

apt update && apt upgrade -y   # For Ubuntu/Debian

Common Mistake: Permission Denied in SSH

One of the most common errors when connecting via SSH is Permission denied (publickey). This usually means your private key doesn't match the public key placed on the server. To fix this issue:

1. Make sure the key file path is correct.
2. Fix the key file permissions with chmod 600 ~/.ssh/mykey.pem.
3. If you're using Windows, use PowerShell or Windows Terminal, not the old CMD.

Step Five: Initial Security Settings

After a successful connection, perform a few essential security settings to protect your cloud server against initial attacks.

Creating a Non-Root User

Working with the root user carries high risk because any mistake can break the entire system. Create a regular user and give them sudo access:

adduser myuser
usermod -aG sudo myuser

Then log in with the new user and work with it from now on. For root access, use sudo.

Disabling Password Authentication

If you're using an SSH key, disable password authentication to render Brute Force attacks ineffective. Edit the /etc/ssh/sshd_config file:

PasswordAuthentication no
PermitRootLogin no

After making changes, restart the SSH service:

systemctl restart sshd

Before closing your current connection, open a new terminal and make sure the connection works with the new key. If an error occurs, don't close the current connection so you can fix the issue.

Firewall Configuration

Enable the UFW firewall and only leave necessary ports open:

ufw allow OpenSSH
ufw allow 80/tcp   # For HTTP
ufw allow 443/tcp  # For HTTPS
ufw enable

This keeps unnecessary ports closed and reduces the attack surface.

Summary and Next Steps

You now have an active cloud server that you can connect to via SSH and have performed the initial security settings. This infrastructure is the foundation for any project: you can install an Nginx web server, set up Docker, or create a dedicated database.

If you encounter any issues at any step, check the system logs. For example, the SSH log is located at /var/log/auth.log and shows detailed information about connection attempts. Also, the official ServerNet documentation and the Linux user community are great resources for troubleshooting.

A cloud server is a powerful tool, but the responsibility for maintaining it is yours. Regular system updates, periodic backups, and resource monitoring are habits that will prevent major headaches in the long run. Now that you've created your first instance, it's time to deploy your project on it.