What you take on when you rent a VPS

What you take on when you rent a VPS

What you take on when you rent a VPS (virtual private server) is everything above the hypervisor: the operating system and every consequence of what it does on the network. The provider keeps the hardware alive, keeps the host running, and keeps the network reachable to the edge of their datacentre. From the first boot, patching, the firewall, backups, monitoring and the mail your IP (internet protocol) address sends are yours.

The handover happens the moment you click Zamów. Nothing announces it, because there is nothing to announce: the machine is simply yours now. This page is the inventory of what "yours" contains. If you want the product definition first, what a VPS is and how it differs from shared hosting covers that ground.

Where the provider stops and you start

The line follows the hypervisor. On their side sit the physical host, power, cooling, the host kernel, the network up to their edge, the panel that boots, reinstalls and rescues your machine, and usually a network firewall you can switch on. On your side sit the guest operating system from first boot, every package on it, the accounts, the keys, the data, and every packet the box sends out.

There is a simple test for each duty below. If it breaks at 03:00, who fixes it? On an unmanaged plan the answer is you, and the provider is not allowed to log in and repair your operating system unless you ask them to.

Updates and reboots are your job now

An installer image is already out of date when it boots, because it was built weeks before you ordered. The first two commands on a new server are these:

sudo apt update && sudo apt upgrade
cat /var/run/reboot-required

That file exists only when an installed package needs a restart to take effect, usually the kernel or a core library, and cat then prints *** System restart required ***. If the file is missing you get No such file or directory, which means no reboot is pending. Nothing else on the system tells you this, so a server can sit fully patched on disk while it keeps running the old vulnerable kernel in memory for months.

Automatic security updates are one package and one check:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
systemctl status unattended-upgrades

Ubuntu server images usually ship this enabled for security updates, and Debian images often do not. Check rather than assume, because "it is automatic" is the belief that leaves a machine unpatched for a year. Installing the packages is only half the work: the running kernel and long-lived services keep the old code until something restarts them. Either set Unattended-Upgrade::Automatic-Reboot "true"; with an Automatic-Reboot-Time in /etc/apt/apt.conf.d/50unattended-upgrades, or pick your own window and reboot on purpose. On Ubuntu, needrestart runs after apt and lists the services still holding deleted libraries.

Some reboots are not your choice. Host maintenance restarts your machine, so anything you started by hand returns only if it is enabled:

systemctl is-enabled nginx postgresql

disabled in that output means the service will be missing after the next restart, and you will hear about it from a customer rather than from the server.

The firewall is open until you close it

A fresh image runs no firewall. sudo ufw status prints Status: inactive, and ufw is the uncomplicated firewall front end that most Ubuntu guides use. Inactive means every service bound to 0.0.0.0 is reachable from the whole internet, including the database you installed for local testing. Look at what is really listening before you decide anything:

sudo ss -tulpn

Then allow SSH (secure shell) before you turn the firewall on, in that order:

sudo ufw allow OpenSSH
sudo ufw enable

The prompt Command may disrupt existing ssh connections. Proceed with operation (y|n)? is a real warning. Enable a default-deny firewall with no SSH rule and your session dies at the next packet. The way back in is the provider's console, where resetting the root password from the rescue console is sometimes the only door left open.

Two things surprise people here. First, the provider's network firewall is a separate control from ufw, so a port can be open in one and closed in the other, and a packet capture on the box shows nothing at all when the upstream rule is the one dropping traffic. Second, Docker publishes ports around ufw. A container started with -p 5432:5432 is reachable from the internet even while ufw status lists a deny rule, because Docker rewrites the destination of that packet and it is decided in the forward path by Docker's own chains, while ufw's rules sit in the input path and never see it. Bind published ports to localhost instead, -p 127.0.0.1:5432:5432, and reach them over an SSH tunnel.

Verify from somewhere else. A scan run on the server tells you what the server can reach, not what the internet can reach.

Why a snapshot is not a backup

A snapshot is a copy of your disk held by the same platform, under the same account, paid with the same card. It rescues you from a bad upgrade, a deleted directory or a failed migration, and it does that faster than anything else you own. It does not survive the events that take the account with them: an account closure, a stolen panel login, an unpaid invoice or the deletion of the server itself. In each of those cases the snapshot is inside the thing that was lost.

A backup lives somewhere the server cannot destroy. Give the machine credentials that can write new data and cannot delete history, so an attacker with root on the box still cannot erase your restore points. Then prove the repository is alive on a schedule:

restic -r <repository> snapshots
restic -r <repository> check --read-data-subset=5%

snapshots prints the date of the newest backup, so a job that has been failing quietly for six weeks shows up as a six week old date instead of an error nobody read. check reads the repository structure and, with --read-data-subset, a sample of the actual data, which catches silent corruption in the storage rather than in your script. Until you have restored to a scratch server once, you do not know whether the restore works. which failures a snapshot covers and which it does not goes through the cases one by one, and an offsite restic repository with append only keys is the setup this paragraph describes.

Nobody is monitoring your services

The provider's monitoring watches the host. It does not know that your disk filled up or that your database was killed. The two failures behind most "the site is down" tickets announce themselves as strings you can go and read:

df -h
journalctl -k | grep -i "out of memory"

An application error of No space left on device means the filesystem is full, most often because log files grew and nothing rotated them. Out of memory: Killed process 1234 (mysqld) means the kernel OOM (out of memory) killer chose your database when RAM ran out, so the process vanished without crashing on its own and without writing anything useful in its own log.

Four things are worth having from day one: an uptime check that runs outside the box, because a machine that is down cannot alert you about being down, an alert on free disk space, a weekly read of journalctl -p err -b, and a note of what normal memory use looks like so you can tell slow growth from a spike. Learn one number that is not your fault as well. %st in top is steal time, the CPU time the hypervisor handed to another tenant, and steal time from a noisy neighbour explains when to open a ticket and when to move.

What happens when your IP starts sending spam

The abuse contact registered against your IP address is the provider, not you. Complaints land there: spam reports, blocklist notices, phishing reports and scan complaints from networks your box touched. The provider forwards them to the address you gave at signup, with a deadline. The deadline matters, because silence is what turns a complaint into a suspension.

The usual cause is an application rather than a stolen SSH key. An outdated CMS (content management system) with an upload hole, or a contact form with no rate limit, sends through the local MTA (mail transfer agent) at full speed. You can see it directly, using Postfix's queue tool here:

postqueue -p
sudo ss -tunp | grep ':25'

A queue holding thousands of messages to addresses you have never heard of is the whole story. At the same time your own mail starts bouncing with a line that names the list, such as 550 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org. Delisting is requested at the blocklist and not from your provider, and a delisting fails again within hours if the source is still running. Fix the source, then request removal, then reply to the ticket with what you found and what you changed. how an abuse complaint travels and what your reply has to contain covers the reply itself.

You also inherit the address's past. A recycled IP can already sit on a blocklist before you send your first message, so check it on the day you get the server, while asking for a different address is still easy.

What an SLA actually promises

An SLA (service level agreement) promises availability of the provider's part: the host and the network. Your own service is outside it. Your shop can be offline all week with the SLA met in full, because the hypervisor was up and your application was not.

The percentage is arithmetic. Over a 30 day month, 99.9% allows about 43 minutes of downtime on their side, and 99.99% allows about 4 minutes. Both figures are compatible with your site being unreachable far longer for reasons that sit on your side of the line.

Read four things before you assume anything: where availability is measured, what the exclusion list contains, what the remedy is, and who has to claim it by when. Scheduled maintenance, emergency security work and attack traffic are commonly excluded. The remedy is normally a credit against a future invoice, claimed by you inside a short window, and it does not compensate lost revenue. Buyers read "99.9%" as "my site stays up". It says that if the platform misses the number and you file a claim in time, some money comes back on the next bill.

RODO: what changes when the data belongs to other people

RODO is the Polish name for the GDPR (general data protection regulation), and it applies to your server the moment it holds personal data about other people. That covers the obvious cases, customer records and payroll, and the less obvious ones: a newsletter list, or web server logs, because an IP address with a timestamp is personal data.

If you decide why and how that data is processed, you are the controller. Your host holds the disks, so the host processes the data on your behalf. That relationship has to be in writing, as a data processing agreement, called an umowa powierzenia przetwarzania danych osobowych. It is a document you request and keep, not a checkbox on the order form.

Here is what the arrangement requires you to have:

• A written processing agreement with the host, naming the subject and duration of the processing, the types of data, the processor's duties, and what happens to the data when you leave.
• The list of sub-processors your host uses, because their suppliers touch the same disks.
• The country the disks are in. It decides whether the data leaves the European Economic Area, and a transfer outside that area needs its own legal basis, so a datacentre inside the EU keeps the question short.
• A breach path in writing: the processor informs you without undue delay, and you are the one who deals with the supervisory authority, which in Poland is UODO (Urząd Ochrony Danych Osobowych).
• Security on your side of the line. Encryption, access control, patching and working backups stay with you, and no agreement moves them to the host.

This is a description of requirements and not legal advice. How they apply to your organisation is a question for a lawyer. Two items are worth settling before you order, because they are expensive to change later. The datacentre country is fixed at purchase, and changing it afterwards means migrating the whole server to a new one. The processing agreement is far easier to obtain during a sales conversation than during an audit. what to check when you are buying from Poland goes through the rest of the local detail.

Netto or brutto: what the price on the card really is

In this market the advertised monthly figure is frequently netto, meaning before VAT (value added tax), and the checkout page is where the real number appears. As of August 2026 the standard VAT rate in Poland is 23%, so a plan advertised at 40 zł netto is 49.20 zł brutto per month.

Four numbers deserve a look before you confirm: the netto price, the brutto total you will actually be charged, the renewal price after any promotional first term, and the billing period. Longer periods are usually cheaper per month and are paid in advance, which makes them a cash flow decision rather than a technical one.

Two more items live on the same page. Enter your NIP (tax identification number) during the order if you are buying as a business, because an invoice issued without it needs a correcting document afterwards. Then check how renewal works: whether it is automatic, when the charge lands, and how much notice a cancellation needs.

If the provider is established in another EU country and you are VAT registered, the invoice may arrive with 0% VAT and a reverse charge note, which changes your paperwork rather than your cost. Your accountant decides how that is booked. For the purchase decision the rule is simpler: compare brutto to brutto, and compare renewal prices rather than first term prices.

The decision this page does not make

Every duty above can be bought. Someone else can patch the packages, hold the firewall, run and test the backups, watch the disk, and answer the abuse mail at 03:00. That is a level of service question and it deserves its own page, so managed and unmanaged hosting compared duty by duty makes that call with the costs and the trade-offs attached. Read this page as the inventory and that one as the choice.

A useful way to use both: walk down the list here and mark each duty as mine or as bought. Anything you cannot mark is the one that will fail first, because it belongs to nobody.

FAQ

Who is responsible for backups on a VPS?

You are, unless you bought a backup service and can name the date of your last successful restore. The provider protects their platform against hardware failure, which is a different thing from protecting your data against your own commands, a compromised application, or a closed account. Keep one copy off the platform, under credentials the server itself cannot use to delete history, and restore it to a scratch machine at least once so you know the restore path works.

Does a snapshot count as a backup?

It covers some failures and misses others. A snapshot undoes a bad upgrade or a deleted directory in minutes, because it sits on the same platform as the server. That same location is why it fails when the account is closed, the panel login is stolen, the payment fails or the server is deleted: the snapshot is inside whatever was lost. Treat it as a fast undo and keep a real backup somewhere else.

Does a 99.9% uptime SLA mean my site will stay up?

No. An SLA measures the provider's host and network, not your application. Over a 30 day month, 99.9% allows about 43 minutes of downtime on their side, while your own service can be unreachable for far longer without anything being breached. The usual remedy is a credit on a future invoice that you have to claim within a stated window, and it does not cover lost revenue.

Do I need an umowa powierzenia przetwarzania with my hosting provider?

If personal data about other people sits on the server, the host processes that data on your behalf, and the relationship has to be in writing. Ask for the processing agreement, the list of sub-processors and the country the disks are in before you upload anything, since the datacentre location is fixed when you order. This describes the requirement rather than giving legal advice: how it applies to your organisation is a question for a lawyer.

Why is the price I pay higher than the price advertised?

Advertised VPS prices are frequently netto, which means before VAT, while the checkout total is brutto. As of August 2026 the standard Polish VAT rate is 23%, so add roughly a quarter to any netto figure. The other two gaps are the billing period, because annual terms are quoted per month and charged up front, and the renewal price, which is often higher than a promotional first term. Compare brutto renewal prices when you shop.