Cloud secret store sync

Vaultic stays the source of truth; your runtime reads natively from the cloud store with zero Vaultic dependency at runtime. Teams on ECS/Lambda/GKE/App Service already have IAM-native secret injection — this lets you keep that runtime plumbing and let Vaultic manage the contents instead.

Two ways to sync, layered on the same diffing/tagging rules:

• CLI (vaultic push <target>) — manual or CI-triggered, uses ambient cloud credentials, nothing stored.
• Web app (Config Syncs tab) — server-side and automatic, triggers on every secret change, requires Vaultic to hold an encrypted credential.

Both tag every entry they write vaultic:managed = true plus a source tag identifying the originating workspace/project/environment, so a prune pass only ever touches entries Vaultic itself created — untagged entries at the target are never touched, even with prune on.

CLI: vaultic push <target>

vaultic push aws-secrets-manager [--prefix myapp/] [--region ...]
vaultic push aws-ssm --path /myapp/prod/ [--region ...]
vaultic push gcp --project my-project [--prefix myapp-]
vaultic push azure-keyvault --vault my-vault

Auth always comes from ambient cloud credentials — the AWS SDK's default credential chain, GCP Application Default Credentials, or Azure's DefaultAzureCredential chain. The CLI never accepts or stores cloud credentials directly; run it somewhere already authenticated (CI with an OIDC role, a machine with aws configure/gcloud auth/az login done, an IAM instance profile, etc.).

Passing --prune deletes managed entries that no longer exist in the Vaultic environment; without it, the command just reports how many stale entries it would delete.

push aws-secrets-manager

One AWS secret per key.

push aws-ssm

One SecureString parameter per key, under a Parameter Store path.

push gcp

One GCP Secret Manager secret per key.

push azure-keyvault

One Key Vault secret per key. Key Vault secret names allow only letters, digits, and hyphens, so keys like DATABASE_URL are sanitized to DATABASE-URL (the original key is preserved in a tag so listing/pruning still works against your real key names). Two keys that sanitize to the same name (e.g. FOO_BAR and FOO-BAR) will fail the push with an error asking you to rename one.

Web app: automatic sync

The Config Syncs tab on a single environment offers a server-side, always-on version of the same sync: add a target once with a set of cloud credentials, and Vaultic pushes automatically — no cron job or CI step required — every time a secret in that environment changes. See Config Syncs for the full walkthrough (adding a sync, credential fields per target, Sync now, run history).

• Credentials are held by Vaultic, encrypted at rest through the same KMS envelope (workspace KEK → per-config DEK → value) every secret value already goes through — not the ambient-credential-chain posture the CLI uses. This is a materially different trust model, which is why it's a separate, explicit opt-in rather than a flag on the CLI command: you're handing Vaultic a credential capable of writing to your cloud account, not just running the CLI somewhere already authenticated. Credentials are write-only — accepted once when you add or reconfigure a sync, never shown or returned again afterward.
• Trigger: any secret create/update/delete/rollback/rotation in the environment re-arms the sync; a background sweep (checks every ~60s by default, CLOUD_SYNC_INTERVAL_MS) picks it up and pushes. A Sync now button on the config triggers an immediate synchronous push instead of waiting for the next sweep tick.
• Run history reuses the exact same scheduled-task run-history table/UI the workspace's Scheduled page shows for every other background job — each sync's card has a "show history" toggle listing recent runs (change counts, or the error if one failed).
• One config per target per environment — adding the same target again reconfigures it (new credentials/settings replace the old ones; the sync keeps running under the same identity).
• Fires cloudsync.applied / cloudsync.failed on the workspace's webhooks (and the audit log), same as every other write — see CLI: sharing & webhooks.

This is additive to, not a replacement for, the CLI's manual push — use whichever fits: CI/one-off pushes via the CLI, or a standing "always in sync" pipe via the web app.