Google Secret Manager alternative: Crunu vs GCP
Crunu vs Google Cloud Secret Manager: what CMEK changes and what it doesn't, who decrypts, IAM and Workload Identity for CI, audit logs, rotation and pricing.
The difference in brief
Google Secret Manager decrypts values for any principal IAM allows, with a key it owns or your CMEK key in Cloud KMS, and suits workloads on Google Cloud. Crunu encrypts on your devices, its server never holds a key, and it serves laptops, servers and CI anywhere. CMEK changes who controls the key, not who decrypts.
Google Secret Manager is the better pick when
- Your workloads run on Google Cloud and should read secrets through IAM and service accounts.
- You want replication across Google Cloud locations and the Secret Manager add-on for GKE.
- Monthly free usage covers your volume and you want nothing new to operate or buy.
Crunu is the better pick when
- The store should never decrypt your values, even with a key you manage in Cloud KMS.
- Your team's .env files, laptops and CI pipelines live outside Google Cloud, or across clouds.
- Removing someone should rotate environment keys and list exactly which values to reissue.
Google Secret Manager and Crunu, property by property
The same 14 questions we ask of every tool, answered from Google Secret Manager’s own pages and from what Crunu does today. Yes is not always better: read the note.
- Yes
- documented and available
- Partial
- with limits: on some plans, in preview or by hand
- No
- not offered
- n/a
- doesn’t apply, or isn’t documented publicly
| Property | Google Secret Manager | Crunuour product | What it changes for you |
|---|---|---|---|
| Decrypted only on your devices | Google Secret ManagerNoSecret Manager decrypts with a key it owns, or your CMEK key in Cloud KMS, when an authorized user reads. cloud.google.com · | CrunuYesValues are encrypted and decrypted only in the browser and the crunu agent. crunu.com/security · | If values are decrypted only on devices you control, a breach of the vendor’s servers doesn’t expose them. |
| Server handles plaintext values | Google Secret ManagerYesThe service decrypts values for any authorized principal; by default it owns the key-encryption key. cloud.google.com · | CrunuNoThe server holds no decryption key at any point. It still sees metadata such as names, emails and timestamps. crunu.com/security · | Whoever runs a server that handles plaintext, and anyone who breaks into it, could read what passes through. |
| Runs on your own infrastructure | Google Secret ManagerNoA managed Google Cloud service. cloud.google.com · | CrunuPartialEnterprise plan only, under a signed agreement: your own server on Docker, Cloudflare Workers, Vercel or Google Cloud Run. crunu.com/self-hosting · | You decide where the data lives and who operates the service. Several tools, Crunu included, offer this only on an enterprise plan. |
| Source code published | Google Secret ManagerNoA managed Google Cloud service; its source is not published. cloud.google.com · | CrunuNoSource code is not published. crunu.com/security/threat-model · | Published code can be read and audited by anyone, and kept running if the vendor changes course. |
| CI signs in with OIDC | Google Secret ManagerYesWorkload Identity Federation lets GitHub Actions, GitLab and other pipelines use their OIDC tokens. cloud.google.com · | CrunuYesService tokens bound by OIDC to repository, branch and environment on GitHub Actions, GitLab CI, Bitbucket or any issuer. crunu.com/features/ci-cd · | Pipelines get short-lived access tied to the repository, instead of a long-lived token stored in CI settings. |
| Keys change when someone leaves | Google Secret Managern/aNot applicable: users never hold the keys; the service decrypts on access. cloud.google.com · | CrunuYesRemoving a member rotates the keys of every environment they could read and lists values to reissue. crunu.com/features/offboarding · | When people hold decryption keys, removing access is complete only once those keys are replaced. |
| Separate key per environment | Google Secret ManagerPartialEach version gets its own data key; separate CMEK keys per secret are your choice. cloud.google.com · | CrunuYesEach environment has its own key, sealed separately to each recipient's public key. crunu.com/features/access-control · | With a key per environment, access to development can’t turn into access to production. |
| Audit log | Google Secret ManagerYesCloud Audit Logs: Admin Activity logs, plus Data Access logs for reads. cloud.google.com · | CrunuYesHash-chained organization log with one-click verification and JSONL export, kept 365 days by default. crunu.com/features/audit-log · | A record of who changed or fetched what tells you what a person or machine could have seen. |
| Links for people without an account | Google Secret ManagerNoAccess is granted through IAM; no share-link feature is documented. cloud.google.com · | CrunuYesLinks for people without an account; the key stays in the URL fragment. Expiry, view limit and password. crunu.com/features/access-links · | Contractors and one-off handovers get a value without it staying in chat history. |
| Free plan or free to use | Google Secret ManagerYesMonthly free usage for active secret versions and access operations. cloud.google.com · | CrunuYesFree during early access. crunu.com/pricing · | A small team can start with real projects before anyone signs a contract. |
| Syncs values into other platforms | Google Secret ManagerNoReplicates secrets across Google Cloud locations; pushing to other platforms is not documented. cloud.google.com · | CrunuNoNo built-in sync to other platforms. CI can push values with crunu run as a recipe. crunu.com/integrations · | Pushing values into clouds and CI saves copying by hand, but the syncing service has to read them. |
| Dynamic secrets | Google Secret ManagerNoRotation sends scheduled notifications; creating new values is up to you. cloud.google.com · | CrunuNoNot offered by design: generating credentials on demand needs a key on the server. crunu.com/security/limitations · | Credentials created on demand and revoked after a lease limit how long a leaked one works. |
| SSO and SCIM | Google Secret ManagerPartialSAML or OIDC sign-in through Workforce Identity Federation, which needs no user sync; its SCIM covers Gemini Enterprise only. cloud.google.com · | CrunuNoNo SSO or SCIM. People sign in with a password, a Secret Key and an optional second factor. crunu.com/features/access-control · | Sign-in and provisioning from your identity provider make joining and leaving one step. |
| Kubernetes integration | Google Secret ManagerYesSecret Manager add-on for GKE mounts secrets as volumes in pods. cloud.google.com · | CrunuNoNo Kubernetes operator, Helm chart or CSI provider. crunu.com/integrations · | An operator or CSI driver delivers values into clusters without custom glue code. |
Comparison in detail
On this page
Google Secret Manager decrypts your secrets inside Google Cloud for whoever IAM lets through; Crunu's server never holds a key that could. Secret Manager is Google Cloud's managed service for secrets and credentials: IAM decides who may read a secret, each version is encrypted with its own data key, and you can bring your own key in Cloud KMS. Crunu is a team vault for environment variables, cloud credentials and API keys, encrypted on your devices and delivered to laptops, servers and CI pipelines in any cloud.
One question comes up first: does a customer-managed encryption key, or CMEK, keep Google out? Google's own documentation answers it, and the answer shapes the rest of this comparison: with CMEK you control the key, but Secret Manager still uses it to decrypt on your behalf.
Who each one fits
Google Secret Manager fits teams whose workloads run on Google Cloud and can read secrets through IAM and service accounts, such as services on Cloud Run or GKE. It fits teams that want replication across locations, Cloud Audit Logs in their existing setup, a monthly free usage allowance and no extra vendor.
Crunu fits teams whose secrets travel beyond one cloud project: developers' .env files, servers at several providers, CI on GitHub, GitLab or Bitbucket. It fits teams that want the store to be unable to decrypt values, a key per environment, and a precise report of what a departing person received.
What CMEK changes, and what it doesn't
Secret Manager encrypts each secret version with its own data encryption key. By default, that data key is wrapped by a key-encryption key owned by the Secret Manager service, and the data is decrypted automatically and transparently when an authorized user reads it.
With CMEK, the key-encryption key becomes a symmetric key you manage in Cloud KMS. Google's documentation is explicit about what happens next: the service identity for Secret Manager, rather than the caller, encrypts and decrypts secrets, and Secret Manager calls Cloud KMS every time it performs a cryptographic operation. You gain real control. Disable or destroy the key and the data can no longer be decrypted; a destroyed key makes it unrecoverable. What you do not gain is a store that cannot read your values. Decryption still happens inside Google Cloud, for any principal that IAM allows.
Crunu moves decryption off the server entirely. Values are encrypted before they leave your device and decrypted only where an environment key lives: a teammate's browser, an enrolled server running crunu daemon, or a CI runner with a service token. The server holds ciphertext, public keys and signed access lists, and it never has a key to decrypt a value. A compromised server cannot add itself as a reader, because the access lists are signed by an administrator.
Seeing who read what
Reads of secret values are Data Access audit logs, and Google Cloud keeps those disabled by default for nearly all services, so you need to turn them on before you can answer who accessed a secret. Crunu records every fetch by person, version, time and address from the start. When someone leaves, the member removal flow rotates the keys of every environment they could read and lists the values to reissue at providers. Values they already saw stay valid until you reissue them, as the limitations page explains.
Where Google Secret Manager is stronger
- Native IAM. Workloads on Google Cloud read secrets through service accounts, with nothing stored on the machine. Crunu machines enroll with a code and keep a key of their own.
- Your own key, with a kill switch. CMEK in Cloud KMS lets you disable or destroy the key that protects your secrets. Crunu's keys come from your password and Secret Key, not from a cloud KMS.
- Platform features. Replication across locations, a GKE add-on that mounts secrets as volumes, rotation notifications and Workforce Identity Federation. Crunu has no Kubernetes or SSO support.
- Free usage and no new vendor. A monthly free allowance inside an account you already have. Crunu is a new vendor in early access, with no external audit published.
Moving from Google Secret Manager to Crunu
- Create an account and save your Emergency Kit.
- Create a project for each application and an environment for each stage, for example
payments-apiwithdevelopment,stagingandproduction. - On a trusted computer, run
gcloud secrets versions access latest --secret=STRIPE_SECRET_KEYfor each secret an application uses, and write each result as aKEY=VALUEline in a.envfile. - Drag the files into the matching environments, then delete the plaintext copies.
- Start programs with
crunu run --env payments-api/production -- npm start, and enroll their servers as machines. - Give pipelines service tokens with OIDC binding, in place of their Workload Identity Federation access to Secret Manager.
Replication, rotation notifications and IAM-based reads from Google Cloud services have no equivalent in Crunu. You can keep Secret Manager for workloads inside Google Cloud and move only the team's own environments. If you host your own Crunu server on Cloud Run, on the Enterprise plan, its deploy script keeps the server's configuration secrets in Secret Manager; your team's values stay ciphertext.
Other Google Secret Manager alternatives
The other two big clouds follow the same model. AWS Secrets Manager decrypts each secret with AWS KMS before returning it, and Azure Key Vault decrypts secrets automatically when you read them.
Several tools push values into Google Secret Manager from one central place: Doppler syncs to AWS, GCP and Azure stores, and Keeper Secrets Manager has a one-way sync into all three. HashiCorp Vault is the self-hosted option for teams that want one platform with dynamic credentials across clouds.
If the reason you are looking is who can decrypt, tools that decrypt on the client are the other route: Phase, Bitwarden Secrets Manager and Crunu. The article customer-managed keys: who decrypts? walks through CMEK and its equivalents at AWS and Azure.
More facts, row by row
Details beyond the 14 questions above, as this comparison states them.
| Google Secret Manager | Crunu | |
|---|---|---|
| Where values are decrypted | In the service, transparently, when an authorized principal reads a secret | Only in the browser and the crunu agent. The server stores ciphertext and signed documents. |
| Who holds the key | By default a key-encryption key owned by Secret Manager; with CMEK, your key in Cloud KMS, used by Secret Manager's service identity | Environment keys sealed to the public keys of people and machines; the account key comes from your password and a Secret Key |
| Keys per environment | Each version gets its own data key; separate CMEK keys per secret are your choice | Each environment has its own key, sealed separately to each person and machine allowed to read it |
| Who can read | Principals granted access through IAM roles | People and machines that hold the environment key, with roles Editor, Reader, Specific files and Operator |
| CI sign-in | Workload Identity Federation lets GitHub Actions, GitLab and other pipelines use their OIDC tokens | Service tokens bound by OIDC to repository, branch and deployment environment on GitHub Actions, GitLab CI, Bitbucket Pipelines or any issuer |
| Rotation | Scheduled notifications to Pub/Sub; creating the new value is up to you | Rotates its own encryption keys. Values at providers are reissued by hand, from a checklist. |
| Where it runs | A managed Google Cloud service | Crunu cloud at app.crunu.com; on the Enterprise plan, also your own server on Docker, Cloudflare Workers, Vercel or Google Cloud Run |
| Replication and sync | Replicates secrets across Google Cloud locations; pushing to other platforms is not documented | Not built in. A CI step can push values with crunu run. |
| Audit | Cloud Audit Logs: Admin Activity logs, and Data Access logs for reads, which are off by default | Hash-chained audit log, 365 days by default and extendable, with JSONL export. Values never reach it. |
| Sharing with outsiders | Access is granted through IAM; no share-link feature is documented | Share links to selected files with an expiry, a view limit and a password; the key stays in the link after # |
| Kubernetes and identity | Secret Manager add-on for GKE; workforce sign-in through Workforce Identity Federation | Not available |
| Pricing model | Monthly free usage for active secret versions and access operations, then billed by use | Free during early access in the Crunu cloud; self-hosting on the Enterprise plan |
Sources
Every page this comparison relies on, and the day we last verified it.
- Google Cloud Secret Manager: Encryption · checked October 30, 2026
- Google Cloud Secret Manager: Customer-managed encryption keys · checked October 30, 2026
- Google Cloud Secret Manager: Overview · checked October 30, 2026
- Google Cloud Secret Manager: Access control with IAM · checked October 30, 2026
- Google Cloud Secret Manager: Audit logging · checked October 30, 2026
- Google Cloud Logging: Enable Data Access audit logs · checked October 30, 2026
- Google Cloud Secret Manager: Rotation schedules · checked October 30, 2026
- Google Cloud Secret Manager: Add-on for GKE · checked October 30, 2026
- Google Cloud IAM: Workload Identity Federation with deployment pipelines · checked October 30, 2026
- Google Cloud IAM: Workforce Identity Federation · checked October 30, 2026
- gcloud reference: secrets versions access · checked October 30, 2026
- Google Cloud Secret Manager pricing · checked October 30, 2026
- AWS Secrets Manager: Secret encryption and decryption · checked October 30, 2026
- Azure Key Vault: About secrets · checked October 30, 2026
- Doppler integrations · checked October 30, 2026
- Keeper docs: Sync command · checked October 30, 2026
- Phase security · checked October 30, 2026
- Bitwarden Help: Secrets Manager overview · checked October 30, 2026
Questions about Crunu and Google Secret Manager
Something else? Write to support@crunu.com
Is Crunu an alternative to Google Secret Manager?
Yes, for team secrets that live on laptops, servers and CI pipelines, especially outside Google Cloud. For workloads inside Google Cloud that read secrets through IAM and service accounts, Secret Manager remains the simpler fit, and you can use both.
How do I move from Google Secret Manager to Crunu?
Read each secret with gcloud secrets versions access latest --secret=NAME on a trusted computer, write the values as KEY=VALUE lines into a .env file, drag it into a Crunu environment and delete the plaintext copy. Then start programs with crunu run and give pipelines OIDC-bound service tokens.
Does CMEK stop Google from decrypting my secrets?
No. With CMEK, the key-encryption key is yours in Cloud KMS, but Google's documentation says the Secret Manager service identity, not the caller, encrypts and decrypts secrets. You can disable or destroy the key, which makes the data unreadable for everyone.
Are reads of my secrets logged?
Only if you enable them. Accessing a secret version produces a Data Access audit log, and Google Cloud disables Data Access audit logs by default for nearly all services. Crunu records every fetch by person, version, time and address.
Can I run Crunu on Google Cloud?
Yes, on the Enterprise plan, under a signed agreement. A self-hosted Crunu server can run on Google Cloud Run with Postgres, and it can move to Docker, Cloudflare Workers or Vercel with one archive that holds no plaintext values. See self-hosting.