Syncs push secrets from Monopam to the stores applications already read: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager and Kubernetes Secrets. Monopam stays the source of truth; the push is one way.
Applies to | Who can do this |
|---|---|
Monopam v2026.10 | Administrators with permission to manage syncs. |
Figure 1. Secrets → Syncs.
Two kinds of sync
Kind | Where | What it pushes |
|---|---|---|
Credential sync | Secrets → Syncs | Vault credentials (user name and password, SSH keys, secret text), as JSON with all fields or as the password only. It can push again after a credential is saved or rotated. |
Project sync | A project's Syncs button | The resolved secrets of one environment. It can push again whenever a secret in it changes. |
Create a sync
- Click Add New (3) and choose the Destination (1). Enter the destination's access details; they are stored encrypted and shown masked.
- Choose what to push and, for Kubernetes, the Secret type.
- Optionally turn on automatic sync, and Remove from destination to delete pushed secrets when they are removed here.
- Save and run the sync. Last Status (2) shows the result of the last run.
Before every push Monopam reads the destination back. A value changed at the destination is overwritten and recorded as Last Change Outside Monopam. Verify compares without pushing.
On Kubernetes, Monopam replaces or deletes only Secrets it created (label app.kubernetes.io/managed-by: monopam). A Secret with the same name and no label is left alone and the sync fails.
Troubleshooting
What you see | Why | What to do |
|---|---|---|
Failed in Last Status. | Wrong access details, a missing permission at the destination, or a foreign Kubernetes Secret with the same name. | Open the sync to read the error and fix the destination. |
Related
- Projects and environments
- Password rotation and reconcile