Managing your storage lifecycle¶
How to set lifecycle configuration¶
There are two lifecycle options:
Bucket-defined lifecycle configuration
When creating a bucket, you can specify the default lifetime for the objects stored in it. The ttl parameter is used in the POST bucket and PUT bucket API operations to specify the lifetime of objects within the bucket, measured in days. If the ttl parameter is not specified on bucket (re)creation, its objects will be retained indefinitely. To check bucket’s lifecycle configuration, use GET bucket API operation.
Object-defined lifecycle configuration
When creating an image / object, you can also specify the particular lifetime for it. There is ttl parameter on POST object, PUT object / POST image, PUT image API operations defining object particular lifetime, in days. If the ttl parameter is not specified on object (re)creation, the bucket lifecycle configuration will be applied for object.
Expiration¶
When an object reaches the end of its lifetime based on its lifecycle configuration, it is marked for removal. For S3 storage, removal is carried out using internal TTL-associated lifecycle configuration rules. For local storage, the removal is carried out by running the cleanup process in the background once a day (at 1 am). To prevent conflicts or duplicate cleanup tasks when multiple instances or workers are involved, a lock mechanism is implemented. This ensures that only a single instance or worker is responsible for executing the cleanup process for local storage.
Note
There may be a delay between the expiration date and the date at which object will actually be removed. Both for local storage and for S3.
How to find when objects will expire¶
To find when an object is scheduled to expire, use the HEAD object / HEAD image API operation. These API operations return response headers that provide the date at which the object is no longer retainable.