The VPS market splits into three rough tiers. The bottom tier sells OpenVZ containers branded as VPS at three to five euros monthly, oversells host capacity by a factor of two or three, and watches performance collapse the moment one customer on your host hits peak load. The middle tier sells real KVM virtualisation but on mainstream cloud hardware in mainstream jurisdictions with KYC requirements and AUPs that disqualify half the workloads our customers run. The top tier delivers KVM on enterprise hardware in privacy-aligned jurisdictions without identity verification, with rDNS we control, with payment in cryptocurrency, with engineers who read tickets rather than escalation scripts.
We sit in the top tier. Every VPS on this page runs KVM with virtio paravirtualised drivers on bare-metal hosts we own outright, racked in datacenters we contract directly. NVMe storage everywhere. Dedicated CPU cores from VPS-2 upward via CPU affinity pinning. Custom rDNS aligned to your domain. No identity verification for standard plans. Pay in eleven cryptocurrencies through self-hosted BTCPay.
The phrase "VPS" appears on hosting pages priced from three dollars to three hundred dollars monthly. The technology stack underneath that phrase varies wildly. Three families dominate. Each delivers a meaningfully different product to the operator buying it.
OpenVZ creates isolated Linux containers that share a single kernel. Resources are soft-allocated via cgroups; the host can promise more total RAM and CPU to its containers than it physically has, on the assumption that not all tenants will demand their full allocation simultaneously. This works under normal conditions and fails under load. Industry benchmarks show 15-30% performance degradation when neighbour containers spike; the OpenVZ pricing advantage exists precisely because providers can fit more tenants on the same hardware. You cannot run a different kernel from the host. You cannot load arbitrary kernel modules. You cannot run Windows or BSD. Modern container ecosystems (Docker, Kubernetes) partially work but with caveats around kernel module dependencies. Cheap, dense, fragile.
LXC and LXD sit in similar architectural territory to OpenVZ but with cleaner cgroup integration, better namespace separation, and modern toolchain support. Same fundamental constraint: shared host kernel. Better isolation than classic OpenVZ but the noisy-neighbour mathematics remain unchanged when providers oversell. LXC is technically excellent for purposes where the operator controls the host (scaled internal infrastructure, CI environments, lab work). It is rarely the right model for customer-facing VPS where tenants demand strong isolation.
KVM is full hardware virtualisation. Each VPS runs its own kernel on virtual hardware emulated by the hypervisor. Modern KVM with virtio paravirtualised drivers (virtio-net, virtio-blk, virtio-scsi) achieves near-native performance on most workloads. CPU isolation is hardware-backed via Intel VT-x or AMD-V; memory is allocated from the host page tables; storage is exposed as virtual block devices. The overhead is real but small: typically 2-5% on CPU, 5-10% on storage I/O, single microseconds added to network latency. In exchange you get strong isolation, the ability to run any operating system, full control over the kernel and modules, and predictable per-tenant performance independent of what other tenants on the host are doing.
We run KVM with virtio across the entire fleet. No OpenVZ, no LXC for customer VPS. The performance overhead is worth paying for the isolation guarantees, the OS flexibility, and the customer-facing claim that one tenant's behaviour cannot degrade another tenant's performance.
| Property | OpenVZ / LXC | KVM (our stack) |
|---|---|---|
| Isolation model | Shared kernel, namespaces + cgroups | Hardware virtualization, separate kernels |
| OS flexibility | Linux only, host kernel determines features | Any OS: Linux, Windows, BSD, custom |
| Kernel modules | Restricted to host's loaded modules | Load any module you compile |
| Resource overcommit | Common, providers oversell 1.5-3x | Hardware-backed allocations only |
| Noisy-neighbour impact | 15-30% degradation under load | Negligible on dedicated cores (VPS-2+) |
| Custom firewall rules | Restricted iptables on shared kernel | Full netfilter, nftables, eBPF |
| Performance overhead | 2-5% under non-contention | 2-5% CPU, 5-10% I/O with virtio |
| Live migration | Tooling exists, complex semantics | Standard libvirt live migration |
Tell us what the VPS will run, how much data it will hold, and your jurisdiction preference. The configurator returns the matching tier, expected price, and the architectural decisions worth knowing before ordering.
MailWizz EMS at moderate concurrent load fits comfortably in VPS-2 envelope. Dedicated CPU pinning ensures consistent dashboard responsiveness for customers. NVMe for the MailWizz database keeps query latency low. Bulgaria offers EU jurisdiction with the best price-performance.
Configurator output is a recommendation, not an order confirmation. Confirm exact stock and any custom requirements on Telegram before payment. Cross-tier upgrades take 2-5 minutes during a brief reboot; you can start lower and scale up if your actual usage patterns warrant.
Four reference configurations cover the majority of VPS workloads. Each tier scales the resources that typically scale together: more vCPU pairs with more RAM pairs with more storage pairs with more bandwidth.
Custom configurations between tiers configurable on request: if you need 12 vCPU with 8 GB RAM, or 4 vCPU with 32 GB RAM, we can stage non-standard mixes when stock allows. Operators with predictable annual spend get yearly discounts (10% on 12-month, 5% on 6-month commitments).
The phrase "VPS or dedicated" misses that the right answer is often "VPS for this part, dedicated for that part." Most production architectures blend both. Below are nine common patterns where VPS is the correct tool and the rationale for each.
MailWizz is a PHP application sitting in front of your sending MTA. The web interface, list management, campaign scheduler, and customer panel all run as standard PHP. Database load is moderate (millions of subscribers fit within MySQL on local NVMe). VPS-2 handles installations up to ~100K subscribers across multiple lists; VPS-3 fits larger deployments or higher concurrent campaign counts. The actual sending happens on a separate dedicated PowerMTA box; the VPS frontends the management plane.
Multi-host PowerMTA architectures separate concerns across machines. The bounce processor parses ARF feedback loops and incoming bounces; the FBL ingester handles ISP feedback loop submissions; the queue overflow handler absorbs bursts when the primary node hits queue limits. Each helper sits on its own VPS for fault isolation. A VPS-1 or VPS-2 handles each helper role; the primary sending node remains on dedicated hardware.
Prometheus scraping metrics from your fleet, Grafana dashboards, Loki for log aggregation, Alertmanager for paging. The monitoring host should be separate from the things being monitored (otherwise the host going down blinds you to the outage). VPS-2 fits a typical 10-30 host fleet with 30 days of metric retention. VPS-3 for larger fleets or longer retention.
Cold-outreach operations run multiple mailboxes per sender, often 5-10 mailboxes across 3-5 sending domains. Each mailbox sends 30-50 messages per day after warmup. Total volume per VPS sits around 200-500 messages daily, far below sustained sending thresholds. VPS-1 fits the full mailbox stack (Postfix + Dovecot + Rspamd) for one sender; agencies running multiple senders per VPS step up to VPS-2.
Most web apps and API services live comfortably on VPS for their entire lifecycle. Static sites need almost nothing (VPS-1 with nginx serves millions of requests per day). Dynamic apps with PostgreSQL or MongoDB fit VPS-2 or VPS-3 depending on database size. The graduation point to dedicated is when sustained CPU exceeds 60% or when database working set exceeds available RAM.
VPN servers are network-bound, not CPU-bound. WireGuard on a VPS-1 handles 500-1,000 concurrent tunnels at line-rate of the 1 Gbps NIC. OpenVPN sustains lower tunnel counts due to UDP encryption overhead but still comfortably 100-300 concurrent. Multi-jurisdiction VPN providers commonly run a fleet of VPS-1 or VPS-2 nodes across 7-15 locations rather than fewer dedicated boxes.
CI runners, staging clones of production, integration test environments, sandbox accounts for security review. All ephemeral or low-utilisation by nature; VPS economics dominate. The 15-minute provisioning time matches developer iteration speed. Snapshot-and-restore patterns work cleanly for repeatable test environments.
Discord bots, scheduled scrapers, queue workers, cron jobs, webhook receivers, build artifact storage, self-hosted Vault, password managers, Bitwarden, RSS readers, Gitea, internal tools. Each uses very little. VPS-1 fits dozens of these workloads concurrently if isolation requirements are modest, or one per VPS-1 if isolation matters.
Onion services handling moderate traffic fit on VPS without strain. Tor adds latency anyway, so the small virtualisation overhead is invisible to end users. VPS-1 handles a single onion frontend; VPS-2 hosts a small onion-only stack with multiple services. We support EOTK setup as a managed service for sites needing both clearnet and Tor mirror coverage.
Same seven jurisdictions as our dedicated fleet. Same legal frameworks, same transit, same network architecture. VPS sits on KVM hosts in the same datacenters. The jurisdiction selection criteria translate directly: pick for legal exposure, audience geography, and threat model.
| Location | VPS host CPU | VPS-2 stock | Median latency to Gmail | Best for |
|---|---|---|---|---|
| BG Sofia | EPYC 7402P / 7543P | good | 22 ms | Default EU choice, best price-to-jurisdiction ratio |
| RO Bucharest | EPYC 7402P | good | 26 ms | EU, strong network capacity, FlokiNET-tier infrastructure |
| MD Chișinău | EPYC 7402P | moderate | 30 ms | EU-adjacent without EU directives, cost-efficient |
| PA Panama City | EPYC 7402P | moderate | 54 ms | Americas-focused, US legal threat model alignment |
| HK Hong Kong | EPYC 7543P | limited | 24 ms (China) | East Asia operations, China-adjacent latency |
| SG Singapore | EPYC 7543P | good | 22 ms (APAC) | Premium APAC hub, common-law jurisdiction |
| UA Kyiv | EPYC 7402P | good | 30 ms | Cost-sensitive operations comfortable with regional risk |
Stock indications refresh in our internal inventory daily. VPS provisioning is faster than dedicated because we keep host capacity warm; even "moderate" stock typically provisions within 30-60 minutes during business hours. For deep details on each jurisdiction (legal framework, MLAT exposure, transit, datacenter specs), see the location wiki entries.
Every VPS provisions with the same base configuration. No upsells locked behind premium tiers. No "essentials" marked as paid addons.
Full hardware virtualization. Each VPS gets its own kernel, its own device tree, its own memory backed by host page tables. Virtio paravirtualised network and storage drivers achieve near-native performance. Hardware-backed isolation via Intel VT-x or AMD-V.
All VPS storage on local NVMe drives. No spinning disks anywhere in the fleet. Storage mirrored at the host level (RAID-1 across two enterprise NVMe drives), so single-drive failures do not take VPS offline. Disk I/O latency in the single microseconds.
VPS-2, VPS-3, VPS-4 use CPU pinning. Your vCPUs map to specific physical cores; no other tenant schedules work on those cores. VPS-1 uses fair-share scheduling but dedicated cores from VPS-2 onward eliminates the noisy-neighbour CPU problem entirely.
One IPv4 included with custom rDNS aligned to your sending domain. IPv6 /64 routed to your VPS for any IPv6 work. Additional IPv4 €8/month each (some jurisdictions have IPv4 scarcity caps, max 8-16 per VPS depending on location).
Self-service control panel: create snapshots, restore from snapshots, web-based console for OOB access, OS reinstall with template selection, network reset. No ticket required for routine operations.
Default templates: AlmaLinux 9, Debian 12, Ubuntu 24.04 LTS, Rocky Linux 9, FreeBSD 14, Windows Server 2022. Custom ISO mounting via control panel for niche distributions or hardened images you maintain.
L3/L4 DDoS mitigation included on all VPS. Same scrubbing capacity as our dedicated fleet (100-500 Gbps depending on location). Mitigation runs at network edge before traffic reaches your VPS. L7 protection available as €39/month addon.
BTC, Lightning, XMR, ETH, USDT (ERC/TRC/BEP), USDC, Solana, Litecoin, TRON, Bitcoin Cash, Dogecoin, DAI via self-hosted BTCPay. No third-party processors. No identity verification for standard plans. Email only.
Tickets and Telegram conversations route to engineers, not first-tier scripts. Median response 20-45 minutes during operating hours. Same support team that runs the dedicated fleet. We read your ticket, look at your VPS, respond with technical specifics.
VPS hosts run on AMD EPYC platforms across all locations. The standard host configuration is EPYC 7402P or 7543P with 256-512 GB DDR4 ECC RAM, four to eight enterprise NVMe drives in mirrored ZFS pools, and dual 10 Gbps NICs bonded for aggregate throughput. EPYC chosen over Intel for VPS density: 24 to 32 physical cores per socket provides headroom for dedicated CPU pinning across many tenants without overcommit. PCIe 4.0 lane count ensures NVMe drives operate at full bandwidth. ECC throughout protects against single-bit memory errors.
Each host runs Debian 12 or AlmaLinux 9 as the bare-metal OS, with libvirt managing the KVM domains. Storage is ZFS on host-level mirrors; VPS disks are zvols allocated as block devices to each guest with virtio-blk attachment. Network is a single Linux bridge per host with vlan tagging per VPS for tenant isolation; firewall rules enforce per-tenant network policies via nftables. DHCP serves IP allocations to guests at boot via a per-host dnsmasq.
We do not run live migration as a standard operation. Maintenance windows announce 72 hours in advance with shutdown-and-restart on the same host, or shutdown followed by cold-migration to a different host within the same datacenter. Live migration is technically supported by libvirt and we use it for unscheduled host maintenance, but the standard operational model favors brief windowed downtime over the small risk of live-migration anomalies.
Host storage uses enterprise NVMe drives with PLP (power-loss protection): typically Samsung PM983 or Samsung PM9A3, Micron 7300 PRO, or Intel D7-P5520 depending on host generation and stock. Drives rated for 1.0 to 1.3 DWPD endurance run their full lifespans under VPS workloads (the dominant write pattern is relatively sparse compared to dedicated database workloads).
Pools configured as ZFS mirrors (RAID-1 equivalent at ZFS level) for two-drive hosts, or RAID-10 for four+ drive hosts. ZFS provides per-zvol compression (LZ4 by default), per-zvol snapshots used for the customer-facing snapshot feature, and end-to-end checksum verification that catches silent data corruption. Performance overhead from ZFS is small (single-digit percentages on read, slightly higher on write); the checksum guarantee and mature snapshot semantics are worth it.
VPS storage is not network-attached. It sits on local NVMe inside the host. Migration to a different host requires either ZFS send-receive or block-level copy across network. We do not run distributed storage (Ceph, GlusterFS) under VPS; the operational model is local-NVMe with cold migration when needed.
Each VPS gets a virtual NIC backed by virtio-net. Virtio paravirtualisation eliminates most of the syscall overhead of fully-emulated network adapters; throughput approaches 9-10 Gbps on single VPS for hosts with 10 Gbps NICs, with single-microsecond latency added by the virtualisation layer.
IP addresses route to your VPS through host-level forwarding. Our IP pools are independently announced via BGP from each datacenter (we control the address space, no upstream-provider sub-allocation). Each VPS appears with its own dedicated public IPv4 and delegated IPv6 /64. Custom rDNS gets configured at provisioning and changes within 4 hours of any update request.
Bandwidth allocation is enforced at host level, not via per-tenant rate limits. VPS-1 includes 5 TB monthly, VPS-2 10 TB, VPS-3 15 TB, VPS-4 20 TB, all on 1 Gbps uplinks for VPS-1 and VPS-2, 10 Gbps for VPS-3 and VPS-4. After monthly traffic exhaustion, bandwidth throttles to 100 Mbps unmetered rather than incurring surprise overage charges.
Host monitoring runs continuously. Disk SMART metrics polled every 60 seconds; ZFS scrubs run weekly per-pool. CPU thermal monitoring, ECC error tracking, NIC link state, host load averages all reported to our internal Grafana stack. Alarm thresholds trigger investigation before customer-visible degradation.
Customer-facing notifications via Telegram and email. Routine maintenance windows scheduled with 72-hour notice during regional low-traffic periods (typically 02:00-06:00 local). Emergency maintenance for active host hardware failure: customer notification within 15 minutes of action; guests on affected hosts either cold-migrate to backup hosts or restart on the original host after repair, depending on failure severity.
Backup is customer responsibility by default. We do not run automatic backup of VPS contents. Snapshot feature allows customers to take quick local snapshots (stored on host pool) for rollback purposes; for offsite encrypted backup we offer Backup-as-a-Service addon at €19/month for up to 500 GB of data.
KVM is full hardware virtualisation. Each VPS gets its own kernel, its own device tree, its own memory allocation backed by hardware. OpenVZ is container-based: all containers on a host share one Linux kernel and resources are soft-limited at the cgroup layer. KVM provides stronger isolation, runs any operating system including Windows and BSD, supports custom kernel modules, and avoids the noisy-neighbour problem because resources are hardware-allocated. OpenVZ has lower overhead and slightly higher density per host but suffers measurable performance degradation (15-30%) when other tenants on the same host hit peak load. We run KVM exclusively across our VPS fleet.
VPS makes sense when sustained CPU utilisation stays below 50%, working dataset is under ~250 GB, and the workload tolerates the small virtualisation overhead. Helper nodes (MailWizz front-end, monitoring stacks, bounce processors, FBL endpoints, build runners, staging environments, blogs, low-traffic web apps) all fit comfortably within VPS economics. Switch to dedicated when sustained load crosses 60% CPU, when NVMe IOPS becomes the bottleneck, when you need 64+ GB RAM, or when single-tenant attestation matters for compliance.
VPS provisioning is automated and typically completes in 15-30 minutes from confirmed payment. Dedicated takes 4-8 hours because hardware is racked, configured, and verified individually. The trade-off is real: VPS comes online fast but is a slice of shared hardware. Dedicated takes longer to deliver but is exclusively yours.
Yes, with the right architecture. VPS works well as a MailWizz front-end, a PowerMTA helper node, an FBL ingester, a bounce processor, or a transactional sender at low-to-mid volume (up to ~50K daily messages). For high-volume bulk sending (200K+ daily), dedicated bare-metal delivers better PowerMTA queue throughput because virtualisation overhead compounds against you on sustained sending load. The architecture choice is not VPS-or-dedicated but VPS-and-dedicated; helper services on VPS, primary sending node on dedicated.
KVM with virtio drivers (virtio-net, virtio-blk, virtio-scsi) achieves close to bare-metal performance for most workloads: typically 95-98% of bare-metal CPU throughput, 90-95% of NVMe IOPS, and within 1-2 microseconds of bare-metal network latency. The overhead becomes noticeable on extremely I/O-heavy workloads (database servers under sustained random-write load) and on workloads doing many short syscalls. For email infrastructure, web servers, application servers, the overhead is measurement noise.
On VPS-2 and above, vCPUs are pinned to specific physical cores via CPU affinity. Other tenants on the host cannot schedule work on cores that have been allocated to your VPS. VPS-1 uses fair-share scheduling across the host, which means you get your 2 vCPU worth of compute on average but other tenants briefly preempt. The CPU pinning model on VPS-2+ matches what bare-metal customers experience for the cores they get, with a small hypervisor scheduling overhead.
Vertical upgrades (more vCPU, more RAM, more storage) typically require a brief reboot; the VPS reconfigures with the new resources and reboots. Total downtime is 2-5 minutes. Horizontal migration to a different host (different physical hardware) takes 15-30 minutes including data transfer. Cross-jurisdiction migration (BG to SG, for example) is a fresh provisioning rather than a live migration; we cooperate with reasonable migration windows.
Yes to all. KVM gives you a full kernel; you can run Docker without restrictions, deploy a single-node Kubernetes (k3s or microk8s fit well on VPS-2+), load any kernel module you compile, mount FUSE filesystems, run nested virtualisation (KVM-on-KVM is supported but with noticeable overhead). The shared-kernel restrictions of OpenVZ do not apply.
If a host fails completely (motherboard, dual-PSU, or both NVMe drives), affected VPS go offline until the host repairs or until guests cold-migrate to a backup host. Cold migration takes 15-30 minutes plus the host-recovery time. Single-drive failures do not take VPS offline because storage is mirrored at host level. SLA credits apply per the published SLA schedule for downtime exceeding standard targets.
Cancel anytime, no contracts, no penalty. We do not offer prorated refunds for unused portions of the current monthly billing period; if you cancel mid-month, the VPS continues running until the period ends. Annual commitments (10% discount) include a refund for unused full months minus the discount, computed as if monthly billing had been used. We do not offer money-back trials; the entry tier (€19/month) functions as a low-risk evaluation period.
Telegram order takes 5 minutes. VPS provisioned within 15-30 minutes of confirmed payment. SSH credentials, IP, and rDNS delivered with provisioning notification. Cancel anytime, no contracts.
# Median Telegram response: 12 minutes during operating hours