Your WordPress sites stay up.
Even when your server doesn't.

No — as long as both your servers meet the requirements listed on this page, your hosting stays exactly as-is. Your current server becomes the Primary; a second matching server becomes the Standby.

Tergum checks health every 30 seconds. After 2 consecutive failed checks (~1 minute), promotion begins. DNS updates via Cloudflare propagate within seconds for most visitors. Total time from failure to traffic on Standby: typically under 2 minutes.

Set your policy to Manual. Tergum will alert you immediately when promotion conditions are detected — Primary down, Standby ready — and wait for you to approve from the dashboard. It won't act without you.

No. Tergum uses Tailscale for secure networking between your servers, so they can be in different data centres, different countries, or different providers entirely. The only requirement is that both connect to the internet.

No — the server pair is the unit of failover. When your Primary server goes down, every domain on that pair promotes to the Standby together. There’s no per-domain failover. This is worth considering when deciding which sites to host on the same server pair — sites that you’d always want to fail over in unison are natural candidates to share a pair.

Yes — and this is where Tergum's promotion model really shines. When your Primary fails, the Standby is promoted to Primary: it keeps accepting orders, processing checkouts, and writing to the database. Your WooCommerce store never stops. When your original server comes back and resyncs, every order placed during the outage is already there on the promoted Standby server — nothing is lost.

The only caveat: any transaction that was literally in-flight at the exact moment of failure (mid-commit, before replication could stream it) may not appear. For most stores this is negligible — the replication lag is typically under a second.

Tergum detects the heartbeat returning and immediately alerts you: "Your original server is back online — but your site is still running on the promoted Standby." The original is stale at this point; it missed every write that went to the promoted server during the outage.

From your Tergum dashboard you click Resync. Tergum then handles everything:

• clones the current database from the promoted Primary to the original server
• configures replication so the original starts following the promoted server, and waits for it to catch up

Once fully in sync, an Initiate Failback button appears if you want to swap roles back — or you can simply leave the promoted server as Primary permanently. Either way, not a byte of data is lost.

For content-only sites (blogs, brochures — nothing transactional), you can enable auto-revert: Tergum handles the entire recovery automatically. When the original server comes back online, Tergum immediately resyncs the database from the promoted server to the original, monitors replication lag, and only flips DNS back once the original is fully caught up. The result is a true return to the initial state — no human involvement, no divergence, no stale data. You'll get a notification when it's done.

For transactional sites (eCommerce, membership, contact forms) — three reasons, all in your interest:

Safety. Automatically starting a full database clone on a server the moment it comes back online — without a human confirming it's stable — is risky. A recovered server that crashes again mid-resync leaves replication in a broken state. A 30-second confirmation window costs you nothing and protects you from that scenario.

Technical necessity. The recovered server can't just "pick up where it left off." Its binary log position is out of date and its data is stale. A full clone from the promoted Primary is required to re-establish a clean replication baseline — that's not something that can happen silently in the background.

Your data, your call. For eCommerce sites especially, you may want to review what happened during the outage — orders taken, inventory changes — before committing to the resync. The promoted server is your live database. We'd rather you confirm you're ready than have us automatically overwrite the original without your say-so.

One thing worth keeping in mind: Resync operates at the server level. All domains on the pair are affected simultaneously — you can't selectively resync just one site.

In practice the manual step is a single button click. Tergum does all the heavy lifting from there.

Tergum supports MySQL 5.7+, MySQL 8.0+, and MariaDB 10.4+. Primary and Standby must run the same database type and be within one major version of each other. Tergum validates compatibility before completing setup.

Tergum supports Nginx, Apache, LiteSpeed Enterprise, and OpenLiteSpeed on Ubuntu/Debian. Nginx + Apache reverse-proxy stacks (where Nginx handles incoming traffic and proxies to Apache on a non-standard port) are also supported — common in some panel-managed setups.

Primary and Standby must use the same web server. LiteSpeed and OpenLiteSpeed are cross-compatible with each other since both use .htaccess for routing. Tergum detects your stack automatically and validates compatibility before completing setup.

Two notes on auto-install limitations: if your Primary runs LiteSpeed, install it on the Standby first (LiteSpeed Enterprise requires a license key; OpenLiteSpeed is free and installs in minutes). If your Primary uses a Nginx + Apache reverse-proxy stack, install both Nginx and Apache on the Standby first. In both cases, as long as the software is already present when you run the Tergum installer, setup proceeds exactly as normal — Tergum detects what’s installed, validates compatibility, and handles all configuration and syncing from there.

We think you should know exactly what runs on your servers before you sign up. Tergum makes three categories of changes:

Tergum infrastructure — files and services Tergum owns and removes when you cancel: the agent binary, file-sync watcher, and emergency recovery endpoint. These exist solely to support Tergum's operation and have zero impact on your WordPress site.

Required setup changes — changes to your server that are necessary for replication to work: a MySQL replication user (tergum_repl), binary logging configuration, an SSH key for file sync, an inotify kernel parameter, and MySQL read-only mode on the Standby. These are shown to you verbatim in the setup wizard and require your explicit acknowledgement before setup proceeds. They're also enumerated in our Terms of Service.

Optional site operation changes — enhancements like wp-cron management or per-domain web server logging that you opt into through the dashboard. These require your explicit consent, are reversible, and you'll receive an email when they're applied.

Every automated change is logged in your dashboard's Activity Log so you always know what Tergum has done on your servers.

Your subscription runs to the end of the billing period, then Tergum monitoring stops and the agent is cleanly removed from your servers.

What gets removed: the Tergum agent, the file-sync watcher, and the emergency recovery endpoint — everything that requires our backend to function.

What stays: MySQL replication (your Standby keeps syncing), Cloudflare Tunnel (your CF account, your tunnel), Tailscale (your network), and your SSH keys. Your servers keep running exactly as before — you just lose the automatic promotion, monitoring, and DNS-failover layer. If you re-subscribe, protection is restored immediately with no re-setup required.

If you want a completely clean slate, our documentation includes step-by-step instructions for removing MySQL replication and any other Tergum-configured infrastructure at your own pace.

Tergum agents send health metrics (disk usage, CPU, replication status, etc.) to our backend for monitoring. We never read or store your WordPress content, customer data, or database contents. Your data stays on your servers. See our Privacy Policy for full details.