Storage backends

By default your secrets live in Vaultlier's managed store. You can instead point a project at your own S3 bucket or Postgres database — the data physically resides in infrastructure you own.

How it works

Configure a backend per project under Settings → Storage backend. Once set, that backend becomes the authoritativestore for the project's secret values. Vaultlier still owns the schema, the encryption, and all access control — only the encrypted blobs move.

Crucially, Vaultlier encrypts every value before it leaves. Your bucket or database only ever receives opaque ciphertext (AES-256-GCM under a per-project key); the master key never leaves Vaultlier. A leak of your store yields nothing usable.

Changing storage requires an organization owner or admin.
Credentials are sealed with the same encryption used for secrets.
Vaultlier tests the connection before saving a backend.

Amazon S3 (and R2 / MinIO)

Each value is written as one object at {prefix}/{projectId}/{env}/{key}/{version}.bin. Provide a bucket, region, and an access key pair scoped to that bucket. For S3-compatible stores (Cloudflare R2, MinIO) also set the custom endpoint.

The credentials need object read/write on the bucket, for example:

IAM policy

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::my-secrets-bucket",
      "arn:aws:s3:::my-secrets-bucket/*"
    ]
  }]
}

Postgres

Provide a connection string. On first write Vaultlier creates a table named vaultlier_secret_blobs holding the ciphertext, nonce, auth tag, and version — never plaintext. The role only needs rights to create that table and read/write its rows.

Connection string

postgresql://vaultlier:••••@db.internal:5432/secrets

Fallback & drift

Vaultlier keeps an encrypted fallback copy of every value in its own database. If your store is briefly unreachable on a read, the runtime transparently serves the fallback so deployments never break. If a write can't reach your store, the value is still saved and the version is flagged as needing resync, surfaced on the settings page.

Configuring a backend applies to new writes. Existing values remain readable from the fallback; re-save them to push them into your store.

Security guarantees

Your store only ever sees ciphertext — plaintext never leaves Vaultlier.
The encryption master key stays Vaultlier-side; your store can't decrypt.
Adapter credentials are encrypted at rest and never returned to the browser.
Storage changes and connection tests are recorded in the audit log.

See Security for the full encryption model and API Keys for how the CLI and runtime authenticate.