EnVault Management is a self-hosted platform for backing up databases and restoring them when required. It allows you to register connections to PostgreSQL or MySQL, schedule backups using cron expressions with a defined timezone, and track job executions live directly in the browser. Before executing a real restoration, you can run a dry-run test that verifies network connectivity and schema compatibility without modifying existing tables.

Infrastructure requirements

EnVault Management stores its internal state, including registered connections, schedules, encrypted credentials, and audit logs, in a dedicated control database. This control database requires PostgreSQL 16 or newer due to native advisory locking mechanisms and structured JSONB columns.

EnVault keeps its control plane completely decoupled from the databases it manages. Database credentials are encrypted with authenticated AES-256-GCM before writing to disk, and they are never returned in plaintext to the client application.

Operational guarantees

• Strict privilege separation between administrators and standard operators.
• Hard boundary preventing any production database from being selected as a restore target.
• Immutable audit trail recording every mutation and authentication attempt without allowing deletion.

Every database connection registered in EnVault is assigned to one of three standard environments, specifically production (prod), quality assurance (qa), or development (dev). This separation reflects canonical software engineering practices to isolate credentials and apply distinct operational rules based on data sensitivity.

Production write safeguards

The assigned environment governs what actions can be executed on each connection. EnVault strictly blocks any connection flagged as production from serving as a restore destination. This architectural barrier ensures that manual errors or automated scripts cannot overwrite live production data.

Current immutability and roadmap

In the current release, these three environments are immutable and validated directly by the control plane schema to maintain operational predictability. The development roadmap includes support for custom environments, allowing engineering teams to register specialized tiers such as staging, uat, or sandboxes to match complex deployment topologies.

You can deploy EnVault and its PostgreSQL 16 control database using a declarative composition file. A named volume preserves control data and connection secrets across container recycles.

services:
  control-db:
    image: postgres:16-alpine
    restart: always
    environment:
      POSTGRES_DB: envault_control
      POSTGRES_USER: envault
      POSTGRES_PASSWORD: ${CONTROL_DB_PASSWORD}
    volumes:
      - envault_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U envault -d envault_control"]
      interval: 5s
      timeout: 5s
      retries: 5

  envault-api:
    image: ghcr.io/envault/api:latest
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - CONTROL_DB_HOST=control-db
      - CONTROL_DB_PORT=5432
      - CONTROL_DB_NAME=envault_control
      - STORAGE_BACKEND=r2
      - R2_BUCKET=prod-db-backups
    depends_on:
      control-db:
        condition: service_healthy

volumes:
  envault_data:

The control database schema initializes and migrates automatically when the application starts for the first time. This database stores connections, cron schedules, encrypted credentials, and the immutable audit log.

Every backup streams directly to object storage through multipart transfers while the dump binary executes. This streaming pipeline avoids spooling temporary archives onto the local file system, allowing large databases to back up without filling local ephemeral disks.

Cloudflare R2 provides full S3 protocol compatibility. You can configure the storage driver by specifying the endpoint address, bucket name, and access keys with read and write permissions.

Access to the web interface and protected endpoints is handled by an integrated authentication subsystem that manages sessions using secure cookies with SameSite lax and httpOnly attributes. This configuration blocks token extraction by untrusted browser scripts.

Closed registration model

Because EnVault safeguards enterprise data infrastructure, public self-registration is intentionally disabled. The user interface does not expose public signup forms. The initial administrator account is provisioned automatically during initial system boot through server environment variables.

Operator hierarchy and management

The authorization layer enforces two distinct roles, administrator and operator. Once the platform is operational, authenticated administrators retain sole authority to register additional operator accounts or revoke credentials, preserving an audited access boundary.

Every credential mutation, connection update, scheduled job execution, and authentication event generates an entry in the control database audit table. Database integrity rules prevent updates or deletions on this table, creating an tamper-resistant activity record.

Captured forensic metadata

Each audit entry records the user identifier, username, source IP address, user agent, HTTP method, route, affected environment, ISO timestamp, execution outcome, and a severity rating categorized as low, medium, high, or critical.

Multi-criteria filtering and detailed inspection

The web audit console provides search filters combining user, environment, resource type, execution state, and time ranges. The event detail view exposes sanitized request payloads, query parameters, duration metrics, and storage volumes without leaking sensitive credentials, providing compliance evidence for standards such as SOC 2 and ISO 27001.

Initiates an asynchronous backup job for a registered connection and returns its job identifier immediately, without waiting for the dump stream to finish.

curl -X POST "http://localhost:3000/backups" \
  -H "Authorization: Bearer $ENVAULT_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "connectionId": "b2d4e6f8-1a2b-3c4d-5e6f-7a8b9c0d1e2f"
  }'

Restores a backup archive onto a specified target connection. Sending isDryRun as true verifies connectivity and schema compatibility without altering table rows. Setting isDryRun to false runs the real restore. If the target connection is marked as production, the request is rejected immediately.

curl -X POST "http://localhost:3000/restores" \
  -H "Authorization: Bearer $ENVAULT_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "sourceBackupId": "3f9c2b6e-4b1a-4e9d-9c2f-1a2b3c4d5e6f",
    "targetConnectionId": "b2d4e6f8-1a2b-3c4d-5e6f-7a8b9c0d1e2f",
    "isDryRun": true
  }'

Restore jobs stream progress updates through Server-Sent Events (SSE), delivering real-time execution steps without polling overhead. Connecting to the stream route for a given job identifier provides continuous state transitions until completion.

curl -N -H "Authorization: Bearer $ENVAULT_API_TOKEN" \
  "http://localhost:3000/restores/job_9412/stream"

System alterations persist in the control database audit table. The audit endpoint supports querying event records with filters for environment, resource type, and pagination.

curl -H "Authorization: Bearer $ENVAULT_API_TOKEN" \
  "http://localhost:3000/audit?environment=prod&resourceType=backup&pageSize=25"

The HTTP interface follows standard REST patterns, allowing applications to trigger and monitor backups from any programming language.

Triggering a backup from code

Examples illustrating how to call the backup endpoint using standard HTTP client libraries.

          
            curl -X POST "http://localhost:3000/backups" \
  -H "Authorization: Bearer $ENVAULT_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"connectionId": "b2d4e6f8-1a2b-3c4d-5e6f-7a8b9c0d1e2f"}'
          
        

          
            const response = await fetch('http://localhost:3000/backups', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.ENVAULT_API_TOKEN}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ connectionId: 'b2d4e6f8-1a2b-3c4d-5e6f-7a8b9c0d1e2f' }),
});

const job = await response.json();
console.log(job.jobId);
          
        

          
            import os
import requests

response = requests.post(
    "http://localhost:3000/backups",
    headers={"Authorization": f"Bearer {os.environ['ENVAULT_API_TOKEN']}"},
    json={"connectionId": "b2d4e6f8-1a2b-3c4d-5e6f-7a8b9c0d1e2f"},
)

job = response.json()
print(job["jobId"])
          
        

When deploying multiple EnVault instances behind a load balancer for high availability, the platform guarantees that each scheduled cronjob, retention sweep, and restore runs once. Distributed coordination relies natively on PostgreSQL advisory locks, eliminating the need to maintain separate external memory clusters.

Non-blocking acquisition

Immediately before starting a job, the worker replica calculates a 64-bit numeric key from the connection identifier and job category. It invokes the native pg_try_advisory_lock function on the control database. If another replica already holds the lock, the call returns false non-blockingly, allowing the replica to skip the tick without connection delays.

Release guarantees

The advisory lock remains held strictly during execution and releases inside a guaranteed finalization block when the task finishes, whether it succeeded or failed. If a container stops unexpectedly or a worker crashes, the PostgreSQL engine automatically releases session-level locks as soon as the underlying TCP connection closes.

Each database connection defines an independent retention policy specified in days, allowing teams to keep seven days of backups for ephemeral development environments and three hundred and sixty-five days for production. A background worker periodically inspects the control database to locate dumps whose creation timestamp has surpassed the configured window.

Coordinated two-phase deletion

The pruning procedure runs in two coordinated steps to prevent orphaned files in cloud storage or missing references in the control database. First, it issues deletion commands to the remote object storage bucket, and once removal is confirmed, it purges the corresponding metadata record from the control database.

Non-destructive simulation

To evaluate retention rules safely before applying permanent deletions, EnVault supports running cleanups in simulation mode. This operation evaluates the retention policy and reports the exact list of dumps eligible for removal, their identifiers, and the total storage volume in bytes that will be reclaimed, without removing any data from object storage.