Automatic expiration and noncurrent-version cleanup, config CRUD plus an execution sweep — with one honest architectural boundary: storage-class transitions to a colder tier are N/A, because XNS runs a single distributed erasure-coded tier, not multiple storage classes.
What this area is
S3’s lifecycle model covers two mechanisms: expiration (delete an object, or a noncurrent version, after N days or at a fixed date) and transition (move an object to a cheaper storage class after N days).
Operations covered here
GetBucketLifecycle/Put/Delete · current-version expiration · noncurrent-version expiration · storage-class transitions
How XNS implements it
Not just a stored rule nobody enforces. lifecycle_handlers.go handles config CRUD and the sweep; lifecycle_expiry_header.go adds an x-amz-expiration header (format expiry-date="<date>", rule-id="<id>") to PutObject and HeadObject responses when an enabled rule with an Expiration matches — the matcher evaluates live object tags at response time, not just at rule-write time.
The reason transitions are N/A, stated plainly: XNS stores every object on one distributed erasure-coded tier — the corp deployment convention is 80 data shards + 40 parity shards across up to 120 hosts per object (Reed-Solomon DataNum/ParityNum are per-cost-center configuration, not a fixed code constant). There is no second, cheaper tier for a lifecycle rule to move data into; redundancy and geo-distribution are inherent to every object from the moment it’s written, not something a rule turns on later.
<Prefix>, no <Filter> wrapper — fixed to match AWS's own round-trip shape.400 InvalidArgument rather than silently truncated.How we conform to the S3 protocol
Expiration and noncurrent-version expiration are verified against the same public conformance suite the rest of the industry is measured by, test by test. We publish the full per-test result, including what still fails, on the compatibility matrix rather than summarizing it here.
Where we deliberately differ. Storage-class-transition and cloud-tiering tests in the full ceph/s3-tests suite are excluded from this build's count entirely — the feature they test is architecturally N/A here (see What's out of scope on this page), not a failure we're hiding.
Expiration and noncurrent-version expiration pass clean; one header/tag-interaction edge case remains open. Full per-test detail is on the compatibility matrix, alongside every measured figure and its provenance.
How we compare
Source: the “Lifecycle & tiering” section of the S3 compatibility matrix, competitor cells from each vendor’s own documentation, researched 2026-06-14. The N/A cells carry the same footnote as the matrix (single distributed erasure tier) — read as “architecturally not applicable,” not “missing.”
| Capability | XNS | AWS S3 | Ceph | MinIO | Wasabi | B2 | Storj |
|---|---|---|---|---|---|---|---|
| Lifecycle expiration | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ object TTL only, no lifecycle config |
| Transitions to colder tiers | N/A single distributed erasure tier | ✓ | ✓ | ✓ | ✗ | ✗ | N/A |
| Noncurrent-version expiration | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ |
| Multiple storage classes | N/A | ✓ | ✓ | ◐ STANDARD + REDUCED_REDUNDANCY only | ✗ | ✗ | N/A |
How applications use it
import boto3
s3 = boto3.client(
"s3",
endpoint_url="https://relayer.example.com",
aws_access_key_id="AKIA...",
aws_secret_access_key="...",
region_name="us-east-1",
)
# Expire objects under a prefix after 90 days; expire noncurrent versions after 30
s3.put_bucket_lifecycle_configuration(
Bucket="my-bucket",
LifecycleConfiguration={
"Rules": [{
"ID": "expire-staging-90d",
"Status": "Enabled",
"Filter": {"Prefix": "staging/"},
"Expiration": {"Days": 90},
"NoncurrentVersionExpiration": {"NoncurrentDays": 30},
}]
},
)
# The response echoes x-amz-expiration when an enabled rule matches
resp = s3.put_object(Bucket="my-bucket", Key="staging/build-4821.tar.gz", Body=data)
print(resp["ResponseMetadata"]["HTTPHeaders"].get("x-amz-expiration"))
# Round-trip the config back
cfg = s3.get_bucket_lifecycle_configuration(Bucket="my-bucket")
print(cfg["Rules"])aws s3api put-bucket-lifecycle-configuration --bucket my-bucket \
--lifecycle-configuration file://lifecycle.json \
--endpoint-url https://relayer.example.com
aws s3api get-bucket-lifecycle-configuration --bucket my-bucket \
--endpoint-url https://relayer.example.com
aws s3api head-object --bucket my-bucket --key staging/build-4821.tar.gz \
--endpoint-url https://relayer.example.comUse cases
Build artifacts, upload scratch space, or ETL intermediates deleted N days after write with no cron job.
Expire build outputs after a fixed retention window, keyed by prefix (e.g. ci/branch-name/).
Expire logs after a compliance- or cost-driven number of days.
Noncurrent-version expiration prevents unbounded version accumulation from inflating stored bytes.
Paired with the background multipart reaper described on the core object operations page.
Applications that lean on it heavily
Can drive bucket lifecycle configuration directly (rclone backend commands) as part of a retention pipeline.
Their own forget/pruning policies pair naturally with S3-side noncurrent-version and expiration rules as a second, storage-enforced safety net.
XNS's own audit-log-to-Loki path (NDJSON sink + Alloy tail) is exactly the kind of write-once, expire-later workload this mechanism targets.
What’s out of scope here
There is one distributed erasure-coded tier; a lifecycle rule can expire or clean up noncurrent versions, but it cannot move an object to a “colder” class because no second class exists. If a workload specifically needs S3-Glacier-style tiered storage economics, that's a different architecture than this gateway offers today.
FAQ
Does XNS support S3 lifecycle expiration rules?
Yes. GetBucketLifecycle/Put/Delete are real, DB-backed handlers with an execution sweep, plus an x-amz-expiration response header on PutObject and HeadObject when an enabled rule matches.
Can I move an object to a cheaper storage tier with a lifecycle rule?
No — storage-class transitions are not applicable to this architecture. XNS runs one distributed erasure-coded tier (80 data + 40 parity shards across up to 120 hosts, by corp deployment convention) rather than multiple storage classes, so there is no colder tier to transition into.
Does lifecycle expiration work on versioned buckets?
Yes, including noncurrent-version expiration, which is a real, conformance-tested handler distinct from current-version expiration.
The lifecycle and tiering rows above are one section of the full S3 compatibility matrix — object operations, buckets, versioning, encryption, access control, and replication all get the same treatment.
Explore the platform
Everything you need to go from evaluation to production.