Search "kinsta backup" and you'll land on two kinds of pages. One says Kinsta backs everything up for you. The other says Kinsta bans backup plugins. Both are true, but neither one tells you whether a backup service that pulls your site over SSH is allowed, and that gap is what this post is about.
Short version: Kinsta's ban is aimed at plugins that run inside WordPress. BackupYourSite isn't one. It connects from outside using the SSH credentials Kinsta hands every site owner. We found nothing in Kinsta's docs or Terms of Service that forbids that, and we also found nothing that explicitly blesses it. We'll show exactly what we read so you can judge for yourself.
How we checked
Our methodology was simple: on 6 November 2026 we read four Kinsta pages in full and wrote down every sentence about backups, plugins, SSH and SFTP. The pages were the banned and incompatible plugins page (last updated 3 June 2026), the SSH page (20 April 2026), the SFTP page (25 March 2026) and the backups page (21 January 2026). We also searched the Terms of Service for any clause on third-party backup tools. We found no such clause, which matters later on.
One caution before the details. A blog post, ours included, is not Kinsta's policy. Kinsta's pages change every few months, as those dates show. Treat what follows as a reading of the docs on one day, not a ruling.
What does Kinsta actually ban?
According to Kinsta's banned plugins page, "Generally speaking, we don't allow caching, backup, or related posts plugins." The reason given for backup plugins is that Kinsta already provides daily automatic backups and downloadable backups, so the plugins aren't needed "in most cases," and they can cause performance problems and use up bandwidth.
The page then names names: All-in-One WP Migration, BackupBuddy, Duplicator Pro, Snapshot, Updraft, WP DB Backup and WP DB Backup Made. BackWPup is a special case. Versions 5.5 and below are banned, while 5.6.0 and above are allowed. A note on the page adds that the list is not exhaustive and that "all non-incremental backups are not allowed."
Read that last line carefully, because it's the one that makes people nervous. It sits under the heading for backup plugins. Every item in the list is a WordPress plugin, installed through wp-admin and executed by PHP on Kinsta's servers. Kinsta's stated worry is PHP load and bandwidth on a platform it tunes tightly. Kinsta also tells you what to use for offsite copies: incremental backup plugins.
Is an SSH backup service a plugin?
No, and the difference is mechanical rather than a matter of branding. A plugin is code that lives in wp-content/plugins, loads on WordPress requests, and schedules its work through WP-Cron. When it backs up, it spends your site's own PHP workers and memory. That's the resource Kinsta is protecting.
BackupYourSite installs nothing inside WordPress for the backup itself. Our team's service logs in over SSH, copies the site files, dumps the database and stores the copy offsite. The work happens in a shell session, not in a PHP request. If you want the nightly sequence step by step, see how BackupYourSite works.
Here's the honest part. "Not a plugin" is a reasoned distinction, not a written exemption. Kinsta could, in theory, say tomorrow that heavy full-site pulls over SFTP are a problem too. So far we haven't seen it say that.
What Kinsta gives you for access
Kinsta's own pages are clear that SSH and SFTP are part of the product on every plan. According to the SSH page, "SSH access is included with all Managed WordPress Hosting plans," and you can run Git, Composer and WP-CLI over it. The SFTP page goes further. It lists "Back up your site" among the things you can do once connected, next to uploading files and fixing errors.
A few details shape how a backup tool has to behave on Kinsta:
- One SSH user. Kinsta says you cannot create additional users to connect via SSH. You can add extra SFTP users, but SSH goes through the primary SFTP/SSH user only.
- A different port per environment. Live and staging each get their own, shown in MyKinsta under Sites, then your site, then Info.
- A cap of 10 simultaneous SFTP transfers. A backup tool that opens dozens of parallel connections will hit that ceiling.
- Optional password expiry and an IP allowlist on the primary user. Both are good security settings. Both will also stop a scheduled backup cold if you forget about them.
That last pair is where we've seen real trouble in the field. A password that expires every 90 days will quietly break a job that nobody watches. If you turn expiry on, put a reminder in the calendar. If you use the allowlist, add the backup service's address, or the nightly run will fail at login.
Does Kinsta's own backup cover you?
Partly. Kinsta takes a daily automatic backup, offers an hourly add-on, and keeps up to 5 manual backups. It also creates system backups before things like a theme or plugin update, a restore, or a push from staging to live. That's a solid safety net for "I broke my site this afternoon."
The detail that changes the picture is where those backups live. Per the backups page, each one "is stored on the same host machine as your site." That's fine for undoing a bad update. It's not an offsite copy. If the account is suspended, the machine fails, or someone with access deletes the site, the backups sitting beside it are in the same blast radius.
Kinsta does sell an answer to this. The external backups add-on can send weekly or monthly copies to Amazon S3 or Google Cloud Storage. That's useful evidence that Kinsta isn't against offsite copies in principle. It does come at an extra cost and a coarser schedule than daily. For a store taking orders every hour, a weekly external copy leaves a long gap. We covered the general test for this in offsite backup: the five questions that separate real ones.
Why the plugin route is worse on Kinsta anyway
Even where a backup plugin is allowed, it inherits the usual weaknesses. It depends on WP-Cron, and Kinsta sites often run with a server-level cron setup that plugin schedules don't always match. We wrote up the failure pattern in why WordPress backup plugins fail. A plugin also dies with the site it's protecting. If wp-admin is broken or the site is hacked, the backup tool lives in the same broken place.
A pull from outside doesn't have that problem. The site can be down and the last good copy is already somewhere else. For the wider picture of what hosts do and don't cover, see does my web host back up my site.
Per the WordPress developer documentation at developer.wordpress.org, a complete backup has to include both the database and the files, and the backup should be stored away from the site itself. That's the standard we hold ourselves to on Kinsta. And per the OWASP access control guidance, a credential should reach no more than the job needs. On Kinsta that's awkward, because the primary SSH user has full access to every file on the site. Use a long, unique password or an SSH key, keep the credential out of shared documents, and rotate it when staff leave.
Live, staging and the second backup you forget about
Kinsta gives each site separate environments, and each one has its own SFTP/SSH details, including its own port. That has a practical consequence for backups that people tend to miss until it bites them. Pushing staging to live generates a fresh SSH key fingerprint on the server, and Kinsta's SSH page warns this can trigger the "REMOTE HOST IDENTIFICATION HAS CHANGED" error on any client that has the old fingerprint stored. A person sees that message and clears the known-hosts entry. A scheduled job just fails, and if nobody is reading the logs, the next several nights go uncaptured.
So after any push from staging to live, check that the next backup run connects. It's a thirty-second check, and it protects you from the exact moment you're most likely to need a restore point, right after a big change went out.
What a restore looks like from an offsite copy
Kinsta's one-click restore is quick, and for a bad plugin update it's the right tool. It rolls back files, database, redirects, Nginx configuration and MyKinsta settings together, domains included. That last part has a catch. Restoring to a point before a custom domain was added removes the domain from the site, and you have to add it again.
An offsite copy plays a different role. You reach for it when the Kinsta-side backups aren't available or aren't trustworthy: the site was deleted, the account was locked during a billing dispute, or malware sat in the files long enough that every recent snapshot contains it. In those cases you rebuild from files and a database dump, which is a slower job but one that doesn't depend on Kinsta's tooling being in your corner. We went through the drill for that scenario in the restore drill nobody runs until it's 2 a.m., and it's worth reading before you need it.
Agencies feel this more than single-site owners. Run twenty client sites on Kinsta and your whole backup story rests on one vendor's dashboard. If a staff member with access leaves on bad terms, or a single account takes a hit, every client's only backups are in the same place as their sites. Keeping a separate copy under your own control is cheap next to explaining a lost site to a client.
How to run this on Kinsta without annoying Kinsta
None of this is a guarantee. It's how we'd set it up if the site were ours:
- Schedule the pull for the quietest hours of your traffic, not midday.
- Keep the connection count low, well under the 10-transfer cap.
- Use SSH key authentication where you can, so a password expiry can't silently break the job.
- Check the first two runs by hand. Compare file counts and open the database dump to confirm it's complete.
- Do a restore test on a staging site before you need one. Backups you've never restored are a hope, not a plan.
If you want certainty rather than our reading, ask Kinsta support one direct question: "Is it acceptable to pull a nightly backup over SFTP/SSH using my primary user, from an outside service?" Keep the reply. A written yes beats a blog post, including this one.
Frequently Asked Questions
Does Kinsta ban backup plugins?
Yes, many of them. Kinsta's banned plugins page says it generally doesn't allow backup plugins and names All-in-One WP Migration, BackupBuddy, Duplicator Pro, Snapshot, Updraft and others. BackWPup 5.6.0 and above is allowed.
Is BackupYourSite a WordPress plugin?
No. It connects to your server over SSH from outside and does not run inside WordPress's PHP process. The backup itself needs no plugin on your site.
Does Kinsta allow SSH access?
Yes. According to Kinsta's SSH page, access is included on all Managed WordPress Hosting plans. Connection details are in MyKinsta under Sites, your site, Info, in the primary SFTP/SSH user panel.
Can I add a separate SSH user just for backups?
No. Kinsta says additional users can connect via SFTP but not SSH. Backup tools that need SSH use the primary SFTP/SSH user, so protect that credential carefully.
Where does Kinsta store its own backups?
On the same host machine as your site, according to Kinsta's backups page. That makes them good for rollbacks but not a replacement for an offsite copy.
Can an outside backup service get my Kinsta account flagged?
We found no rule against it in Kinsta's docs or Terms of Service, but we can't promise how Kinsta will treat it. Ask Kinsta support in writing if you need a firm answer.
What breaks a scheduled SSH backup on Kinsta most often?
An expired primary-user password or an IP allowlist that doesn't include the backup service. Both are optional Kinsta security settings that can stop a nightly job without any visible error.
Ready to see how this fits your stack? Read the BackupYourSite features and check the connection requirements against your Kinsta plan.