**Source URL:** https://limited.veevavault.dev/qualityone/vault-dx/cli/guides/pushing-safely

# Pushing Configuration Safely

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

<Aside type="caution">
This command does not track your local updates or remote changes to your vault since your last pull. Using `vault config push` can overwrite remote changes and delete components, Vault Java SDK classes, and Custom Pages that exist in the vault but not in your workspace.
</Aside>

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:

```sh
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:

```sh
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:

```sh
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

```sh
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:

```sh
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:

```sh
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.

---

**Previous:** [Working with Vault CLI Configuration](/qualityone/vault-dx/cli/guides/working-with-config)  
**Next:** [Manual Downloads](/qualityone/vault-dx/cli/guides/manual-downloads)