Servers: connecting, installation stages, and metrics
How CreateYourVPN connects and secures your VPS: every installation stage step by step, server states, and what each metric on the card means.
A server is the main building block of your infrastructure: an ordinary rented VPS that CreateYourVPN turns into a secured node of your VPN. In this lesson we'll walk through what happens when you connect a server — stage by stage — and learn how to read its metrics.
What you need to connect a server
Any clean VPS running Ubuntu (or Debian) with at least 1 CPU / 1 GB RAM. Don't have a server yet? Here's a guide to buying a VPS.
Connecting starts with the "Connect a server" button (the first server of a cluster) or "Add node" (extending an existing cluster — see the lesson on clusters). The setup wizard will ask for:
| Field | What to enter |
|---|---|
| Server IP address | The public IP of your VPS (IPv4 or IPv6) |
| SSH port | Usually 22 for a fresh VPS |
| User | Usually root |
| Root password | The password from your hosting provider — needed only once |
| Display name | A label for your dashboard, e.g. FRA-1 |
Next comes the "Schedule" step: the server's timezone and an optional regular reboot (daily/weekly/monthly at a set time). Reboots help the server "breathe easier" over the long run.
The root password is used exactly once — for the very first login. Already during the first installation stage, CreateYourVPN switches the server to key-based access and disables password login. The password itself is never stored anywhere.
What happens during installation
After you click "Start installation", the panel shows a list of stages with live status ("waiting" → "running" → "done"). You can close the window — the installation continues in the background. Here's what's behind each stage.
Preparing the server. The most important stage — a full set of security hardening measures. The system creates a dedicated service user on the server with key-based access, moves SSH to a non-standard port, disables password and root login, enables a firewall (only the necessary ports stay open), brute-force protection, and automatic security updates. This is also where the timezone and reboot schedule are applied.
Setting up the control panel (first server of a cluster only). The master (management node) is deployed: the user database and the certificates it will use to "recognize" its worker nodes. Admin credentials are generated automatically — you don't need to invent or store anything.
Activating the cluster (first server only). The system verifies that the master is ready and brings the cluster online.
Starting the worker. The service that will carry VPN traffic is installed on the server, and networking is configured. User traffic is accepted on the standard HTTPS port 443 — from the outside it's indistinguishable from visits to a regular website.
Joining the cluster. The server receives a certificate, registers with the master, and the system verifies the connection. From this moment the node is in service.
Altogether this usually takes a few minutes. If a stage fails with an error, it's most often a typo in the IP/password or a "dirty" server that already has something installed on it. Double-check the details and try again on a clean VPS.
Server states
You'll see status labels on the cards — here's what they mean:
| Status | What it means |
|---|---|
| Queued | The server has been added; installation is about to start |
| Hardening | The preparation and security stage is running |
| Secured | Hardening is done, key-based access works |
| Installing | The control panel or the worker is being installed |
| Ready | Everything is installed and verified |
| Failed | The last stage ended with an error |
Worker nodes also have their own connection states with the master: "Installing", "Registering", "Connected", "Error", and others. Only connected nodes serve users.
Metrics: what the numbers on the card mean
Every server reports its state once every few minutes, and the panel refreshes the numbers every few seconds. The compact card shows the four key metrics plus an online chart; the full metrics panel shows everything at once:
| Metric | What it shows |
|---|---|
| Online | How many devices are currently connected to the server. Unique addresses are counted — roughly "how many phones and laptops are sitting on the server right now" |
| Throughput | Current speed through the server, Mbit/s |
| CPU | Processor load, % |
| RAM | Memory in use, % |
| Disk | Disk usage, % |
| Load | Load average — the system's averaged busyness over a minute |
| Uptime | How long the server has been running without a reboot |
| Capacity | An estimate of the channel's bandwidth, Mbit/s (appears once the system has estimated it from real traffic) |
The full metrics panel also has 24-hour charts: online connections, throughput, CPU, and RAM — great for spotting daily peaks.
If a server stops reporting, the panel honestly shows "No data — agent not responding" and marks outdated numbers with a "stale" badge. Metric freshness is one of the signals used by the monitoring system, which we'll cover in lesson 7.
Coefficient
The node inspector has a "Coefficient" field — the server's weight in load balancing. It defaults to 1.0. The higher the coefficient, the more users the system is willing to send to this server compared to its neighbors. Exactly how it factors into distribution is covered in the next lesson.
Key takeaways
- Connecting a server is just IP + root password + a name; the rest is automated.
- The first stage is always securing the server: keys instead of passwords, a firewall, auto-updates.
- Online means devices, Throughput is the current speed, Capacity is the channel's ceiling.
- Metrics aren't just pretty numbers: load balancing (lesson 4) and monitoring (lesson 7) run on them.