Setting Up S3-Compatible Cloud StoragePRO
Connect Amazon S3, DigitalOcean Spaces, Cloudflare R2, Backblaze B2, Wasabi, or a self-hosted MinIO server as your SiteVault Pro cloud backup destination. Each provider needs the same five pieces of information, a bucket, an endpoint, a region, an access key, and a secret, but the exact values differ per provider. This guide walks through each one.
An account with the cloud provider you want to use, and the ability to create a bucket in that provider’s console. SiteVault does not create the bucket for you, make it in the provider’s UI first, then paste the bucket name into the SiteVault modal.
Which SiteVault modal to use
SiteVault Pro has two entry points for S3-flavored cloud storage on the SiteVault > Cloud Storage page, under the Bring Your Own Credentials group:
Amazon S3
Use when your bucket lives in an actual AWS account. Region is a dropdown of standard AWS regions. Endpoint is filled in automatically from the region.
S3-Compatible
Use for DigitalOcean Spaces, Cloudflare R2, Backblaze B2, Wasabi, or MinIO. Adds an Endpoint field so you can point SiteVault at any provider that speaks the S3 API.
Click Connect on either card to open the setup modal. Both modals expose a Test Connection button next to Save Provider, so you can verify credentials before saving.
Amazon S3
Create the bucket + IAM key in AWS
Create an S3 bucket
In the AWS console, open S3 > Create bucket. Pick a globally unique bucket name (for example mysite-sitevault-backups), choose an AWS region close to your site, and leave the default settings (block all public access = on). Click Create.
Create a dedicated IAM user
In the AWS console open IAM > Users > Add user. Give it a name like sitevault-backups and select Programmatic access. Skip the Console access option.
Attach a bucket-scoped policy
Attach an inline policy allowing s3:ListBucket, s3:GetObject, s3:PutObject, and s3:DeleteObject against just the bucket you created. Scoping to the bucket keeps the key from touching anything else in your AWS account if it’s ever compromised.
Save the Access Key ID + Secret
AWS shows the Access Key ID and Secret Access Key exactly once. Copy both into a secure place. If you lose the Secret you’ll need to generate a new one.
Fill in the SiteVault Amazon S3 modal
- Name. Friendly label, shown in the Connected Providers table. Example:
My Backup Storage. - Access Key ID. From the IAM user you just created.
- Secret Access Key. From the IAM user.
- Bucket Name. The exact bucket name you created (must already exist).
- Region. The AWS region you picked when creating the bucket. Choose from the dropdown.
- Path Prefix. Optional folder inside the bucket where backups are stored. Default:
sitevault/. Change it if you use one bucket for multiple sites and want to keep them separated.
Click Test Connection. On success, click Save Provider. The new provider appears in the Connected Providers table below.
DigitalOcean Spaces
Create the Space + Spaces Key in DigitalOcean
Create a Space
In the DigitalOcean control panel, open Spaces Object Storage > Create Space. Pick a datacenter region (NYC3, SFO3, AMS3, FRA1, or SGP1), enable CDN if you want, and give the Space a unique name.
Generate a Spaces access key
Go to API > Spaces Keys in the DO control panel. Click Generate New Key and name it (for example sitevault-backups). DO shows the Key (access key ID) and Secret exactly once. Copy both.
Fill in the SiteVault S3-Compatible modal
Under Bring Your Own Credentials, click Connect on the S3-Compatible card.
- Name. Friendly label. Example:
DO Spaces Backups. - Endpoint. The datacenter hostname without
https://. Examples:nyc3.digitaloceanspaces.com,sfo3.digitaloceanspaces.com,ams3.digitaloceanspaces.com,fra1.digitaloceanspaces.com,sgp1.digitaloceanspaces.com. Do not include the bucket name. - Access Key ID. The Key from DigitalOcean’s Spaces Keys page.
- Secret Access Key. The Secret from the same page.
- Bucket Name. The Space name you created.
- Region. The datacenter code (
nyc3,sfo3,ams3,fra1, orsgp1), match the datacenter your Space is in. - Path Prefix. Optional. Default
sitevault/.
Click Test Connection, then Save Provider.
Cloudflare R2
Cloudflare R2 has no egress fees on downloads to Cloudflare’s network and cheap egress everywhere else, a good fit for offsite backups you rarely restore from but want to keep long-term.
Create the R2 bucket + API token in Cloudflare
Enable R2 and create a bucket
In the Cloudflare dashboard, open R2 Object Storage > Create bucket. Pick a bucket name and a location (either Automatic or a specific region hint).
Note your Account ID
Cloudflare’s R2 endpoint includes your account ID in the hostname. Find it under R2 > Overview > Account details. It looks like a 32-character hex string.
Create an R2 API token
Under R2 > Manage R2 API Tokens > Create API Token. Give it a name, choose Object Read & Write permission, and scope it to just the bucket you created. Cloudflare shows the Access Key ID and Secret Access Key exactly once. Copy both.
Fill in the SiteVault S3-Compatible modal
- Name. Friendly label. Example:
Cloudflare R2 Backups. - Endpoint,
<your-account-id>.r2.cloudflarestorage.com. Replace<your-account-id>with the hex account ID from Cloudflare. Nohttps://, no bucket name. - Access Key ID. From the R2 API token you created.
- Secret Access Key. From the same token.
- Bucket Name. The R2 bucket name.
- Region,
auto. Cloudflare R2 uses a virtual region calledauto; do not use an AWS-style region code here. - Path Prefix. Optional. Default
sitevault/.
Click Test Connection, then Save Provider.
Backblaze B2
B2 is typically the lowest per-gigabyte storage cost of the S3-compatible providers, which makes it attractive if you have a lot of backup history to retain.
Create the bucket + Application Key in Backblaze
Create a B2 bucket
In the Backblaze console, open B2 Cloud Storage > Buckets > Create a Bucket. Give it a unique name and choose Private for the visibility. Save.
Note the S3 endpoint for your bucket
On the bucket detail page, B2 shows the S3-compatible endpoint. It looks like s3.us-west-004.backblazeb2.com where the number matches your account’s cluster. Different accounts land on different numbers; use whatever B2 shows for your bucket.
Create an Application Key scoped to the bucket
Open App Keys > Add a New Application Key. Name it, restrict access to your specific bucket, choose Read and Write capabilities, and create the key. B2 shows the keyID and applicationKey exactly once. Copy both.
Fill in the SiteVault S3-Compatible modal
- Name. Friendly label. Example:
Backblaze B2 Backups. - Endpoint. Whatever B2 showed for your bucket, without
https://. Example:s3.us-west-004.backblazeb2.com. - Access Key ID. The B2
keyID. - Secret Access Key. The B2
applicationKey. - Bucket Name. The B2 bucket name.
- Region. Your bucket region such as
us-east-005. Match the region embedded in your endpoint (the004,005, etc. from the hostname). - Path Prefix. Optional. Default
sitevault/.
Click Test Connection, then Save Provider.
Wasabi
Wasabi advertises no egress fees and a flat storage price, which can be a good fit if your backup restore volume is unpredictable.
Create the bucket + access key in Wasabi
Create a Wasabi bucket
In the Wasabi console, open Buckets > Create Bucket. Pick a region (us-east-1, us-east-2, us-west-1, eu-central-1, and others) and give the bucket a unique name.
Create an access key
Under Access Keys > Create New Access Key. Choose Root User or, better, a dedicated user with a policy scoped to the bucket you created. Wasabi shows the Access Key and Secret Key exactly once. Copy both.
Fill in the SiteVault S3-Compatible modal
- Name. Friendly label. Example:
Wasabi Backups. - Endpoint,
s3.wasabisys.comfor us-east-1. Other regions use their own endpoint (for examples3.eu-central-1.wasabisys.com). Check the Wasabi documentation for your exact region’s endpoint. Nohttps://. - Access Key ID. The Wasabi Access Key.
- Secret Access Key. The Wasabi Secret Key.
- Bucket Name. The Wasabi bucket name.
- Region. The bucket’s region code (
us-east-1for the wasabisys.com endpoint; match the endpoint you entered for other regions). - Path Prefix. Optional. Default
sitevault/.
Click Test Connection, then Save Provider.
MinIO (self-hosted)
MinIO is an open-source S3-compatible object store you host yourself. It’s a good fit for on-premises setups or air-gapped environments where you want backups to stay inside your own infrastructure.
Prepare your MinIO instance
Confirm MinIO is reachable from your WordPress server
The MinIO server needs to be reachable over HTTPS from the machine your WordPress site runs on. If MinIO is behind a firewall or on a private network, make sure the WordPress server can reach it.
Create a bucket
In the MinIO console, create a bucket with a name of your choice.
Create a service account
Create a new access key under Identity > Service Accounts (or, on older MinIO versions, under Access Keys). Restrict its policy to the target bucket where possible. Save the Access Key and Secret Key.
Fill in the SiteVault S3-Compatible modal
- Name. Friendly label. Example:
Internal MinIO Backups. - Endpoint. The hostname of your MinIO server, no
https://, no bucket path. Example:minio.internal.example.com. - Access Key ID. The MinIO access key.
- Secret Access Key. The MinIO secret key.
- Bucket Name. The bucket you created in MinIO.
- Region. Usually
us-east-1, unless you have setMINIO_REGIONto something else on the server. Match what your MinIO config uses. - Path Prefix. Optional. Default
sitevault/.
Click Test Connection, then Save Provider.
SiteVault expects a valid HTTPS certificate. If your MinIO instance uses a self-signed certificate, install a real certificate (LetsEncrypt or a private CA rooted on your WordPress server) before pointing SiteVault at it. Skipping certificate verification is not recommended for a system storing your backups.
Verifying the connection and syncing existing backups
Once the provider is saved, three actions live on the row inside the Connected Providers table:
- Test. Runs the same connectivity probe as the modal’s Test Connection button. Use this if credentials rotated or the bucket was moved.
- Sync Now. Uploads any completed backups on the site that have not yet been synced to this provider. Useful right after adding a new provider, or after fixing a credential problem.
- Delete. Removes the provider from SiteVault. Does not delete anything from the bucket itself.
After clicking Sync Now, watch the Last Sync column in the Connected Providers table. It updates when the upload completes. If sync fails 3 times in a row, SiteVault fires the alert notice described in Understanding Cloud Sync Failure Alerts.
Common Test Connection failures
| Error you see | Most common cause | Fix |
|---|---|---|
InvalidAccessKeyId or Access Denied |
Typo in the Access Key ID or Secret, or the key was rotated on the provider side | Copy and paste the credentials fresh from the provider console. Watch out for stray whitespace at the start or end. |
NoSuchBucket or The specified bucket does not exist |
The bucket name in the modal doesn’t match a real bucket, or the endpoint points at a different region than the bucket | Confirm the bucket exists in the provider console and that the Endpoint hostname matches the region the bucket is in. |
Could not resolve host or DNS errors |
Endpoint hostname is misspelled or contains https:// or a bucket prefix |
Enter the hostname only, no scheme, no bucket name. See the endpoint examples per provider above. |
SignatureDoesNotMatch |
Region value doesn’t match what the provider expects for SigV4 signing | Cloudflare R2 needs auto. Wasabi wasabisys.com needs us-east-1. B2 needs your bucket region such as us-east-005. DO Spaces needs the datacenter code. |
PermanentRedirect (or a redirect chain) |
Endpoint points at a different region than the bucket lives in | Move the bucket to the region matching the endpoint, or change the endpoint to match the bucket’s actual region. |
| Timeout with no specific error code | Firewall between your WordPress server and the provider, or the provider is blocking your server’s IP | Check outbound HTTPS is allowed from your WordPress host. For self-hosted MinIO on a private network, confirm the WordPress server can reach the MinIO hostname. |
FAQ
What is the difference between the Amazon S3 and S3-Compatible options in SiteVault?
The Amazon S3 modal is preset for AWS and shows a Region dropdown of the standard AWS regions. Use it when your bucket lives in an actual AWS account. The S3-Compatible modal adds an Endpoint field so you can point SiteVault at any provider that speaks the S3 API, DigitalOcean Spaces, Cloudflare R2, Backblaze B2, Wasabi, or a self-hosted MinIO instance.
Do I need to create the bucket in the provider console first?
Yes. SiteVault does not create the bucket for you. Create it in the provider’s console first, then paste the bucket name into the SiteVault modal. The helper text under the Bucket Name field says “must already exist” as a reminder.
What permissions does the access key need?
The access key must be able to list, put, get, and delete objects in the target bucket. SiteVault uses list and put during backup uploads, get during cloud downloads and restores, and delete when the retention policy cleans up old backups. If the key lacks delete permission, retention deletions will surface as failed syncs via the alert framework described in Understanding Cloud Sync Failure Alerts.
Can I use one bucket for backups from multiple sites?
Yes, if you set a unique Path Prefix per site. For example, use site-one/ on one site and site-two/ on the other. Backups from each site end up under its own prefix inside the same bucket. Do not share the same prefix between two sites, retention would delete each other’s backups.
Are the credentials encrypted at rest in the WordPress database?
Yes. SiteVault encrypts every stored credential using authenticated AES-256-GCM. The encryption key is derived from a per-site secret combined with your WordPress AUTH_KEY constant, so the ciphertext in the database is unreadable without both. Credentials are only decrypted at the moment SiteVault needs to call the cloud API.
What is the Path Prefix field for?
Path Prefix is an optional folder name prepended to every backup uploaded to the bucket. The default is sitevault/. Setting a prefix keeps backups organized inside a bucket that might contain other data, and lets a single bucket host backups from multiple sites (see previous question).