The Vault stores environment variables and secrets for your deployments. Each VM gets its own vault, and you can create standalone vaults for shared configuration across your organization.

Vault types¶

Instance-bound vaults are tied to a specific VM. They are created automatically when you provision a VM through the wizard, or manually from the deployments page. Open one by clicking Vault on any VM card.

Standalone vaults live at the organization level. They are not tied to any VM and can be linked later. Navigate to them from Vaults in the sidebar.

Create a vault¶

Standalone vault¶

1. Go to Vaults in the sidebar
2. Click Create Vault
3. Enter a name and optional description
4. Optionally link it to a project
5. Click Create

Instance-bound vault¶

Instance-bound vaults are created automatically when you provision a VM. You can also create one manually from the deployments vault page for any existing VM that does not yet have a vault.

Add entries¶

1. Open a vault
2. Click Add Entry
3. Enter a key (valid environment variable name: letters, numbers, underscores, starting with a letter or underscore)
4. Enter a value
5. Configure options:

1. Click Save

Edit an entry¶

1. Click the Edit icon on any entry row
2. Modify the key, value, or options
3. Click Save

For secrets, the edit form reveals the decrypted value. The value is re-encrypted on save.

Delete an entry¶

1. Click the Delete icon on an entry row
2. Confirm the deletion

Bulk import¶

You can import multiple entries at once from .env-formatted content.

1. Open a vault
2. Click Import
3. Paste .env-formatted content, one KEY=value per line
4. Preview the parsed entries
5. Confirm to create all entries at once

Maximum import size: 64 KB.

Auto-populate from your repository¶

JuhJuh can scan your connected repository and detect environment variables automatically.

1. Click Auto-Populate on any vault
2. JuhJuh analyzes your repository's configuration files, container definitions, and application settings
3. Detected variables are added as entries with descriptions and metadata inferred from the source

Auto-populate detects variables from:

• Environment example and template files
• Container configuration files and their environment sections
• Container image build directives (ENV and ARG)
• Application settings files that read from the environment

Each detected entry is classified automatically. Keys containing words like SECRET, PASSWORD, or TOKEN are marked as secrets. Keys containing URL, HOST, or DATABASE are marked as required. You can adjust any of these after import.

Validate¶

Click Validate to check that all required entries have non-empty values. Missing or empty keys are highlighted so you can fill them in before deploying.

Validation also runs automatically at the start of every deployment. If any required entries are missing, the deployment stops before anything is pushed to the VM.

Versioning¶

Every change to a vault entry increments the vault's version number. The version counter powers two things:

• Conflict detection. If two team members edit the same vault concurrently, the second save detects the version mismatch and prevents a silent overwrite.
• Drift tracking. After a deployment, you can compare the current vault version against the snapshot captured at deploy time to see what changed.

Snapshots¶

Every deployment captures an immutable snapshot of the vault at deploy time. Snapshots give you three capabilities:

View a snapshot. Open any past deployment and click Vault Snapshot to see the exact environment variables that were active during that deployment.

Compare snapshots. Select two deployments and view a side-by-side diff. Added keys, removed keys, and changed values are highlighted. Secret values are masked in the diff view.

Restore from a snapshot. Roll a vault back to the state captured in any past snapshot. This overwrites current entries with the snapshot's values and increments the vault version.

Snapshots are immutable. A restore creates new entries from the snapshot data; the original snapshot is never modified.

Drift detection¶

After a deployment, any changes you make to the vault create drift between the live vault and the last deployed snapshot. You can check for drift in two ways:

• Dashboard. The vault page shows a drift indicator when the current version differs from the last snapshot.
• CLI. Run juhjuh vault diff <vm-name> to see added, removed, and changed entries. See the CLI vault commands for details.

Drift detection helps you decide when to redeploy. If the vault has changed since the last deployment, those changes are not yet active on the VM.

Config-as-code¶

Define vault variable declarations in your JuhJuh File to keep secret requirements versioned alongside your infrastructure:

yaml vaults: app-vault: variables: SECRET_KEY: description: Application secret key required: true DATABASE_PASSWORD: required: true secret: true files: ssl-cert: path: /etc/ssl/certs/app.crt description: SSL certificate file

This declares which variables and files a vault should contain. Actual secret values are never stored in the file. Set them through the dashboard or CLI.

Run juhjuh vault import <vm-name> to sync these declarations to the server. The import command supports several options:

Variables can reference local environment variables with the ${from_env} placeholder:

yaml vaults: app-vault: variables: DATABASE_URL: value: "${from_env}" is_secret: true description: Primary database connection string

When you run juhjuh vault import, JuhJuh reads the value of DATABASE_URL from your local environment and pushes it to the server vault.

See the JuhJuh File vaults section for the full specification.

How vaults connect to deployments¶

Deployments reference a vault by name. When a deployment runs:

1. JuhJuh validates that all required vault entries have values
2. An immutable snapshot of the vault is captured
3. Vault secrets are injected into the VM at deploy time, and your application picks them up as environment variables
4. File-type entries are written as files at the paths you specified

Services that use envFrom groups in your JuhJuh File receive both clear-text variables and secret values from the vault automatically. You do not need to list each variable individually in the service definition.

yaml deployments: production: vm: prod-vm image: myapp vault: app-vault services: - web - worker

The vault field references the vault by name. If the vault does not exist yet, create it through the dashboard, CLI, or config-as-code import before deploying.

Export¶

Export a vault's entries in .env format for local development or backup:

```bash

Print to stdout¶

juhjuh vault export production

Save to a file¶

juhjuh vault export production --output .env.local ```

Exported files are written with restricted permissions (owner read/write only). See the CLI vault commands for all export options.

Delete a vault¶

Standalone vaults can be deleted from the vault list page. Click Delete on the vault card and confirm.

Instance-bound vaults are removed when the associated VM is destroyed.

Related¶

• Infrastructure Overview: how vaults fit into the broader infrastructure model
• VMs: each VM gets an instance-bound vault automatically
• Deployments: vault snapshots are captured at deploy time and secrets are injected into the VM
• JuhJuh File: define vault declarations and envGroups that reference secret values
• Resources: connect external services whose credentials are stored in vaults
• CLI: manage vault entries, import declarations, export configs, and check drift from your terminal