DEV Community: Twilight

your media files have an expiration date

Twilight — Sat, 04 Apr 2026 19:05:16 +0000

A photo uploaded to your app today gets views. The same photo from two years ago sits in storage, loaded maybe once when someone scrolls back through an old profile. You pay the same rate for both.

I have seen this pattern in every media-heavy application I have worked on. The hot data is a thin slice. The cold data grows without stopping. If you treat all objects the same, your storage bill reflects the worst case: premium pricing for data nobody touches.

Tigris gives you two mechanisms to deal with this. You can transition old objects to cheaper storage tiers, or you can expire them outright. Both happen on a schedule you define. This post covers when and how to use each one.

how media access decays

Think about a social media feed. A user uploads a photo. For the first week, that photo appears in followers' feeds. It loads fast because your CDN caches it. After a month, the photo surfaces only when someone visits the user's profile. After a year, it loads during an occasional deep scroll or a search result.

Log files follow a similar curve. You need today's logs for debugging. Last month's logs exist for compliance. Last year's logs exist because nobody deleted them.

The access pattern is predictable: frequency drops off a cliff after a short window. Your storage costs, if you do nothing, stay flat.

the four storage tiers

Tigris stores your data globally across multiple regions by default. Within that global infrastructure, you get four tiers to choose from.

Standard is the default. High durability, low latency, what you expect from object storage. Use it for anything that loads in response to a user action.

Infrequent Access (STANDARD_IA) costs less to store but charges for retrieval. The data remains available with the same low latency. Use it when you need the data to load fast but you do not expect frequent requests: profile photos older than 30 days, generated reports, backup snapshots.

Archive (GLACIER) has the lowest storage cost but requires restoration before access. Restoration takes about an hour. Use it for data you must retain but almost never read: old backups, compliance logs, completed project archives.

Archive with Instant Retrieval (GLACIER_IR) sits between Infrequent Access and Archive. You get archive-level pricing with immediate retrieval. Use it when you want cheap storage but cannot wait an hour for restoration: quarterly reports, seasonal content that resurfaces, audit records that regulators might request on short notice.

Here is the tradeoff in plain terms: you pay more to store data you access often, and you pay less for data you rarely touch. The retrieval pricing inverts: cheaper tiers charge more per GET request. If you transition data to a cheap tier and then access it every day, you lose money. The tiers work when your access patterns match the pricing.

transitioning objects between tiers

You configure lifecycle rules at the bucket level. A rule tells Tigris: after X days, move objects from their current tier to a specified tier.

You can set the transition trigger by days (after the object's last modified date) or by a specific calendar date.

transitioning after 30 days

This is the common pattern. Objects start in Standard. After 30 days of no modification, they move to Infrequent Access.

Create a file called lifecycle.json:

{
  "Rules": [
    {
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        }
      ]
    }
  ]
}

Apply it:

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-media-bucket \
  --lifecycle-configuration file://lifecycle.json

Objects in this bucket will transition to Infrequent Access after 30 days. The transition happens at UTC midnight.

transitioning to archive at a fixed date

Some data has a known shelf life. Annual reports from 2024 should move to archive storage after the year ends.

{
  "Rules": [
    {
      "Status": "Enabled",
      "Transitions": [
        {
          "Date": "2025-12-31T00:00:00Z",
          "StorageClass": "GLACIER"
        }
      ]
    }
  ]
}

Same apply command. Every object in the bucket moves to Archive on December 31, 2025.

combining transition and expiration

A single lifecycle rule can include both transition and expiration. The one-rule-per-bucket limit refers to rule objects, not actions. You can transition objects at 30 days and expire them at 365 days in the same rule.

{
  "Rules": [
    {
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

Objects in this bucket move to Infrequent Access after 30 days and get deleted after 365 days.

expiring objects with TTL

Some data has no business existing after a certain point. Temporary upload tokens, generated thumbnails you regenerate on demand, session recordings older than 90 days. Expiration rules delete objects on a schedule so you do not have to.

The configuration mirrors transitions:

{
  "Rules": [
    {
      "Status": "Enabled",
      "Expiration": {
        "Days": 30
      }
    }
  ]
}

Every object in this bucket gets deleted 30 days after its last modified date. The expiration time rounds to UTC midnight.

You can also set a fixed date:

{
  "Rules": [
    {
      "Status": "Enabled",
      "Expiration": {
        "Date": "2025-12-31T00:00:00Z"
      }
    }
  ]
}

This deletes all objects in the bucket at the end of 2025. Useful for event-specific buckets: create a conference photo bucket, set a fixed expiration date, and the uploads disappear after the event wraps.

setting the tier on upload

You do not have to wait for lifecycle rules. You can set the storage tier at upload time using the x-amz-storage-class header or the --storage-class flag.

With the AWS CLI:

aws s3api put-object \
  --bucket my-bucket \
  --key quarterly-report-q3.pdf \
  --body report.pdf \
  --storage-class GLACIER_IR

With the REST API:

PUT /quarterly-report-q3.pdf HTTP/1.1
Host: my-bucket.storage.fly.tigris.dev
x-amz-storage-class: GLACIER_IR

This puts the object directly into Archive with Instant Retrieval, skipping Standard. Use this when you know at upload time that the data will not need frequent access.

You can also set a default tier at bucket creation time. Every object uploaded to that bucket inherits the default unless overridden by the header.

restoring objects from archive

Objects in the Archive tier are not available for GET requests. A GET on an archived object returns a 403 error. You must restore it first.

aws s3api restore-object \
  --bucket my-bucket \
  --key old-backup.tar.gz \
  --restore-request Days=3

The Days parameter controls how long the object stays restored. After three days in this example, the object moves back to Archive.

Check restoration status with:

aws s3api head-object \
  --bucket my-bucket \
  --key old-backup.tar.gz

The response includes a Restore header. During restoration, you see ongoing-request="true". When complete, the header shows the expiry date.

This restore step is the main reason Archive costs less. Tigris does not keep the data in a retrieval-ready state. If you need data available without a restore step, use Archive with Instant Retrieval instead.

a practical setup for a media app

Consider a photo-sharing app. Here is a tiering strategy that matches how people use the product.

Objects uploaded in the last 7 days: Standard tier. These photos appear in feeds and search results. They load often and need to load fast.

Objects between 7 and 90 days old: Infrequent Access. These photos load when someone visits a profile or clicks a shared link. The access is occasional but still needs low latency.

Objects older than 90 days: Archive with Instant Retrieval. Deep archive browsing is rare. When it happens, the user expects the photo to load without waiting. GLACIER_IR covers this case.

The current Tigris lifecycle configuration supports transitioning from Standard to one target tier per rule. To build a multi-step transition chain (Standard to IA to GLACIER_IR), you need application-level logic or multiple buckets. Most teams I have worked with pick one transition point and stop there. Moving from Standard to Infrequent Access at 30 days covers the bulk of the savings.

For expiration, create a separate bucket for temporary data. Generated thumbnails, video transcodes, upload staging files. Set a 30-day TTL on that bucket and let the objects delete themselves.

the cost argument

Storage costs compound. An app that uploads 10 GB of media per day accumulates 3.65 TB per year. If all of that sits in Standard storage, you pay Standard rates on every byte.

Moving objects to Infrequent Access after 30 days means you pay Standard rates on 300 GB (30 days of uploads) and Infrequent Access rates on the remaining 3.35 TB. The savings depend on the specific pricing, but the principle holds: cheaper storage on the data you touch least.

The mistake I see teams make is waiting too long to set up lifecycle rules. They treat it as an optimization to do later. Later, their storage bill is large enough that the savings from tiering would have paid for the engineering time several times over.

Set up your lifecycle rules when you create the bucket. It takes five minutes. The rule runs in the background from day one.

a few constraints to know

Tigris rounds all transition and expiration times to UTC midnight. If you set a 30-day transition, the object moves at midnight UTC on the 30th day after its last modified date.

One lifecycle rule per bucket. A rule can include both transitions and expiration, but you cannot stack multiple rules with different schedules on the same bucket.

The lifecycle configuration JSON accepts only the fields shown in the examples above when using the AWS CLI. Extra fields will cause errors.

getting started

Create a bucket in the Tigris Dashboard at console.storage.dev. Apply a lifecycle rule. Watch your objects transition on schedule. The whole process takes less than ten minutes.

If you are already using S3-compatible tooling, the migration path is direct. The AWS CLI and SDK work with Tigris without modification. Point your endpoint at Tigris, set your credentials, and run the same commands you already know.

File uploads for a social media app with Tigris

Twilight — Sat, 28 Mar 2026 21:48:27 +0000

Social media apps live and die on media handling. Users post photos, upload videos, share documents. Your backend could route every file through your servers, but that burns bandwidth and adds latency. Tigris gives you a way to push files straight from the browser to object storage, with the data replicated across multiple regions worldwide.

Tigris is an S3-compatible object storage service. Your data lives in multiple regions at once. A user in Tokyo uploads a photo; a follower in Berlin loads it from a nearby cache. You do not pick a primary region. Tigris handles distribution.

This post walks through using the Tigris JavaScript SDK to handle file uploads for a social media app.

Setup

Install the SDK:

npm install @tigrisdata/storage

Create a bucket at console.storage.dev and grab an access key. Put the credentials in your environment:

TIGRIS_STORAGE_ACCESS_KEY_ID=tid_your_access_key
TIGRIS_STORAGE_SECRET_ACCESS_KEY=tsec_your_secret_key
TIGRIS_STORAGE_BUCKET=social-media-uploads

Server-side uploads

Some uploads should go through your server. Profile pictures, for instance, where you want to validate image dimensions before storing. The put function handles this.

import { put } from "@tigrisdata/storage";

async function uploadAvatar(userId: string, imageBuffer: Buffer) {
  const result = await put(`avatars/${userId}.jpg`, imageBuffer, {
    contentType: "image/jpeg",
    access: "public",
    allowOverwrite: true,
  });

  if (result.error) {
    throw result.error;
  }

  return result.data?.url;
}

The returned url points to the uploaded file. Because access is "public", the URL works without authentication. Any user on the platform can load the avatar.

The SDK infers content type from the file extension when you omit contentType. Setting it explicitly is safer when the extension might not match the actual format.

Large files with multipart upload

Videos are the bulk of social media storage. A 500 MB video clip does not fit in a single request. Pass multipart: true and the SDK splits the file into chunks and uploads them in parallel.

import { put } from "@tigrisdata/storage";

async function uploadVideo(file: ReadableStream) {
  const result = await put("videos/new-post.mp4", file, {
    multipart: true,
    contentType: "video/mp4",
    access: "private",
    onUploadProgress: ({ loaded, total, percentage }) => {
      console.log(`${percentage}% uploaded`);
    },
  });

  if (result.error) {
    throw result.error;
  }

  return result.data;
}

The onUploadProgress callback fires as chunks complete. Wire it to a progress bar in the UI and users can see how far along the upload is.

Private files need a signed URL for access. Generate one with getPresignedUrl:

import { getPresignedUrl } from "@tigrisdata/storage";

const url = await getPresignedUrl("videos/new-post.mp4", {
  operation: "get",
  expiresIn: 3600,
});

That URL works for one hour. After that, generate a new one.

Client-side uploads

Routing files through your server wastes bandwidth. The Tigris SDK ships a browser-compatible module that uploads files directly from the client, skipping your server entirely.

Your server generates a presigned URL, the browser uploads to Tigris using that URL, and your server never touches the file bytes. The @tigrisdata/storage/client package wraps this into a single upload function.

First, add an API route that the client module calls to initiate the upload:

// pages/api/upload.ts (Next.js example)
import { getPresignedUrl } from "@tigrisdata/storage";

export default async function handler(req, res) {
  const url = await getPresignedUrl(`uploads/${req.body.filename}`, {
    operation: "put",
    contentType: req.body.contentType,
    expiresIn: 3600,
  });

  if (url.error) {
    return res.status(500).json({ error: url.error });
  }

  res.status(200).json(url.data);
}

Then in the browser:

<input type="file" onchange="handleUpload(event)" />

<script type="module">
import { upload } from "@tigrisdata/storage/client";

async function handleUpload(event) {
  const file = event.target.files[0];

  const result = await upload(`posts/${file.name}`, file, {
    url: "/api/upload",
    multipart: true,
    contentType: file.type,
    onUploadProgress: ({ percentage }) => {
      updateProgressBar(percentage);
    },
  });

  if (result.error) {
    console.error(result.error);
    return;
  }

  console.log("Uploaded:", result.data.url);
}
</script>

The url option tells the client module where your server endpoint is. The client calls that endpoint to get a presigned URL, then uploads the file bytes straight to Tigris. Your server CPU and bandwidth stay free.

Listing and deleting files

A user deletes a post. You need to remove the associated media. The SDK provides list and remove for this.

import { list, remove } from "@tigrisdata/storage";

async function deletePostMedia(postId: string) {
  const files = await list({ prefix: `posts/${postId}/` });

  if (files.error) {
    throw files.error;
  }

  for (const item of files.data?.items ?? []) {
    await remove(item.key);
  }
}

list with a prefix filter returns only objects under that path. Paginate with paginationToken when a prefix contains more than 100 objects.

Error handling

Every SDK function returns { data, error }. Check error before using data. This pattern works well in both server and client code:

const result = await put("photo.jpg", buffer);

if (result.error) {
  console.error("Upload failed:", result.error);
  return;
}

console.log("Stored at:", result.data?.url);

No exceptions to catch. No guessing about what went wrong. The error object contains enough information to surface a message to the user or log for debugging.

Why Tigris

Most object storage providers charge for egress. Social media apps serve the same files over and over; followers reload images, videos get replayed. Egress fees add up fast. Tigris charges zero for egress.

The global distribution is the other reason. You deploy one bucket. Tigris replicates the data across regions. Users in different continents load files from nearby infrastructure without any extra configuration from you.

The SDK is simpler than configuring the AWS S3 SDK. Three environment variables and you are done. No endpoint URLs to manage, no region parameters to pass on every call.

The Tigris JavaScript SDK handles the common file operations a social media app needs: upload, download, list, delete, and presigned URLs. Client-side uploads keep your server costs down. Global distribution keeps load times low for users everywhere.