Skip to main content

Public Bucket

Sometimes you want to share your bucket with the world. You can do this by creating a public bucket. This will allow anyone to read the contents of your bucket. You can still control who can write to your bucket.

Creating a public bucket using AWS CLI

Assuming you have the AWS CLI configured as shown in the AWS CLI guide, you can create a public bucket as follows:

aws s3api --endpoint-url https://t3.storage.dev create-bucket --bucket foo-public-bucket --acl public-read
$ aws s3api --endpoint-url https://t3.storage.dev create-bucket --bucket foo-public-bucket --acl public-read
{
"Location": "/foo-public-bucket"
}

The key here is the --acl public-read flag. This will allow anyone to read the contents of the bucket foo-public-bucket.

Accessing objects in a public bucket

Objects in a public bucket (by default) can be read without any authentication. However, only those with access to the bucket can write objects.

Let’s upload a file to our public bucket:

$ aws s3api --endpoint-url https://t3.storage.dev put-object --bucket foo-public-bucket --key bar.txt --body bar.txt
{
"ETag": "\"c157a79031e1c40f85931829bc5fc552\""
}

Now, anyone can read this file without authentication.

Public bucket domains

Every public bucket is automatically served over several dedicated public content domains. Using foo-public-bucket as an example, the bucket is accessible at:

DomainExample URL
BUCKET_NAME.t3.tigrisfiles.iohttps://foo-public-bucket.t3.tigrisfiles.io/bar.txt
BUCKET_NAME.t3.tigrisbucket.iohttps://foo-public-bucket.t3.tigrisbucket.io/bar.txt
BUCKET_NAME.t3.tigrisblob.iohttps://foo-public-bucket.t3.tigrisblob.io/bar.txt

All three domains serve the same content without authentication and are interchangeable.

Existing Fly.io accounts

Existing Fly.io accounts can also access public content at BUCKET_NAME.fly.storage.tigris.dev. This continues to work but is not available for new accounts. We recommend setting up a custom domain for production use regardless of which domain you currently use.

warning

The public bucket domains don’t work with dots in bucket names because the SSL wildcard certificate only matches bucket names that do not contain dots. Dots create multiple subdomain levels that a single wildcard certificate doesn’t cover. Use a custom domain if your bucket name contains dots.

Virtual-hosted–style request

Virtual host style URLs are the default way of referencing your objects. In a virtual-hosted–style URI, the bucket name is part of the domain name in the URL.

Virtual-hosted–style URLs use the following format:

https://bucket-name.t3.tigrisbucket.io/key-name

So for the object we just uploaded, the virtual-hosted–style URL would be:

$ wget https://foo-public-bucket.t3.tigrisbucket.io/bar.txt -O- -q
bar
warning

Virtual-hosted–style access doesn’t work with dots in bucket names because the SSL wildcard certificate only matches bucket names that do not contain dots. Dots create multiple subdomain levels that a single wildcard certificate doesn’t cover. Use a custom domain if your bucket name contains dots.

Path-style request

For buckets created on or after February 19, 2025, path-style URLs are no longer supported. For buckets created before February 19, 2025, path-style URLs will continue to function. However, we recommend updating your code to use virtual-hosted style URLs as it provides a unique subdomain per bucket.

Path-style URLs use the following format:

https://t3.tigrisbucket.io/bucket-name/key-name

So for the object we just uploaded, the path-style URL would be:

$ wget https://t3.tigrisbucket.io/foo-public-bucket/bar.txt -O- -q
bar
info

You can have a mix of public and private objects in a public bucket. By default, all objects inherit the access control settings of the bucket they are in. If a bucket is public-read, all objects are publicly readable. If you want to make an object private, you can set the object ACL to private. See the Object ACLs guide for more information.

Custom domain

For production use, we recommend configuring a custom domain for your public bucket. A custom domain gives you:

  • Brand consistency — serve content from your own domain (e.g., assets.example.com) instead of a Tigris-managed domain.
  • Portability — your URLs stay stable if you ever change your underlying storage configuration.
  • No dot-in-name restrictions — custom domains work regardless of whether your bucket name contains dots.

To set up a custom domain, create a CNAME record pointing your domain to foo-public-bucket.t3.tigrisbucket.io and then configure the domain in your bucket settings. See the Custom Domains guide for full instructions.