Use case
An ephemeral test environment exists for one purpose — a pull request, a performance experiment, a support investigation — and disappears when that purpose ends. The idea is old; what usually goes wrong is the data. Environments are created in seconds, but the data inside them is either a stale shared copy or an unreviewed clone of production that nobody remembers to delete. DataNivra's environment leases tie the life of the data to the life of the environment.
The lifecycle of a lease
A lease moves through a small, auditable set of states: requested, hydrating, ready, releasing and released. It can also end as expired (its time ran out), failed (hydration did not complete and any partial copy is removed) or orphaned (an inventory from your agent found a copy that should no longer exist, which triggers teardown and a high-severity alert).
Every lease has a time-to-live between five minutes and seven days per request, an absolute end of at most thirty days, and at most twenty renewals. Only the lease owner can renew it. The environment's expiry always equals the lease's expiry, and your agent refuses to write after that moment even if a late command arrives.
Release, expiry, failed hydration and orphan detection all use one teardown path: the same idempotent, retried job that removes an expired environment's copies. That matters, because clean-up code that runs rarely is the clean-up code that fails.
Where the data lands
DataNivra never creates infrastructure in your estate and never needs inbound access to it. The target is an environment your administrator registers with a secret reference (for example a vault or Kubernetes secret path); your agent resolves it locally and connects from inside your network. Two target kinds ship in the agent today:
| Target | Hydration | Snapshot and rewind |
|---|---|---|
| Directory (Parquet/CSV files) | written atomically, then renamed into place | supported: content-addressed snapshots with verified rewind |
| PostgreSQL database | tables created and loaded in one transaction | not supported (designed only); requests fail closed |
The repository includes two ready-made patterns for a disposable PostgreSQL target: a hardened Docker Compose project per lease, which has been run live with the agent, and a namespace-per-lease Helm chart with a default-deny network policy and resource quota, which is validated by linting and rendering tests but has not yet been run on a live cluster.
What you get back
- Certified data only. A lease is refused before anything is written unless the dataset version passed its configured policy gates, is unexpired and unrevoked, has complete evidence and a valid signed certificate. Certification means DataNivra-certified against configured policy gates, not a regulatory or third-party certification.
- Evidence without values. State events, certificate id and digest, hydrate and teardown receipts, timings and the CI reference, sealed with a SHA-256 digest.
- Quotas. Live leases per tenant and per user and lease hours per month follow your plan; creates are rate limited per tenant.
What it does not do
- No native database clones. Copy-on-write branches, template-database clones or volume snapshots of any platform are not available; every lease hydrates by loading the certified version.
- No infrastructure provisioning. Containers, databases and namespaces are created by your own tooling (the patterns above are a starting point).
- No compliance promise. A lease limits where and how long test data lives; it does not by itself make a system compliant with any regulation.
Next steps
Read the CI/CD test data use case for the pipeline side, the environments tutorial for how DEV, QA, SIT, UAT and performance differ, and the agent installation guide for setting up the agent that writes your targets. Start free to try the flow in the synthetic sandbox.