Version History & Rollbacks

Every time you add or edit a secret in Redenv, a new version is created automatically. No extra commands, no configuration — you get a complete audit trail and instant rollbacks out of the box.

How Versioning Works#

Each secret maintains an array of versions, ordered from newest to oldest:

Every version records four things:

Viewing History#

See all versions of a secret:

redenv history view API_KEY

Output:

Rolling Back#

Restore a previous version:

# Rollback to version 1
redenv rollback API_KEY --to 1

This creates a new version (version 3) with the content from version 1:

To rollback to the immediately previous version, omit the --to flag:

redenv rollback API_KEY
# Equivalent to: redenv rollback API_KEY --to <previous version>

Version Limits#

By default, Redenv stores all versions forever. You can set a per-secret limit to manage storage:

# Keep only the last 10 versions per secret
redenv history limit 10

When the limit is reached, the oldest versions are automatically pruned.

# Check the current limit
redenv history limit --show

# Remove the limit (keep all versions)
redenv history limit --unlimited

Accessing Versions in SDKs#

Fetch specific versions programmatically using the JavaScript or Python SDK.

// Get version 5 by version number
const v5 = await redenv.getVersion("API_KEY", 5);

// Get the previous version (1 version older than current)
const prev = await redenv.getVersion("API_KEY", 1, "index");

// Get the oldest version
const oldest = await redenv.getVersion("API_KEY", -1);

# Get version 5 by version number
v5 = await client.get_version("API_KEY", 5)

# Get previous version
prev = await client.get_version("API_KEY", 1, mode="index")

# Get oldest version
oldest = await client.get_version("API_KEY", -1)

Modes:

Use Cases#

Emergency Rollback#

A newly deployed secret breaks production:

# Immediately restore the previous working value
redenv rollback DATABASE_URL

Applications using the SDK pick up the old value on the next cache refresh (default: 5 minutes).

Audit Trail#

Investigate when and by whom a secret was changed:

redenv history view STRIPE_KEY

Useful for compliance, security audits, or debugging production incidents.

Time Travel for Testing#

Test how your app behaves with an old configuration:

const oldConfig = await redenv.getVersion("FEATURE_FLAG", 5);
// Run assertions against the old value

Storage & Performance#

Redenv vs. Git#

Best Practices#

1. Set reasonable limits — 10–50 versions per secret is usually sufficient
2. Test rollbacks in staging — practice before relying on them in production
3. Backup before bulk operations — use redenv backup before imports or clones
4. Review history after incidents — version metadata helps with root cause analysis