[Blog](/blog/.md)
/
[Updates](/blog/tags/updates/.md)
# You wanted more lifecycle rules. They're here.
Garren · May 26, 2026 ·
8 min read
[](https://www.garrensmith.com)
[Garren](https://www.garrensmith.com)
Founding Engineer
Anyone who's spent a weekend in Minecraft knows the moment. You've got eleven double chests labeled "STUFF", you can't find your iron, and you finally cave and build the sorting room. Hoppers feeding chests, item filters routing cobblestone to the bulk room, lava bucket waiting for the rotten flesh you'll never use. Once you have it, you wonder how you lived without it.
Buckets without proper lifecycle rules are the same situation. One giant chest. No hoppers. You're paying to keep your build screenshots from 2022 sitting next to last night's logs.
Last year, [we shipped lifecycle rules](/blog/lifecycle-rules/.md) for Tigris. One rule per bucket, one transition or one expiration. They have been incredibly useful for a lot of users. But we wanted to take it further. Today is that day: **multiple rules per bucket**, **prefix filters**, transitions and expirations mixed however you want.
The hoppers are here.
## What's actually new[](#whats-actually-new "Direct link to What's actually new")
Before this update, you got one lifecycle rule per bucket, applied to every object in it. That's enough to do "move everything older than 30 days to Archive," but not much more.
Now:
* A bucket can have **multiple lifecycle rules** — up to ten.
* Each rule can be scoped to a key prefix using `Filter.Prefix`. Omit the filter (or pass `Filter: {}`) to apply the rule to every object in the bucket.
* Transition and expiration rules can be mixed in the same bucket however you want.
* Each rule can have an `ID` (up to 36 characters) so you can name what it does.
* A single rule can include both a transition and an expiration, but only one of each. So `Standard → IA → expire` fits in one rule, while chaining `Standard → IA → Glacier` takes two.
Full reference lives in the docs: [Object Lifecycle Rules](https://www.tigrisdata.com/docs/buckets/object-lifecycle-rules/) and [Object Expiration](https://www.tigrisdata.com/docs/buckets/objects-expiration/).
Here's the new shape of a single rule:
```
{
"ID": "logs-to-ia",
"Status": "Enabled",
"Filter": { "Prefix": "logs/" },
"Transitions": [{ "Days": 30, "StorageClass": "STANDARD_IA" }]
}
```
That's the building block. Let's build three sorting rooms.
## Sorting room 1: Logs with retention tiers[](#sorting-room-1-logs-with-retention-tiers "Direct link to Sorting room 1: Logs with retention tiers")
Imagine your service writes structured logs to `logs/` in a bucket. Engineers grep them every day for the first month. Quarterly audits pull from them for a year. After that, nobody touches them. Compliance still says you keep them for 18 months and then they go away.
Before, you'd need a cron job to do this. Or three buckets. Or a lot of luck.
Now you write one rule that does both: a transition and an expiration on the same prefix.
```
{
"Rules": [
{
"ID": "logs-tiered-retention",
"Status": "Enabled",
"Filter": { "Prefix": "logs/" },
"Transitions": [{ "Days": 30, "StorageClass": "STANDARD_IA" }],
"Expiration": { "Days": 540 }
}
]
}
```
The rule moves anything under `logs/` to Infrequent Access after 30 days, then deletes it after 540. Logs older than a month live in cheaper storage. Logs older than 18 months don't live anywhere.
Exactly what [the previous post](/blog/lifecycle-rules/.md) promised: slowly punting things down the tier list before they're eventually deleted. Same savings shape too — older logs at IA cost a fraction of fresh logs at Standard, and at day 540 they cost nothing.
## Sorting room 2: One bucket, three workloads[](#sorting-room-2-one-bucket-three-workloads "Direct link to Sorting room 2: One bucket, three workloads")
Now picture a SaaS app that stores three kinds of objects in one bucket:
* `uploads/` — user-generated content. These are forever.
* `thumbnails/` — automatically generated from uploads. Regenerable, so they should expire.
* `exports/` — one-time CSV downloads. Once the user has the file, it's dead weight.
Three workloads, three lifecycles, one bucket. With prefix filtering you write two rules and you're done:
```
{
"Rules": [
{
"ID": "thumbnails-expire",
"Status": "Enabled",
"Filter": { "Prefix": "thumbnails/" },
"Expiration": { "Days": 30 }
},
{
"ID": "exports-expire",
"Status": "Enabled",
"Filter": { "Prefix": "exports/" },
"Expiration": { "Days": 7 }
}
]
}
```
Uploads don't need a rule. They live forever, which is the whole point.
Before this change, you had two options for this kind of thing: run a deletion script and hope it stays correct, or split your bucket into three. Both were bad. Now it's two JSON objects in a config file.
## Sorting room 3: An ML training pipeline[](#sorting-room-3-an-ml-training-pipeline "Direct link to Sorting room 3: An ML training pipeline")
If you're training models on Tigris, your bucket probably looks something like this:
* `datasets/raw/` — your source data. Used hard during a training run, barely after.
* `checkpoints/` — model snapshots from each run. Hot during training, cold once the run is done.
* `artifacts/intermediate/` — embeddings, tokenized batches, debug outputs. You generate them, you regenerate them, and you mostly throw them away.
This is where multi-rule lifecycle earns its keep. One bucket holds three prefixes, each on its own policy:
```
{
"Rules": [
{
"ID": "raw-archive",
"Status": "Enabled",
"Filter": { "Prefix": "datasets/raw/" },
"Transitions": [{ "Days": 14, "StorageClass": "GLACIER" }]
},
{
"ID": "checkpoints-cool",
"Status": "Enabled",
"Filter": { "Prefix": "checkpoints/" },
"Transitions": [{ "Days": 7, "StorageClass": "STANDARD_IA" }]
},
{
"ID": "intermediate-expire",
"Status": "Enabled",
"Filter": { "Prefix": "artifacts/intermediate/" },
"Expiration": { "Days": 3 }
}
]
}
```
Raw datasets get archived two weeks after a training run. Checkpoints cool down to Infrequent Access after a week. Intermediate artifacts get deleted after three days.
Zero egress on a globally distributed, multi-cloud bucket helps here. Archiving training data on other clouds is a decision you think twice about because thawing it back out costs you. On Tigris, it's storage that costs less.
[Pt 1's savings example](/blog/lifecycle-rules/.md): a 120 TB bucket dropped from $2,450 to $833 a month after 92 TB moved to Archive. About two thirds off the original bill. Raw datasets dwarf checkpoints and intermediate artifacts in most training pipelines, so the bulk of the savings on Tigris comes from the `GLACIER` transition on `datasets/raw/` — the corpus that drives most of the storage bill in training workloads.
## How rules are evaluated[](#how-rules-are-evaluated "Direct link to How rules are evaluated")
Multi-rule lifecycle on Tigris doesn't have a coordination layer in front of the workers. Each rule runs on its own worker, walking the bucket oldest-first. If two rules match the same object, whichever worker picks it up first does the work.
You can't transition from a colder tier to a warmer one. Once an object lands in `GLACIER`, no rule can pull it back to `STANDARD_IA`. When two transitions race, the one that fires first is the only one that matters — the other has nothing to do by the time it arrives.
When a transition and an expiration fire on the same object at roughly the same moment, [pt 1's global replication](/blog/lifecycle-rules/.md) settles it the same way it settles any other concurrent metadata update: by timestamp. Multi-rule reuses the architecture pt 1 walked through.
## A note on what's not here yet[](#a-note-on-whats-not-here-yet "Direct link to A note on what's not here yet")
Filtering is by key prefix only. Not by object tags. If you've used S3 lifecycle rules in anger, you've probably reached for tag-based filters at some point. "Expire everything tagged `temp`." "Transition objects tagged `cold`." We don't have that yet. Prefix filtering covers most of what people reach for, but if tag filtering is the missing piece for you, tell us in [our Discord](https://community.tigrisdata.com/). That feedback shapes what we build next.
## How to turn it on[](#how-to-turn-it-on "Direct link to How to turn it on")
Same one-liner as before. The JSON file holds more rules now — up to ten per bucket. That cap is arbitrary; we can raise it if you need more.
```
aws s3api put-bucket-lifecycle-configuration \
--bucket my-bucket \
--lifecycle-configuration file://lifecycle.json
```
If your bucket already has data in it, the new rules apply on the next scan, oldest-first — no backfill flag, no migration. Expect the first action within a few minutes, or up to fifteen or twenty if the scheduler just finished a sweep.
If you'd rather click than write JSON, the [Tigris Dashboard](https://console.storage.dev/) has the same controls. The full configuration reference is in the docs: [Object Lifecycle Rules](https://www.tigrisdata.com/docs/buckets/object-lifecycle-rules/) covers transitions, [Object Expiration](https://www.tigrisdata.com/docs/buckets/objects-expiration/) covers deletion, and [Storage Tiers](https://www.tigrisdata.com/docs/objects/tiers/) explains what `STANDARD_IA`, `GLACIER`, and `GLACIER_IA` actually mean.
## Wrapping up[](#wrapping-up "Direct link to Wrapping up")
Every Minecraft player eventually builds the sorting room because the alternative is chaos. Buckets are no different. Lifecycle rules stop you paying to store the bits that aren't earning their keep.
We've got more on the way: tag-based filtering, and a few things we're not quite ready to talk about yet. Keep your eyes peeled.
Set and forget object storage
Filter by prefix,
more hoppers in your bucket;
old bytes drift away.
[Get started today!](https://www.tigrisdata.com/docs/get-started/)
**Tags:**
* [Updates](/blog/tags/updates/.md)
* [object storage](/blog/tags/object-storage/.md)
* [s3](/blog/tags/s-3/.md)
* [feature](/blog/tags/feature/.md)
* [lifecycle](/blog/tags/lifecycle/.md)