People usually come to us in one of two situations. Either you have one or two important sites on shared hosting and they’ve outgrown it: the site slows down at peak hours, the limits are vague, and when something breaks, support answers with a template. Or you run a web agency with dozens of client sites scattered across different hosts and VPSes, and nobody can say for sure which PHP version runs where or when the last backup was taken.

The pain is the same either way. One compromised site drags its neighbours down. A plugin update takes the homepage offline on a Friday evening. Contact form emails land in spam. And the backup exists, but nobody has ever tried restoring from it.

What we do

We build the platform on a dedicated server (OVH or Hetzner) or on a VM in your Proxmox cluster, and get it to the point where the sites simply run.

  • Nginx + PHP-FPM. Every site gets its own system user and its own PHP-FPM pool. A site can’t read its neighbour’s files, and a heavy site can’t eat all the workers. Several PHP versions run side by side, so an old site on 7.4 doesn’t hold back the new ones on 8.3.
  • Caching. OPcache, Nginx FastCGI cache for anonymous visitors, Redis object cache where the plugins support it.
  • Databases. MariaDB with a separate user per site and no outside access.
  • TLS. Let’s Encrypt certificates issued and renewed automatically, with expiry monitoring.
  • Hardening. Rate limits on wp-login.php and xmlrpc.php (or xmlrpc blocked entirely if nothing needs it), CrowdSec or fail2ban watching Nginx and SSH logs, and a WAF in front of the sites when it’s warranted.
  • Email. Sites send through a proper SMTP relay with SPF, DKIM and DMARC, not bare mail() from an unsigned address.
  • Backups and monitoring. Daily copies of files and databases to separate storage, uptime and certificate checks for every site, alerts via Telegram or email.

Control panel or plain configuration

There are two ways to run this, and neither wins on every point.

A panel like HestiaCP suits agencies. Someone on your team can create a site, a mailbox or a database for a new client without filing a ticket with the admin. We run some of our own sites on HestiaCP. But a panel is one more thing to patch and watch for vulnerabilities. It also has its own ideas about where configs live, so manual changes made alongside it can vanish after an upgrade.

Plain configuration with Ansible fits when there are only a few sites, or they matter a lot and rarely change. Everything lives in a repository: vhosts, PHP pools, users, cron jobs. The server can be rebuilt from scratch, and every change is in the Git history. The catch is that adding a site takes someone who can run a playbook.

We often go hybrid: the panel for the agency’s day-to-day work, while the base system, hardening, monitoring and backups are managed with Ansible outside it.

A side note on package sources. Newer PHP versions on Debian usually come from a third-party repository, and its signing key expires now and then. When that happens, apt update quietly stops delivering security fixes. We catch that with monitoring, not by accident six months later.

Updates: plugins break sites, servers rarely do

In practice the server is rarely what fails. Sites break after a plugin, theme or core update. That’s why blind auto-updates are a bad idea — and manual ones keep getting postponed.

Our approach: the site is cloned to staging, updates run there, then an automated check hits the homepage, a few key URLs, the cart or a form, and scans the log for PHP errors. If everything passes, the same updates go to production. If not, production stays untouched and you get a report of what broke.

wp core update --minor
wp plugin update --all --exclude=woocommerce
wp core verify-checksums
curl -fsS -o /dev/null -w '%{http_code}\n' https://staging.example/

Major releases, WooCommerce and licensed premium plugins are updated by hand, with notice. Joomla follows the same idea with different tools.

When this doesn’t work: if a site has been heavily edited live and no copy behaves like the original, the code needs cleaning up first. That’s a separate job.

Backups and migration

A backup nobody has restored from is a hope, not a backup. So we periodically restore a site from backup into an isolated environment and check that it loads and the database is intact.

Moving off shared hosting happens without downtime: we copy files and the database, test the site on the new server via a hosts override, lower DNS TTLs in advance, sync the final changes and switch the records. If email lived on the same host, we move it separately, history included.

What you get

  • A server that’s fully yours: root access, plus panel access if there is one.
  • Isolated sites with their own users, PHP pools and databases.
  • Updates through staging, with a report after each cycle.
  • Protected logins, xmlrpc and SSH, and certificates that renew themselves.
  • SPF, DKIM and DMARC set up, so site email actually arrives.
  • Backups on separate storage with regular restore tests.
  • Uptime monitoring with alerts that reach you too.
  • Documentation: what runs where, how to add a site, how to restore from backup.

Whether it’s one site that has outgrown shared hosting or an agency juggling dozens of clients across a zoo of servers, write to us with how many sites you have and where they live now. We’ll take a look and suggest how to bring it all under one roof.