A client running more than 20 web applications had infrastructure scattered across 7 machines at two different providers: several apps on 5 hosting VMs in Romania and two more on two dedicated servers rented at Hetzner. Duplicate costs, inconsistent security and zero unified visibility. We consolidated everything onto a single new Debian server with KVM virtualization — with a real security perimeter and 24/7 monitoring. Implemented in April 2025, at Hetzner, on Debian 12 (Bookworm), on a dual-CPU server with 128 GB RAM.
The context
The client's infrastructure had grown organically, without a unified plan:
- 5 VMs at a Romanian hosting provider, running most of the 20+ web apps
- 2 dedicated servers rented at Hetzner, each with its own apps and configuration
- Two providers, two bills, two different administration models
- Security in pieces — each machine with its own rules (or none), no single control point
- No central monitoring: a problem on an app was found when the client called, not before
The business risk wasn't a single app going down, but the lack of control and visibility over everything running in production.
The challenge
We had to consolidate everything without rewriting the applications and without long downtime, keeping workloads isolated — the old apps must not affect each other. On top of that, the client wanted lower costs and a single point of administration, with no compromise on security.
The proposed solution
After technical discussions with the client, the decision was clear: a single new, more powerful physical server at Hetzner, turned into a virtualization host. On it we built a KVM environment with three virtual machines, each with a well-defined role:
- Debian Linux host — the base system, hardened and turned into a security perimeter and single entry point
- KVM as hypervisor — real isolation between workloads, snapshots, flexible resource allocation
- 3 VMs — two for the two old dedicated servers, one for all the apps from the 5 Romanian VMs
Why KVM and not Proxmox or VMware
We wanted a single lean server doing both virtualization and the security perimeter — nginx, Suricata and GeoIP all run on the same Debian host. KVM is the native Linux hypervisor: zero licensing, full control, direct integration with the host, no extra management layer. Proxmox or VMware would have added needless complexity here — and real HA on just two Proxmox nodes is problematic: a cluster needs a third vote for quorum, otherwise you risk split-brain. For a single host with fast recovery onto a standby server, Debian + KVM was the right choice.
In short, the transformation:
The implementation
Step 1 — Debian host + KVM
On the new server we installed Debian Linux as the host system, hardened to best practices (minimal services, key-based SSH, nftables firewall, kernel tuning). On top of it, KVM/QEMU + libvirt as the virtualization layer. This way each app or group of apps runs isolated in its own VM, unable to affect the rest.
Step 2 — Migrating the two dedicated servers (image-level)
The two old physical dedicated servers at Hetzner were migrated at image level (P2V — physical to virtual), each into its own VM on the new host. We took the entire server — operating system, configuration, applications — exactly as it was, with no reinstall and no manual reconfiguration. The apps started in the VM identical to the old environment.
Step 3 — Consolidating the 5 Romanian VMs
The 20+ web apps spread across the 5 hosting VMs in Romania were migrated into a single VM on the new server. We grouped the apps, rebuilt the dependencies (runtimes and databases as needed) and validated each app before shutting down the old environment.
Security — the host as the perimeter
All traffic now enters through a single controlled point, on the host, before it reaches any application. This let us build a real security perimeter, identical for all 20+ apps:
- nginx as reverse proxy — single entry point for all apps across the 3 VMs. Centralized TLS termination, certificates managed in one place, per-domain/app routing, consistent rate limiting and security headers. The apps inside the VMs are not exposed directly to the internet.
- GeoIP filtering — country-level filtering directly on the host. We shrink the attack surface by blocking regions where the client has no legitimate users but where most automated scans and attacks come from.
- Suricata IDS/IPS — deep packet inspection on the host, with up-to-date rule sets. It detects and blocks exploit attempts (SQLi, scans, known payloads) before they reach the apps in the VMs. Every alert is logged and forwarded to monitoring.
- CrowdSec — behavioral detection of attacks (brute-force, scans, abuse) and signal-based blocking, including shared community blocklists
- ipset with dynamic lists — very fast kernel-level blocking of large IP lists that update dynamically (CrowdSec decisions, threat feeds, IP reputation) — attackers are cut off at the gate, before they reach the apps
- NetFlow — practically every connection through the server is logged at flow level: who talked to whom, how much traffic, when. Full visibility for investigations and audit
The result: instead of 7 machines with different (or non-existent) rules, a single consistent perimeter that everything passes through.
Monitoring and alerting — Zabbix
Without visibility, consolidation would just move the problem. We deployed Zabbix as the central monitoring and alerting system, with agents on the host and all 3 VMs:
- Infrastructure — CPU, RAM, disk, I/O and the state of each KVM VM on the host; alerts before a resource becomes critical (e.g. disk over 80%)
- Applications — HTTP/HTTPS checks on each web app (response code, response time, TLS certificate expiry), so we know it's down before the client calls
- Security — Suricata alerts and nginx events flow into Zabbix, correlated with the rest of the metrics
- Backup — backup job status, so a failed backup raises an alert, not a surprise at restore time
- Alerting with escalation — email notifications, with thresholds and severities, plus dashboards for a real-time overview
Availability and image-level backup
Consolidating onto a single physical server means that server becomes critical — so backup was part of the design, not an afterthought. We use an enterprise image-level backup solution: each VM is saved in full (complete image + incrementals), on a second server rented separately by the client, in a different physical location.
The advantage over a classic file backup: when needed, we restore the entire VM in minutes — system, configuration, apps, data — ready to boot, not reassembled by hand. RTO drops from hours to minutes, and the physically separate copy follows the 3-2-1 principle.
This is not an HA cluster with automatic failover — it was a deliberate cost decision. The backup server is not just a copy target: when needed, the 3 VMs can be booted directly on it within minutes (warm standby), because they are saved as full, boot-ready images. We get a minutes-level RTO at a fraction of the cost and complexity of a real HA cluster. If the business needs sub-minute automatic failover, the natural next step is a 2-3 node cluster with replication — but for this client's volume and budget, fast, tested recovery was the right balance.
The result
- ✅ From 7 machines at two providers to a single server with 3 VMs — one administration, one main bill
- ✅ 20+ web apps migrated without rewriting, with real isolation between workloads (KVM)
- ✅ The two dedicated servers taken over at image level — zero manual reconfiguration
- ✅ A single security perimeter: nginx reverse proxy + GeoIP + Suricata IDS/IPS on the host, identical for all apps
- ✅ Full 24/7 visibility with Zabbix — alerts before the incident, not after
- ✅ Image-level backup on a separate server — full restore in minutes, copy in another physical location
- ✅ Lower costs and infrastructure handed over fully documented
Do you have apps scattered across multiple servers?
If you're paying bills at several providers for apps spread across different machines, with no shared security perimeter and no unified monitoring, you're probably paying more for less control. We do audits and consolidation plans: what can be merged, how to isolate workloads, what security perimeter to put in place and how to monitor everything from one place.