Your own storage
Serve your game files from your own R2, Amazon S3 or Google Cloud bucket.
By default Deltaship stores your releases and delivers them to players. On Pro and up you can serve your game files from your own bucket instead: Cloudflare R2, Amazon S3, Google Cloud Storage or another S3-compatible store. You pay your storage provider directly, keep your files in the region you choose, and your files stay in an account you own.
Nothing about safety changes. Every file is still verified against your signed release before the game starts, whoever stores it. A file in your bucket that was changed or damaged is refused by the launcher and never installed.
What goes in your bucket#
- Your game files go to your bucket, in a folder of their own for your studio inside the folder you choose.
- Everything else stays with Deltaship: release records and signatures, your launcher design and images, and your launcher installers. A misconfigured bucket can never change what a release is.
- Files in your bucket do not count toward your plan's hosted storage. Storage & hosting shows both totals.
Before you start#
- You need a plan that includes your own storage (Pro and up). On other plans the Your own storage panel on Storage & hosting shows which plans have it, with a link to compare plans.
- Only owners and admins can connect or change a bucket, and your email must be confirmed.
- Studios keep the terms of the plan they signed up on (see Plans and limits). If your plan was taken out before this feature was added and the panel does not offer it, contact Deltaship.
- Create a bucket and an access key limited to that bucket. The key must be able to write, read and delete files in it.
Connect a bucket#
- In the dashboard, open Storage & hosting.
- In Your own storage, under Connect a bucket, choose your Provider.
- Fill in the fields:
| Field | What to enter |
|---|---|
| Endpoint | Your provider's address, as a full https address with no path. For R2 it looks like https://ACCOUNT_ID.r2.cloudflarestorage.com; for Amazon S3, https://s3.REGION.amazonaws.com; for Google Cloud Storage, https://storage.googleapis.com. |
| Bucket | The bucket's name: 3 to 63 lowercase letters, digits, dots, dashes or underscores. |
| Region | auto for R2 and Google Cloud Storage; the bucket's region, such as eu-west-1, for Amazon S3. |
| Folder in the bucket | Where Deltaship keeps your files. Defaults to udtk/. |
| Access key ID and Secret access key | The key you created for this bucket. |
- Choose Test and connect.
For Google Cloud Storage, create an HMAC key for a service account (Cloud Storage's interoperability settings) and enter its access ID and secret here. A normal service account key file does not work.
The secret key is stored encrypted and is never shown again. The panel shows only the last four characters of the access key ID.
Rules for the endpoint: it must be a public DNS name on the standard https port. IP addresses, internal names, Deltaship's own addresses and anything that redirects are refused. A bucket folder can belong to one studio only; if another studio already uses it you are asked to pick a different bucket or folder.
What the connection test checks#
When you connect, and whenever you choose Test connection, Deltaship writes a small test file into your folder, reads it back and compares it, then deletes it. The bucket is only connected if all three steps pass. If one fails, the message names the step (write, read or delete) and a short reason such as access denied, bucket or file not found, no response or the endpoint redirected. Nothing is saved when a test fails.
For Amazon S3 and Cloudflare R2 the test also checks whether the bucket enforces file checksums. Only a bucket that passes this check can receive direct uploads.
Uploading to your bucket#
By default every upload goes through Deltaship, which verifies each file before writing it to your bucket. The Unreal plugin always uploads this way.
The command-line publisher and the GitHub Action can instead send files straight to your bucket, which skips Deltaship for the upload itself. It is opt-in: use the publisher's --direct-upload option or set the action's direct-upload input to true. Deltaship then hands out short-lived upload addresses, the bucket refuses any file that does not match, and Deltaship checks the stored size and checksum before recording each file. If your bucket cannot be used this way, or cannot prove the checksum for a file, that file goes through Deltaship automatically. See Publishing from CI.
Connecting, testing and replacing keys are limited to 10 an hour for your studio.
After you connect#
The panel lists each bucket with a status:
| Status | Meaning |
|---|---|
| New uploads | Your active bucket. New files from every upload go here. |
| Serving existing files | A bucket you stopped using for new uploads. Releases that still need its files keep working. |
Files that Deltaship already stores stay where they are and keep being served. Only new files go to your bucket, and a file your studio already has is never uploaded twice.
Players download straight from your bucket, using short-lived download links that Deltaship creates for them. Your bucket becomes part of your players' download path, so an outage at your storage provider is an outage for installs and updates. Installed games keep playing.
Replace keys#
When keys are rotated, revoked or no longer work:
- Open Storage & hosting and expand Enter new keys for your bucket.
- Enter the New access key ID and New secret access key.
- Choose Test and replace keys.
Deltaship tests the new keys against the same bucket first. If they pass, files already in the bucket are served with them from then on. The old keys are replaced.
If a connection cannot be used, for example because its last test failed, it is never used for new uploads. The next publish uploads again any file that is only in that bucket, to your current storage, so a release is never left incomplete. Entering working keys makes the bucket's files available again.
Stop using a bucket#
Choose Stop using for new uploads on the bucket. New files go to Deltaship storage again. Files already in the bucket are still served from it until no release uses them, so keep the bucket and its keys until then. Deltaship removes a stopped bucket's saved keys once nothing needs it.
Connecting a different bucket does the same for the old one: it moves to Serving existing files.
If your plan changes#
If you move to a plan that does not include your own storage, nothing breaks. New uploads go to Deltaship storage, counted against that plan's storage limit, and files already in your bucket keep being served. See Inactivity, payments and downgrades.
When old releases are removed, for example under your plan's kept releases limit, Deltaship deletes their files from your bucket as well. It deletes only files in your studio's own folder. If your bucket cannot be reached at that moment, it tries again the next day.
Azure support#
Troubleshooting#
| Message | What to check |
|---|---|
| Could not write a test file (access denied) | The key can write to this bucket and folder. |
| Could not write a test file (bucket or file not found) | The bucket name, region and endpoint. |
| Could not write a test file (no response) | The endpoint address, and that the bucket's provider is reachable. |
| The endpoint redirected | Use the address your provider gives for this bucket's region. |
| That bucket folder is already used by another studio | Choose a different bucket or folder. |
| Confirm your email before connecting a bucket | Confirm your email address, then try again. |
| Your plan does not include your own storage | See the plans that do under Plans and limits. |
| Too many storage changes | Try again in an hour. |