Managed hosting
How we keep the sites we host online, and how we get them back if something goes wrong.
Two companies
The primary server in Atlanta serves all traffic. An identical standby in San Francisco serves none until it is needed, built from the same automation.
Using two different hosting companies matters. A provider-wide outage, a billing problem, or a company acquisition affects one server, never both.
Two power grids
Atlanta sits on the Eastern Interconnection power grid; San Francisco on the Western. These are physically separate electrical systems. The 2003 Northeast blackout took out 50 million people across eight states and Ontario from a single Ohio equipment failure. A grid event on that scale cannot reach both of these machines.
One encrypted tunnel
The two servers talk over WireGuard, a modern encrypted VPN. Database replication and file synchronization travel inside that tunnel. Nothing sensitive crosses the public internet unencrypted, and no database port is exposed to the outside world.
Databases replicate continuously. A change on the
primary appears on the standby in seconds.
Files sync nightly, one direction only, primary to
standby. Never bidirectional, so the standby can never overwrite
live data.
TLS certificates sync automatically, so the standby
always holds valid, current certificates. A failover produces no
browser security warnings.
Redundancy and backup solve different problems, and conflating them is a common mistake. Replication faithfully copies a mistake or a compromise to the second server within seconds. It protects against hardware failure, not against damage.
Backups run nightly to a third company in a third location, encrypted before they leave the server. Recovery is possible from any point in the last six months.
Restores are tested, not assumed. A full restore of archived data onto a different server at a different provider has been verified byte-for-byte.
Every configuration detail lives in version-controlled automation. Nothing is configured by hand and forgotten.
This means a replacement server can be rebuilt from nothing in minutes rather than reconstructed from memory. It also means both servers are genuinely identical, rather than two machines that drifted apart over years of small undocumented changes.
The pair has been failed over to the standby and back again as a live exercise. Both servers took the primary role, served real traffic, and returned. The procedure is written down and proven.
An untested failover plan is a hope. This one is a rehearsal.
Every scheduled job reports in when it succeeds. If a report does not arrive on time, an alert fires.
That distinction matters: a server that has failed completely cannot send an error message. Watching for missing check-ins catches the failures that watching for errors would miss.
Each hosted site runs as its own system user, in its own process pool, restricted to its own directory. One compromised site cannot read another site's configuration, database credentials, or files.
Shared hosting traditionally runs every site as the same user, which means a single vulnerable plugin on any site exposes all of them. This does not.
Questions?
Get in touch or call 814-538-9194 and we'll give you a straight answer.
Macpherson