Most backup tools for agencies are SaaS. When I built SiteVault, the app I use to back up client WordPress sites, I went the other way. Here's the reasoning, and what it changed technically.
The credential problem
A backup service needs access to the site: FTP/SFTP for files, database credentials for the dump. In a SaaS model, the provider stores those for every client of every agency using it. That's a high-value target, and as a solo developer I didn't want to be responsible for it.
Self-hosted flips that. Each agency runs its own instance, so the credentials never leave their infrastructure.
How the backups actually run
Instead of pulling everything over FTP from the outside, SiteVault installs a small MU plugin connector on the WordPress site. The connector runs the backup server-side and the app orchestrates it. That makes it faster and more reliable on large sites.
Each run is logged step by step (size, status, duration), and after it completes, the client gets an email report. Email goes through Resend.
Packages instead of manual cron
Backups are scheduled by maintenance package instead of per site: Basic (monthly), Pro (weekly), Agency (daily + monitoring). Each package defines its frequency and how many backups to keep, so retention is handled automatically.
The trade-offs
Self-hosted means the buyer handles hosting and updates. In return, they own the code, can customize it, and pay once instead of monthly.
I'm selling SiteVault with full source code on https://market.designzonic.com/product/sitevault. If you've built something similar, I'd like to hear how you handled backup storage and retention.
Top comments (0)