Lifecycle rules

PUT /v1/buckets/{bucket}/lifecycle replaces the whole configuration. Each rule needs a status and at least one action; a rule with status: disabled stays in the configuration but is skipped during evaluation. Read GET /v1/buckets/{bucket}/lifecycle before changing it. The response contains lifecycle_rules and revision, with the same revision quoted in the ETag header. A bucket with no configuration returns empty rules and revision none. Both PUT and DELETE require an If-Match header containing that quoted revision. Missing headers return 428; stale revisions return 412 with LIFECYCLE_CONFLICT. Reload, review the newer configuration, and reapply your changes deliberately. Wildcards and weak ETags are not accepted.

Console
API
CLI
Go

The bucket’s Management tab has a Lifecycle rules card. Add rule gives you a Prefix filter and the day-based actions: Expire current objects after (days), Expire noncurrent versions after (days) with an optional Always keep newest (versions), and Abort incomplete multipart uploads after (days). Each rule has its own enable switch, and Save writes the whole set.Choose Transition storage class (STANDARD or COLD) and enter Transition after (days) to move objects before they expire. Days must be positive integers and earlier than day-based expiration. Remove transition clears the transition explicitly.Saving preserves fields the card cannot edit, including absolute dates. Entering expiration or transition days replaces that action’s absolute date. Removing a rule or the configuration also removes its preserved fields. If another editor changed the configuration, the console refreshes it and keeps your draft for review. It does not automatically overwrite their changes.

Read the current revision, then replace the configuration:

GET /v1/buckets/{bucket}/lifecycle

PUT /v1/buckets/{bucket}/lifecycle
If-Match: "<revision from GET>"
Content-Type: application/json

{
  "lifecycle_rules": [
    {
      "id": "archive-then-expire",
      "status": "enabled",
      "filter": { "prefix": "logs/" },
      "transition": { "days": 30, "storage_class": "COLD" },
      "expiration": { "days": 365 },
      "abort_incomplete_multipart_upload": { "days_after_initiation": 7 }
    }
  ]
}

basaltic storage bucket get-lifecycle <bucket> --output json
basaltic storage bucket set-lifecycle <bucket> \
  --revision '<revision from GET>' --from-file lifecycle.json

The file contains the lifecycle_rules request body shown in the API tab. Pass the unquoted revision value to --revision; the CLI quotes the header. To remove the configuration, read its current revision and run:

basaltic storage bucket delete-lifecycle <bucket> --revision '<revision from GET>'

client := storage.New(cfg)
current, err := client.GetBucketLifecycle(ctx, bucket)
if err != nil {
    return err
}
// Review current.LifecycleRules before replacing them with rules.
err = client.PutBucketLifecycle(ctx, bucket,
    &storage.PutBucketLifecycleRequest{LifecycleRules: rules},
    basaltic.WithRequestHeader("If-Match", strconv.Quote(current.Revision)))

Import strconv for the quoted header value. Handle 412 by reloading and reviewing; do not retry with a fresh revision automatically.

These preconditions apply to the native API. S3 lifecycle operations retain standard unconditional replacement behavior. An S3 update still changes the revision, so an older native-API edit is rejected.

Action	What it does
`transition`	Moves matching objects to another storage class once they are old enough.
`expiration`	Deletes objects past `days` (from last-modified) or after `date`.
`noncurrent_version_expiration`	Removes non-current versions past `noncurrent_days`, optionally keeping the `newer_noncurrent_versions` most recent.
`abort_incomplete_multipart_upload`	Discards uploads still unfinished `days_after_initiation` later.

Rules are evaluated independently, so an object matching several is subject to all their actions. filter.prefix narrows a rule; an absent or empty filter applies it to the whole bucket.

A transition keeps the object’s identity — same key, same version id, same last-modified — and moves only its bytes. That is what makes pairing a transition with an expiration work: the move does not restart the expiry clock.

Two constraints on transitions, both rejected at write time rather than failing silently later:

A transition must come strictly before the rule’s expiration. Otherwise the object would be deleted before it ever moved.
One transition per rule. With two storage classes a second has nowhere to go. The S3 endpoint accepts a single-element <Transition> list and rejects longer ones rather than applying the first and ignoring the rest.

Get started

Products

Platform

Help

Lifecycle rules

Lifecycle rules

​Lifecycle rules

Lifecycle rules