Setup & operation

Run ssh root@your-server-ip from any terminal on macOS, Linux or Windows 10 and later. Use the key you supplied at provisioning, or the password emailed to you. The first connection shows a host key fingerprint — compare it against the one in the control panel before accepting it.

Five steps cover the overwhelming majority of real-world compromises: key-based SSH with password authentication disabled, no direct root login, a default-deny firewall, unattended security updates, and fail2ban or an equivalent. Together they take about ten minutes and eliminate essentially all automated attacks.

Disable password authentication entirely — brute force against key-based SSH is not possible. Add fail2ban to reduce log noise, and consider moving SSH off port 22 to cut scanner volume by roughly 95%. The strongest option is putting SSH behind WireGuard so it is never exposed to the public internet.

Use nftables on modern Linux, or ufw as a friendlier front end. Set the default inbound policy to drop, allow established and related connections, then allow only the ports you actually serve. Always allow your SSH port before enabling the policy, or the console will be your only way back in.

On KVM, yes. OnionVPS provides templates for Ubuntu, Debian, AlmaLinux, Rocky, Fedora, Arch, Alpine, NixOS, FreeBSD, OpenBSD, Windows Server, Proxmox and others, and you can upload a custom ISO and install anything that boots. On container-based virtualisation such as OpenVZ, you are limited to Linux templates the host provides.

Yes, on every plan, at no cost and with no approval step. Upload the ISO from the panel or point us at a URL, attach it as virtual media, and boot from it through the VNC console. Anything that boots on standard KVM hardware will install, including BSDs, hardened images and appliances.

KVM (Kernel-based Virtual Machine) is full hardware virtualisation built into the Linux kernel, using processor extensions to run each guest with its own kernel and hardware-enforced isolation. Unlike OpenVZ or LXC, which share the host kernel, a KVM guest can load kernel modules, run any operating system and use real swap.

On a KVM VPS, yes, without restriction — install Docker Engine from the official repository and everything works, including buildx, Compose and Docker-in-Docker. On OpenVZ or LXC-based virtual servers Docker either fails or requires unsafe host configuration, because it needs cgroups and namespaces that shared-kernel virtualisation does not expose.

Yes. Nested virtualisation is enabled on every OnionVPS instance, so you can run KVM guests inside your instance, install Proxmox VE, or run Docker-in-Docker and VM-based CI jobs. Many providers disable it, which is the usual reason Proxmox and certain CI configurations fail elsewhere.

Yes, outbound port 25 is open on every OnionVPS instance by default. There is no support ticket, no account-age requirement and no paid unblock. Most providers block it permanently to control spam, which is why self-hosted mail is impossible on much of the market.

Yes, for both IPv4 and IPv6, directly from the control panel, and changes propagate within minutes. Reverse DNS is essential for mail: most large receivers reject messages from an address whose PTR record does not resolve back to the sending hostname.

Yes. Port 25 is open, reverse DNS is self-service, and our address space has no spam history. Mailcow or Stalwart give you a complete stack in an evening. The difficulty is not installation — it is deliverability, which depends on SPF, DKIM, DMARC, a matching PTR and a patient warm-up.

Every instance includes one IPv4 address and a routed IPv6 /64 — that is 18 quintillion v6 addresses, not one. Up to eight additional IPv4 addresses can be added per instance at $3 a month each, from the panel, with no justification form and no waiting period.

Yes — a routed /64 subnet on every instance, at every tier, at no cost. Not a single address: an entire subnet routed to your server, so each container or service can hold its own public IPv6 address without network address translation.

A snapshot is a point-in-time copy of your instance's disk, taken instantly and stored on the same infrastructure. A backup is a copy stored elsewhere. Snapshots protect against your own mistakes; backups protect against infrastructure failure. You need both, and three snapshots are included free on every plan.

Follow the 3-2-1 rule: three copies, on two kinds of media, one off-site. In practice that means snapshots for quick rollback, plus an encrypted nightly backup with restic or Borg to a different jurisdiction, plus a restore you have actually tested. An untested backup is a hypothesis.

Use the out-of-band VNC console in the panel, reboot into single-user or rescue mode from the bootloader, remount the root filesystem read-write and run passwd. It takes about two minutes and needs no support ticket. If the disk is LUKS-encrypted and you have lost the passphrase, the data is unrecoverable by design.

An out-of-band console attaches to your instance's virtual display and keyboard through the control panel, independently of its network. It is how you fix a firewall rule that locked you out, a broken SSH configuration, or a boot failure — without opening a support ticket. It works even when the instance has no network at all.

Data has to physically move, so a region change is a rebuild rather than a live migration. Deploy the new instance, sync the data with rsync or a restic restore, verify, cut DNS over with a short TTL, then destroy the old one. Plan for 30 to 90 minutes depending on data volume.

Use Ubuntu LTS if you are learning or want the largest body of tutorials and newer packages. Use Debian for a minimal, predictable, long-lived server — it idles in roughly half the memory, ships no Snap and no vendor telemetry. Both use the same package format, so most instructions transfer directly.