Let’s say you’re trying to work on a clone of Twitter to learn how something like that is made with Next.js. Sooner or later, you’re gonna hit a wall: someone wants to change their avatar. It's vibe coding time!

I want you to imagine what life was like before we had object storage. Uploading files was a custom process. If you wanted to scale, you ended up having to hire storage area network experts that built complicated systems with terms like “LUN” and “erasure coding”. Your application had to either shell out to an FTP server to handle uploads or put them alongside the source code. Above all though: everything had to be planned in advance. You had to do capacity planning so that you could know how much storage you needed to buy and when you needed to buy it. You couldn’t just insert a credit card and then get all the storage you wanted.

In 2006, Amazon invented the concept of object storage, fundamentally changing how applications work. Storage became a faucet. If you want more, you simply turn the knob. Bottomless storage was revolutionary, and now we’ve come to expect storage to be decoupled from physical hardware. S3 paved the way for seamless data management across any environment as long as it had a connection back to Amazon.

One of the great things about modern AI editor workflows is how it makes it easier to get started. Normally when you open a text editor, you have an empty canvas and don’t know where to start. AI tools let you describe what you want and help you get started doing it.

“We’ve all been excited about AI editors making development fast and just plain fun.”

• Most developers, probably

Today we’re happy to announce that we’re making it even easier to get started with Tigris in your AI editor workflow. If you want to get to the part where you can plug configs into your AI editor and get started, head to Getting Started and get off to vibe coding your next generation B2B SaaS as a service.

At Tigris, globally replicated object storage is our thing. But why should you want your objects "globally replicated"? Today I'm gonna peel back the curtain and show you how Tigris keeps your objects exactly where you need them, when you need them, by default.

Global replication matters because computers are ephemeral and there's a tradeoff between performance and reliability. But does there have to be?

Tigris has achieved SOC 2 Type II certification, signifying our high standard for security and operations. We have partnered with an independent third party to thoroughly review our policies and procedures and verify our compliance. We’re excited to provide secure object storage for everyone, whether you’re storing megabytes or petabytes.

Hey! Thanks for catching my talk Affording your AI chatbot friends. Here's some resources that were mentioned during the talk.

As the saying goes, the only constants in life are death and taxes. When you work with the Internet, you get to add another fun thing to that list: service deprecations. This is a frustrating thing that we all have to just live with as a compromise for not owning every single piece of software and service that we use. In their effort to keep life entertaining, Google has announced that they’re deprecating Google Container Registry. This is one of the bigger container registry services outside of the Docker Hub and it’s suddenly everyone’s emergency.

Google Container Registry will be deprecated on March 18, 2025. This date is coming up fast. Are you ready for the change?

The Docker Hub is going to drastically decrease the rate limits for free accounts on April first. Are you ready for those changes? Here’s a high level overview of the rate limit changes we’re about to have:

What if you could easily cache images so these rate limits don’t impact your workloads? Today I’m going to show you how you can set up your own pull-through cache of the docker hub so that your workloads only have to download images once.

We’re transitioning to virtual hosted style URLs for all new buckets created after February 19, 2025. For new buckets, we will stop supporting path style URLs. Buckets created before February 19, 2025 will continue to work with either path style or virtual host style URLs.

The path style URL looks like this: https://fly.storage.tigris.dev/tigris-example/bar.txt

The virtual host style URL looks like this: https://tigris-example.fly.storage.tigris.dev/bar.txt

With the path style URL, the subdomain is always fly.storage.tigris.dev. By moving to virtual host style URLs, the subdomain is specific to the bucket. This additional specificity allows us to make some key improvements for security and scalability.

Why make this change now?​

Recently some ISPs blocked the Tigris subdomain after malicious content was briefly shared using our platform. Though we removed the malicious content, the subdomain was the common denominator across several reports and added to blocklist maintained by security vendors. This block of our domain resulted in failed downloads on several ISPs with unclear error messages. Either the DNS resolved to another IP not owned by Tigris, or there were connection errors that implied a network issue. We’re sure this was frustrating for folks to debug.

We have been working with the security vendors to remove our domain from their blocklists. However, the long term solution is to move to virtual hosted style URLs so that the subdomains are no longer the common denominator when identifying content.

How does this impact your code?​

You’ll need to update your code anywhere you have path based access like for presigned URLs. You’ll also need to configure your S3 client libraries to use the virtual hosted style URL. Some examples are below. If we’ve missed your framework, please reach out, and we’ll help.

svc = boto3.client(
	's3',
	endpoint_url='https://fly.storage.tigris.dev',
	config=Config(s3={'addressing_style': 'virtual'}),
)

sdkConfig, err := config.LoadDefaultConfig(ctx)
if err != nil {
	log.Fatalf("Couldn't load default configuration. Here's why: %v", err)
	return
}

// Create S3 service client
svc := s3.NewFromConfig(sdkConfig, func(o *s3.Options) {
	o.BaseEndpoint = aws.String("https://fly.storage.tigris.dev")
	o.Region = "auto"
	o.UsePathStyle = false
})

IAmazonS3 s3Client = new AmazonS3Client(
	new AmazonS3Config {
		ForcePathStyle = false,
		ServiceURL = "https://fly.storage.tigris.dev"
	}
);

s3 = Aws::S3::Client.new(
	region: "auto",
	endpoint: "https://fly.storage.tigris.dev",
	force_path_style: false,
)

const S3 = new S3Client({
  region: "auto",
  endpoint: "https://fly.storage.tigris.dev",
  s3ForcePathStyle: false,
});

config :ex_aws, :s3,
  scheme: "https://",
  host: "fly.storage.tigris.dev",
  region: "auto",
  virtual_host: true

With this move to virtual hosted style URLs, we’re undoubtedly going to break some existing workflows as new buckets are created. If this creates a hardship on you, please contact us at help@tigrisdata.com and we'll find a solution.

The software ecosystem is built on a bedrock of implicit trust. We trust the software won’t have deliberately placed security vulnerabilities and won’t be yanked away offline without warning. AI models aren’t exactly software, but they’re distributed using a lot of the same platforms and technology as software. Thus, people assume they’re distributed using the same social contract as with software.

The AI ecosystem has a lot of the same distribution and trust challenges as software ecosystems do, but with much larger blobs of data that are harder to introspect. There are fears that something bad is going to happen with some large model and create a splash even greater than the infamous left-pad incident of 2016. These kinds of attacks seem unthinkable, but are inevitable.

How can you defend against AI supply-chain attacks? What are the risks? Today I’m going to cover what we can learn from the left-pad incident and how making a copy of the models you depend on can make your products more resilient.