Vaultlier

FAQ

Short answers to the questions that come up most often.

How is this different from .env?

With .env the secret values live in a file on disk and in version-control-adjacent places. With Vaultlier, your repo holds only metadata — which keys exist and their types — while the values stay encrypted in the portal and are resolved in memory at runtime. You also get typing, per-environment values, versioned history, and role-scoped access.

Is the project id a secret?

No. The project id (prj_…) is a public identifier and is safe to commit. Reading or writing a project always additionally requires a valid API key, so the id alone grants nothing.

What does audit AI send?

Nothing is sent by default. vaultlier audit is a local scan unless you pass --ai. With --ai, the CLI sends sanitized audit metadata to the hosted analyzer: scores, framework names, finding titles, severities, paths, and recommendations. It does not upload source files, .env contents, or secret values.

Where are my secrets stored?

By default, encrypted in Vaultlier's managed store. Per project you can switch to a bring-your-own backend — your own S3 bucket or Postgres database — and the values live in infrastructure you own. Either way Vaultlier encrypts every value before it is stored, so the backend only ever holds ciphertext. See Storage backends.

Does it work offline?

Schema operations degrade gracefully: pull without an API key uses local metadata and regenerates the typed client when the project opted into one. Resolving secret values at runtime requires network access to the portal.

Can I init without an API key?

Yes. Press Enter at the API-key prompt during init. You can add a key later:

Terminal
vaultlier config set apiKey=vlt_live_...
# or set it in the environment
export VAULTLIER_API_KEY=vlt_live_...

Can I self-host the portal?

Yes. Point the CLI and SDK at your deployment with --api-url / VAULTLIER_API_URL (CLI) or the baseUrl client option (SDK). See Installation.

A self-hosted portal must set VAULT_MASTER_KEY in its server environment — the 32-byte base64 key it uses to seal and unseal secret values. Generate one with vaultlier generate-key, set it once, and keep it safe.

This is enforced at startup: a portal launched without a valid VAULT_MASTER_KEYfails to boot with a clear error rather than serving broken secret operations. If the server is already running and the key is missing, the variables page shows a "Vault not configured" notice and stays read-only until the key is set. The key is read only server-side — it is never created, shown, or sent to the browser. Treat it like a root credential: changing or losing it makes existing sealed secrets unrecoverable. See Security.

How do I rotate an API key?

Create a new key in the portal, deploy it via VAULTLIER_API_KEY, confirm it works with vaultlier config verify, then revoke the old key. Revocation is immediate. More in API Keys.