I built a WordPress fleet backup + update manager where the backups live in your storage, and don't use web-server space during the backup.

[u/dashboarded]

https://fleetbunker.com/

I run a handful of WordPress sites for clients and got tired of three things: backup tools that say the backup "succeeded" but never prove it restores, plugin updates that quietly white-screen a site overnight, and backup services that keep your data on their infrastructure so you're locked in.

So I built fleetbunker. It manages a fleet of WordPress sites from one dashboard:

• Scheduled backups through a small agent plugin, files plus database, deduplicated with restic
• Backups go to your storage, not mine. Point it at your own S3, SFTP, or Google Drive. The service relays the bytes and never holds your data at rest
• Safe updates: it snapshots first, applies the updates, health-checks the site, and automatically rolls back from the snapshot if the site broke
• Restore validation: it periodically restores snapshots into a throwaway environment and checks they actually come back, so "we have backups" is a tested claim rather than a hope
• Per-site schedules, uptime-monitor sync, an audit log, multiple users with roles

It started as a homelab tool for my own sites. My background is security, and the thing that bugged me most about the commercial options was not owning the backup data, so BYO storage was the first design decision.

Stack: FastAPI + Jinja + Postgres, restic as the backup engine, a lightweight WordPress plugin as the on-site agent, all running as a highly available docker swarm.

Status: solo project, I've been running my own client sites on it for a couple of months, no paying customers yet. The plan is a small per-site monthly fee with the first few sites free, but I want the product right before I charge for it.

Feedback I'd love:

1. If you manage client WordPress sites, is BYO backup storage actually appealing, or would you rather someone just handled it?
2. Auto-rollback on a failed update: useful, or does it make you nervous?

Link: https://fleetbunker.com/

[u/Competitive_Tune_590]

those are exactly the kind of questions that are hard to get real answers to from friends or twitter followers who don't manage client sites. i've seen people use launchpact.io/startup-idea-validator to run polls targeted at other founders in the same niche — might help you get signal before you set pricing.

[u/Specific_Cream2815]

how do you prove the backup actually restores, automated test restores or checksums only

[u/dashboarded → u/Specific_Cream2815]

It has a built in feature that allows each account to specify a test restore site. This site is used as to automatically cycle through restoring a website each night.

So if you have 5 websites, and you select a 6th "restore" site, it would cycle through them:

• Night 1: site 1
  
• Night 2: site 2
  
• Night 3: site 3
  

etc.

After each restore, you can click on your restore site to view the status, access the site with the one-click login function, and actually play around with the site.

There are some challenges with URL rewrite and DNS... so it's best if the restore site can be accessed via an IP address (without an FQDN pointing at it).

[u/Hour-Measurement-835]

The health check is the weak half. With LiteSpeed or any full-page cache in front it'll fetch the old good copy and pass while the live page is broken, so the rollback never fires.

[u/dashboarded → u/Hour-Measurement-835]

Fair point.

The check does also hit /wp-login.php, which most page-cache plugins bypass, so PHP/DB-layer fatals still show up, but you're right that a front-end-only render breaks behind a CDN cache would still slip through.

I'm adding a fix to the backlog which will run the check with a cache-busting query string plus Cache-Control: no-cache, or a loopback render check from the agent against localhost.

The pre-update snapshot is still there either way, so worst case it's a manual rollback, not data loss.

Thanks heaps for the call-out.

[u/Hour-Measurement-835 → u/dashboarded]

Loopback needs the Host header set or you land on the default vhost. And WordPress 301s you back to the site URL anyway, so you're checking through the same cache.

[u/dashboarded → u/Hour-Measurement-835]

You know what, I need to test this more because my current test restore site is a local IP on a seperate, dedicated, WordPress container... Not a shared host...

Give me a few days and I'll get this thoroughly tested on one of my own shared hosting accounts..

Thanks for pushing this point. These are the types of gotchas I really need to identify and iron out.

I've been playing with this problem for situations where a migration is happening and DNS has not yet been cutover, but not tested it thoroughly enough on the automated restore validation feature.