Pushing Configuration Safely

vault config push makes the target vault match your local workspace.

This guide describes a workflow that makes every push predictable.

1. Pull from the target vault and commit

Start each change from a fresh pull of the vault you will push to, and commit the result to source control before you edit anything:

vault config pull --dns myorg-sandbox.veevavault.com
git add -A
git commit -m "Pull from myorg-sandbox"

The commit records exactly what was in the vault.

2. Make your changes

Edit the files in your workspace, then review your edits:

git diff

To remove a component from the vault, delete its directory, for example components/Picklist/old_status__c/.

3. Preview the push

Run a dry run against the same vault:

vault config push --dns myorg-sandbox.veevavault.com --dry-run

Check the output line by line:

MODIFIED and ADDED lines should match your git diff.
DELETED lines should list only what you meant to remove.
An unexpected MODIFIED line usually means the vault changed since your pull. Pull again, and resolve the difference in source control before pushing.
SKIPPED lines are local files the CLI could not read. They are not pushed.

Vault does not validate the changes during a dry run. A push can still fail for a change that appears in the preview.

4. Push

vault config push --dns myorg-sandbox.veevavault.com

If the push would delete anything, the CLI lists it and asks you to confirm. Answer n if the list is not what you expect.

If one asset fails to deploy, the CLI reports the error, continues with the rest, and exits with code 1. Fix the failing asset and push again. Assets that already deployed show as unchanged.

5. Pull again and commit

After the push, pull from the vault and commit, so your workspace matches what Vault actually stored:

vault config pull --dns myorg-sandbox.veevavault.com
git add -A
git commit -m "Push to myorg-sandbox"

Exclude configuration you do not manage

If some configuration is managed directly in the vault, such as reports or picklists users edit at runtime, add it to .vdxignore. Ignored configuration is never pulled, pushed, or deleted:

# .vdxignore
components/Report/**
components/Picklist/supplier__v/

Pushing to a different vault

You can push the same workspace to several vaults, for example a sandbox and then a validation vault. Each push compares against its own target, so always run the dry run against the vault you are about to push to. Anything in that vault that is not in your workspace will be deleted.

Using `--yes` in CI/CD

--yes approves deletions without a prompt. In a pipeline, run the dry run as a separate, reviewed step before the push:

vault config push --dns myorg-validation.veevavault.com --dry-run
vault config push --dns myorg-validation.veevavault.com --yes

Without --yes, a push that would delete anything exits with code 1 in a non-interactive shell, which stops the pipeline instead of deleting.