Why Every Object Deserves a Lifecycle: Building Greener Storage with DTZ ObjectStore

created: Thursday, Nov 6, 2025

Introduction

In cloud development, we often treat storage as infinite. Every log, backup, or dataset we create is preserved indefinitely - not because it’s always useful, but because deletion feels risky. Yet this mindset quietly drives up both cost and carbon impact.

The truth is: most stored objects should not live forever. From transient build artifacts to temporary exports and short-lived analytics datasets, much of the data we produce has a natural lifespan. The challenge lies in aligning that lifecycle with our systems.

At DownToZero.Cloud, we designed DTZ ObjectStore around this principle. It’s not just about storing data efficiently - it’s about storing it responsibly.

The Problem with Perpetual Storage

Every object in the cloud consumes more than disk space. It uses:

Energy to stay on spinning disks or SSDs
Cooling to maintain data center environments
Metadata overhead to keep it indexed, replicated, and backed up

This ongoing activity continues even for data that’s never accessed again. In essence, our storage has a carbon shadow - and unmanaged data lifecycles make it grow larger over time.

Designing with Time in Mind

One of the core Green Software Patterns is Data Lifecycle Management - ensuring that digital resources align with real-world relevance.

In practice, that means:

Defining time-to-live (TTL) policies for each object class
Automating the removal or archival of obsolete data
Treating deletion as an act of optimization, not loss

When you apply this pattern, the benefits extend beyond sustainability:

Reduced operational cost through automatic cleanup
Simpler data governance with predictable retention
Improved system performance as metadata and index sizes shrink

How DTZ ObjectStore Makes Lifecycles First-Class

The DTZ ObjectStore service is built with lifecycle management at its core. Unlike traditional storage systems where TTLs are an afterthought, DTZ embeds this capability into the object creation workflow.

1) Per-Object TTL via HTTP Headers

Attach a TTL when you upload. Use either relative duration (X-DTZ-EXPIRE-IN) or an absolute timestamp (X-DTZ-EXPIRE-AT). Supply your API key as X-API-KEY.

Base URL: https://objectstore.dtz.rocks/api/2022-11-28

Upload with a 24-hour TTL (duration):

curl -X PUT \
  "https://objectstore.dtz.rocks/api/2022-11-28/obj/logs/builds/2025-11-05.json" \
  -H "X-API-KEY: $DTZ_API_KEY" \
  -H "X-DTZ-EXPIRE-IN: P1D" \
  --data-binary @build-output.json

Upload that expires at a fixed time (RFC-3339):

curl -X PUT \
  "https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
  -H "X-API-KEY: $DTZ_API_KEY" \
  -H "X-DTZ-EXPIRE-AT: 2025-12-01T00:00:00Z" \
  --data-binary @report.csv

2) Reading, Inspecting, and Listing Objects

Download an object:

curl -s \
  "https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
  -H "X-API-KEY: $DTZ_API_KEY" -o report.csv

Check metadata (including server-computed expiration):

curl -I \
  "https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
  -H "X-API-KEY: $DTZ_API_KEY"
# Look for headers like:
# X-DTZ-EXPIRATION: 2025-12-01T00:00:00Z

List objects by prefix:

curl -s \
  "https://objectstore.dtz.rocks/api/2022-11-28/obj/?prefix=logs/builds/" \
  -H "X-API-KEY: $DTZ_API_KEY" \
  | jq .
# Response includes per-object fields like key, size, lastModified, and expiration.

Delete early (if needed):

curl -X DELETE \
  "https://objectstore.dtz.rocks/api/2022-11-28/obj/exports/report.csv" \
  -H "X-API-KEY: $DTZ_API_KEY"

3) Energy-Aware Cleanup

The deletion of every object is split into two phases. When an object reaches its expiration time, it is no longer accessible through the API, but it remains present in the storage system (and is not billed at that point). The actual deletion is scheduled in batches during low-carbon time windows to minimize the footprint of background jobs - turning lifecycle enforcement into a sustainability lever, not just an ops task.

From Policy to Practice

Lifecycle isn’t about deleting recklessly - it’s about designing with purpose. Patterns that work well:

Build artifacts → expire after CI/CD completion
Analytics exports → expire after delivery or ingestion
User uploads → expire after inactivity
Caches & transient datasets → short default TTLs

Define the rules once and let the system continuously optimize itself - consuming less, costing less, and doing more with the same energy envelope.

The Shared Goal: Sustainability by Design

Object lifecycle management directly reflects the Green Software ethos: delete unused storage resources and set retention policies by default - a small, intentional act of stewardship that scales.

At DownToZero.Cloud, this is where good engineering meets good citizenship. Our mission is to empower developers to design for zero waste - where data lives only as long as it needs to, and no longer.

GitHub Actions Integration

Object lifecycle management integrates seamlessly into CI/CD pipelines. DTZ provides dedicated GitHub Actions for uploading and downloading objects with built-in expiration support:

objectstore-upload - Upload build artifacts, logs, or any file with optional TTL
objectstore-download - Retrieve objects from ObjectStore in your workflows

Example: Upload a build artifact with 30-day expiration

- name: Upload build artifact
  uses: DownToZero-Cloud/objectstore-upload@main
  with:
    api_key: ${{ secrets.DTZ_API_KEY }}
    name: build.zip
    expiration: P30D

This makes it effortless to apply lifecycle policies directly in your deployment workflows - ensuring temporary artifacts don’t accumulate indefinitely.

Conclusion

Storage should be dynamic, not static.

By embedding lifecycle awareness into your architecture, you reduce cloud waste and embrace a pattern of sustainable design that benefits the planet, your platform, and your users alike.

DTZ ObjectStore turns this principle into practice - giving every object a story, a purpose, and, most importantly, an end.