VPS guides and step-by-step tutorials
Set your server up the same evening — copy the commands below, in order, from first login to a site on HTTPS
Setting up a VPS takes about thirty minutes and eight steps: install the operating system from an image, log in over SSH, create a user with sudo, switch login to a key, close every port you do not use, install a web server and a database, issue a TLS certificate, and take the first backup. This page walks through all eight with the exact commands for Ubuntu 22.04 and 24.04 and Debian 12, plus what to do when a step fails. Nothing here is specific to one provider — the same commands work on any server you have root on.
The eight steps, with commands
Run them in this order on a freshly installed Ubuntu or Debian server.
-
Step 1 · Access
Log in over SSH
A new server is reached by its IP address and the password issued with it: ssh [email protected] from a terminal on Linux, macOS or Windows 10 and later. If the connection times out, the server is not up yet or a firewall in front of it blocks port 22 — use the KVM console in the panel to check. First thing after logging in, change the initial password with passwd.
-
Step 2 · Users
Create a user with sudo and stop using root
Daily work under root turns every typo into an outage. Create a normal account and give it administrative rights: adduser deploy then usermod -aG sudo deploy. Log out, log back in as the new user and confirm the rights with sudo whoami — the answer should be root. On Debian, install sudo first with apt install sudo.
-
Step 3 · Keys
Switch SSH login to a key
A key removes the whole class of password-guessing attacks. On your own machine run ssh-keygen -t ed25519, then copy the public half to the server with ssh-copy-id [email protected]. Verify that key login works, then open /etc/ssh/sshd_config, set PasswordAuthentication no and PermitRootLogin no, and apply it with systemctl restart ssh. Keep the current session open while you test the new one.
-
Step 4 · Updates
Update the system and turn on security patches
Bring the freshly installed image up to date with sudo apt update && sudo apt full-upgrade, and reboot if the run creates /var/run/reboot-required. Then let the server patch itself: sudo apt install unattended-upgrades followed by sudo dpkg-reconfigure --priority=low unattended-upgrades. Security updates land without you, while regular package upgrades stay under your control.
-
Step 5 · Firewall
Close every port you do not use
Allow SSH before you enable the firewall, or you will lock yourself out: sudo ufw allow OpenSSH, then sudo ufw allow 80/tcp and sudo ufw allow 443/tcp for a web server, then sudo ufw enable. Check the result with sudo ufw status numbered and see what is actually listening with ss -tulpn. If a rule does lock you out, the KVM console still gets you in.
-
Step 6 · Web server
Install Nginx and PHP
Install the stack with sudo apt install nginx php-fpm php-mysql and start it with sudo systemctl enable --now nginx; the default page should answer on the server IP. Put your site config in /etc/nginx/sites-available/example.com, enable it by linking the file into /etc/nginx/sites-enabled/, test the syntax with sudo nginx -t and apply it with sudo systemctl reload nginx. Site files usually live in /var/www/example.com.
-
Step 7 · Database and TLS
Add a database and a certificate
For the database, sudo apt install mariadb-server and then sudo mysql_secure_installation — it sets the root password and removes the anonymous test accounts. For HTTPS you need the domain already pointing to the server with an A record: sudo apt install certbot python3-certbot-nginx, then sudo certbot --nginx -d example.com -d www.example.com. Renewal runs from a systemd timer, so nothing expires by surprise.
-
Step 8 · Backups
Take the first copy before you need it
Automatic backups are not part of the plan — you take copies yourself in the control panel, in the backups section, in a couple of clicks and with nothing to configure first. On top of that, keep a data-level copy: mysqldump -u root -p appdb > /root/appdb.sql for the database and tar -czf /root/site.tar.gz /var/www/example.com for the files. Store at least one copy off the server.
Commands are written for Ubuntu 22.04 and 24.04 and Debian 12. Replace 203.0.113.10, example.com and appdb with your own values.
Pick the track that matches your server
Commands and config paths differ between systems — start from the right one.
Linux: Ubuntu and Debian
The commands on this page target Ubuntu 22.04 and 24.04; on Debian 12 they are identical apart from package versions. Access is over SSH, with key login recommended from day one.
Windows Server
A different toolset: Remote Desktop instead of SSH, Server Manager and PowerShell instead of apt, and the built-in firewall instead of ufw. Access still starts from the KVM console.
No time to run it yourself
The same work can be handed over: initial setup, updates, monitoring and incident handling come as hour packages named Mini, Pro and Max.
The first hour after ordering
What happens between the order and a working server.
Choose an image and install the OS
You pick the image in the panel and start the installation yourself — Ubuntu, Debian or Windows Server. Nobody installs the system for you, so you know exactly what is on the machine and which packages it carries.
Open the KVM console
KVM gives you the screen and keyboard of the machine at hardware level: it works before the network comes up and stays available when SSH or the firewall is misconfigured. Open it once at the start so you know where it is when you need it.
Log in, harden, update
Steps 1 to 5 above take about fifteen minutes: sudo user, key login, ufw with only SSH, HTTP and HTTPS open, and unattended security updates. Do them before anything is exposed to the internet.
Deploy what you came for
Web server, database, container runtime or application. VPS and cloud servers run in trial mode for 5 hours before payment, which is enough to install the stack and put real load on it.
When something goes off-script
The usual dead ends and the way out of them.
Open the KVM console in the panel — it does not depend on the network stack. Log in there and run sudo ufw allow OpenSSH, or sudo ufw disable to reopen everything while you fix the rules.
Nine times out of ten it is file permissions: the home directory must not be group-writable, .ssh must be 700 and .ssh/authorized_keys must be 600, owned by the user. Run ssh -v to see which key the client actually offers, and check sudo journalctl -u ssh for the reason it was rejected.
Run sudo nginx -t first — it names the file and line of the broken directive. If the config is valid, the port is usually taken: sudo ss -tulpn shows what already listens on 80 or 443, and sudo journalctl -u nginx -n 50 shows the failure itself.
Check the three usual suspects in order: free -m for memory and swap, df -h for a full disk, and top for a process eating the CPU. A disk at 100 per cent makes a server look dead while it is perfectly healthy.
We do not give a formal SLA on a single server. For availability requirements we build a distributed fault-tolerant cluster across several data centres, so one failed node does not take the service down.
Moving a live site to a new server
Migration is done in a fixed order, and the DNS part comes first: lower the TTL of the A record to 300 seconds a day before the move, so the switch propagates in minutes rather than hours.
Then copy the files with rsync -avz /var/www/ deploy@NEW-IP:/var/www/, dump the database with mysqldump and load it on the new machine with mysql -u root -p appdb < appdb.sql. Bring the site up on the new server and test it by its IP before touching DNS. Only when it answers correctly do you point the A record at the new address, and keep the old server running for another day or two.
If you would rather not do it by hand, we can move the project for you, or take over the whole machine under server administration.
Migration serviceFrequently asked questions
Did not find your answer?
Write to us through the form on the contacts page.
Over SSH, using the server IP and the password issued with it: ssh root@your-server-ip from any terminal on Linux, macOS or Windows 10 and later. If SSH does not answer, the KVM console in the panel gets you in regardless of the network configuration.
With hardening, in this order: create a user with sudo, switch login to an SSH key, turn on the ufw firewall with only SSH, HTTP and HTTPS open, and enable unattended security updates. Only then install the application stack.
It is access to the server at hardware level: installing and reinstalling the OS, working before the network comes up, and emergency access when SSH is unavailable or the firewall locked you out.
With ufw: sudo ufw allow 443/tcp opens a port, sudo ufw status numbered lists the current rules and sudo ufw delete removes one by its number. Always allow OpenSSH before running sudo ufw enable.
Automatic backups are not included in the plan. You take copies yourself in the control panel, in the backups section, in a couple of clicks — and for data it is worth adding mysqldump for the database and tar for the site files, stored off the server.
Yes. VPS and cloud servers run in trial mode for 5 hours, so you can install your stack and put real load on it before deciding. Dedicated servers are assigned after payment; support helps you pick the configuration first.
Yes. They are written for standard Ubuntu, Debian and Windows Server and do not depend on where the server runs. The same commands work anywhere you have root access.
Yes. Write through the contact form and include the output of the command that stopped — we will advise within the scope of your service.