Which to choose when your app teams need more than GCP-native secret storage
Choose Google Cloud Secret Manager when your secrets serve GCP-only workloads, your governance runs on IAM, and you want the least operating work. Choose self-hosted Infisical when application teams need separate projects and environments, secret syncs to other platforms, a Kubernetes operator that reloads deployments, and a secrets store you control inside your own network. Most of the difference comes down to who manages the access model day to day and whether the secrets must stay in a place you run yourself.
Secret Manager fits a team whose platform sits almost entirely on Google Cloud. Access is granted through IAM bindings on each secret, Cloud Audit Logs record access, and Google operates the service. Its limits show up when developers ask for per-environment dashboards, sync to GitHub or Vercel, or dynamic database credentials. Infisical covers those workflows with a dashboard per project and environment, syncs, secret versioning with point-in-time recovery, and rotation and dynamic secrets for PostgreSQL and MySQL. Its GCP machine identity auth lets GCP workloads log in without static keys. Confirm with the vendor which of these features your edition includes, because the self-hosting documentation says enterprise features such as SSO require an enterprise license.
Three questions should drive the decision. First, do you need SSO for operators, and if so, will you buy the enterprise license that the self-hosting documentation says is required for it? Second, who will patch, back up and upgrade the Infisical deployment, whether that is your platform team, a managed service or a partner such as DeployOpen under a written scope? Third, where must the secret values physically live, and can a regional or data residency rule be met by a self-hosted instance in your own cloud account? If the answers point to GCP-only use with IAM as the only control plane, keep Secret Manager. If they point to shared app workflows across clouds and tools, plan an Infisical pilot against a single application.
Which option fits which scenario
This table matches common team profiles to the better fit between Google Cloud Secret Manager and self-hosted Infisical. Read each row as a condition first, then check the reason before deciding, because the fit usually depends on where workloads run and who must operate the platform.
| Scenario | Better fit | Why |
|---|---|---|
| GCP-only application teams with IAM already governing access | Google Cloud Secret Manager | If every workload runs on GCP and access is already managed through IAM, Secret Manager adds little operating work and keeps access in one place. |
| Multi-cloud teams running on AWS, Azure and GCP | Self-hosted Infisical | Infisical authenticates machine identities with Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth, so one store can serve several clouds instead of one store per provider. |
| Teams that must sync secrets to GitHub or Vercel | Self-hosted Infisical | Infisical provides secret syncs to platforms such as GitHub, Vercel and AWS. Confirm the exact target list in the current documentation before committing to a workflow. |
| Kubernetes-heavy platform teams | Self-hosted Infisical | The Kubernetes operator delivers secrets to workloads and reloads deployments, which reduces custom glue code. Confirm operator behavior against your cluster version and GitOps tooling. |
| Strict data location requirements on a single cloud region | Self-hosted Infisical or Google Cloud Secret Manager | Self-hosted Infisical keeps secret storage in your own accounts or data centers, while Secret Manager stores data in the replica locations you configure. Confirm residency terms with Google and with your own assessor. |
| Teams that need SSO on the self-hosted platform | Google Cloud Secret Manager, or Infisical with an enterprise license | Infisical's self-hosting documentation says SSO requires enterprise licensing, so budget for that license in a quote. Secret Manager uses Google Cloud identity for console and API access. |
| Teams that need built-in dynamic database credentials | Neither alone, evaluate Infisical's dynamic secrets | Infisical offers dynamic secrets for databases such as PostgreSQL and MySQL, while Secret Manager stores static values and relies on your own rotation code. Test the rotation path in a non-production environment. |
| Regulated teams that need a platform they operate themselves | Self-hosted Infisical | Running Infisical in your own infrastructure gives you control over hosting, backups and upgrades, but you take on that operating effort. Ask for the operating scope in a written quote. |
Where the secrets live and who controls them
Secret Manager is a Google-managed service. Google operates the storage, the API and the underlying infrastructure, and your team controls access through Google Cloud IAM, project boundaries and, where you use it, customer-managed encryption keys. The main hosting choice you make is the replication setting for each secret, which determines the regions where secret versions are stored. Replication policy is set per secret, so data residency decisions need to be made at creation time and checked during reviews.
- Replication location: Choose automatic or user-managed replication and confirm which regions hold secret versions for each workload.
- Control plane: Google runs the service, so availability and patching of the platform sit outside your team.
- Identity: Access is granted through IAM roles on secrets or projects, which keeps the model consistent with the rest of GCP.
- Audit: Access and administrative events are recorded in Cloud Audit Logs, which you retain and export under your own policy.
- Encryption keys: Customer-managed keys in Cloud KMS are an option for CMEK-protected secrets, and key custody stays with your team.
Confirm with your Google Cloud account team and current documentation which regions and key options apply to your organization's agreements, and record the replication setting for every production secret.
Infisical Cloud is the vendor's hosted service, and teams can sign up for it for free. The vendor operates the platform, so the hosting, upgrades and availability of the service are handled by Infisical. Your team still controls projects, environments, identities and access policies inside the service. This model suits teams that want a quick start without running servers, but it moves the secret store and its metadata into a third party's environment, which must be reviewed against your data classification and contracts.
- Operator: Infisical runs the hosted control plane, so your team depends on the vendor's operations and incident handling.
- Data location: Confirm where the hosted service stores secrets and metadata, and whether that location meets your residency rules.
- Access model: Project and environment permissions, temporary access and approval workflows are configured inside the service.
- Commercial terms: Ask for the current subscription terms, support levels and data processing terms in writing before onboarding.
- Exit path: Ask how secrets can be exported and in what format, and test it before production use.
Request the vendor's current security documentation and data processing terms, then compare them with your own third-party risk requirements before any production secret is stored.
Self-hosted Infisical runs in your own cloud account, data center or air-gapped network. The supported options include a single Docker container, Docker Compose, an official Helm chart that bundles PostgreSQL and Redis, Linux packages, and AWS or GCP reference deployments. In this model your team owns the database, backups, network controls, key handling and upgrades. That gives full control over location and access paths, and it also means the operating responsibility sits with you or with the implementation partner you engage.
- Deployment target: Choose the account, data center or isolated network where the instance and its database will run.
- Operating responsibility: Your team owns patching, database backup and restore, monitoring and capacity planning.
- Network boundary: Restrict who can reach the API and the database, and decide how workloads in other networks reach secrets.
- Enterprise features: The self-hosting documentation states that SSO and gateways require enterprise licensing, so confirm which features your design needs.
- Upgrades: Plan a tested process for each release, using the published release notes as the source of version changes.
Illustrative example: a regulated team might run the Helm chart inside a private Kubernetes cluster with an external, separately backed-up database, so no secret leaves the network. Confirm the database and backup design with your own architects before adopting it.
Identity and audit decisions drive most compliance reviews. Secret Manager relies on Google identities and IAM roles, with audit records in Cloud Audit Logs. Self-hosted Infisical authenticates machine identities through Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth, and applies RBAC, temporary access and approval workflows. Your auditors will ask how each machine identity is issued, scoped, reviewed and removed, and where the log of each access is kept. The evidence has to come from your systems, and the design has to be documented before the review starts.
- Machine identity: Map each workload to one identity method, such as GCP or Kubernetes auth, and document who approves it.
- Access logs: Confirm where Infisical audit records are stored, how long they are kept, and who can alter them.
- Access reviews: Define how project memberships and machine identities are recertified on a schedule.
- Evidence: Collect configuration exports, role definitions and log samples as part of the control narrative.
- Assurance: DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
Ask your compliance lead which control mapping your assessor expects, then agree the evidence list with them before implementation begins.
The core Infisical repository is licensed under the MIT Expat license. Content in any ee directory falls under a separate license located in ee/LICENSE, and the enterprise features such as SSO and gateways are covered by that separate terms. Legal teams should read both files rather than rely on a summary. Google Cloud Secret Manager is a commercial managed service, billed under Google's terms, so the comparison is between a service contract and a self-hosted deployment that uses an open-source core.
- Core license: The main repository is MIT Expat, which allows broad internal use and modification under its terms.
- Enterprise directories: Anything in an
eedirectory follows the separate license inee/LICENSE, so check it before enabling those features. - Feature dependency: Confirm which features your design needs and whether each one requires an enterprise license.
- Contract scope: Ask the vendor in writing which license terms apply to your deployment model and version.
- Version tracking: Record the release you deploy and review the license file again when you upgrade.
Have your legal team review the repository's license files and the vendor's enterprise terms before any budget or architecture decision depends on them.
What the enterprise license changes for SSO and gateways
Infisical's core repository is MIT licensed, but code in its ee directories falls under a separate license stored in ee/LICENSE, so the license question depends on which features a deployment uses. The self-hosting documentation states that enterprise features, including SSO and gateways, require enterprise licensing. The MIT grant in the main Infisical LICENSE file therefore does not by itself cover those capabilities, and legal and procurement teams should read the ee terms before assuming a free self-hosted deployment includes them.
This matters most when your organization must federate human logins through its identity provider, for example requiring staff to sign in to Infisical with corporate SSO and enforce the same MFA and joiner-mover-leaver rules used for other internal systems. If your access model relies only on machine identities, such as GCP, Kubernetes or OIDC workload authentication, the enterprise license may be less central to the decision. Confirm which identity flows your application teams and platform engineers need on day one, and whether SSO is a hard requirement for audit evidence.
Before committing, ask Infisical in writing which edition includes SSO and gateways, whether the license terms restrict the number of seats or self-hosted instances, how renewals and support are priced, and what happens to features if the license lapses. Treat any answer as current only for the version you plan to deploy, and check the Infisical releases page for the release you are evaluating. Enterprise terms are quoted by Infisical, so build the cost of the license into the total comparison with your own run costs.
What moving application secrets from Secret Manager to Infisical involves
The sequence moves application secrets from Secret Manager into a self-hosted Infisical instance in your own environment, with each workload switched over only after its secrets are verified in the new store.
Inventory secrets, projects and IAM bindings
The platform or security team lists every secret, its versions, labels, the GCP projects it lives in and the service accounts that read it. Application owners confirm which secrets are used by which workload and which are stale. The output is a spreadsheet or export that maps each secret to its consumers, with CMEK-protected and rotation-triggered secrets flagged for separate handling. The step is done when every consuming workload has a named owner and no secret is unassigned.
Deploy Infisical in your environment
Your infrastructure team deploys Infisical with Docker Compose or the official Helm chart, which bundles PostgreSQL and Redis, inside your own cloud account, data center or network. They set up TLS, backups for the database and the encryption key material, and access controls for administrators. Confirm the current release and the self-hosting prerequisites against the Infisical self-hosting overview before you choose a version. The step is done when the instance is reachable only from approved networks and a backup restore has been tested.
Map names and labels to projects and environments
Decide how Secret Manager naming maps to Infisical. Typically an application or service becomes an Infisical project, and development, staging and production become its environments, with folders for grouping. Secret Manager labels that carry ownership or classification move into folder structure or documented naming conventions, since you should not assume they carry over automatically. Write the mapping down and have the owning teams sign off. The step is done when every secret has a target project, environment and path.
Recreate access with machine identities
Replace Secret Manager IAM bindings with Infisical machine identities and RBAC roles. For workloads running on Google Cloud, use the GCP machine identity authentication so a service account proves its identity without a stored credential. For workloads on Kubernetes, use the Kubernetes auth method or the Kubernetes operator, which delivers secrets to pods and can reload deployments. Test each identity against a non-production environment first. The step is done when each workload reads its secrets from Infisical using its own identity and the permissions match the original bindings.
Handle CMEK and rotation functions separately
Secrets encrypted with customer-managed encryption keys need a decision about whether the values are re-created in Infisical from their source systems or copied out before the keys are retired, and this should be reviewed by your security and compliance owners. Pub/Sub rotation functions that call Secret Manager do not move automatically. Decide whether each rotation becomes Infisical rotation or dynamic secrets for supported targets, or stays as custom code. Confirm supported rotation targets in the Infisical documentation. The step is done when every CMEK secret and every rotation function has a written disposition.
Run both stores in parallel
Migrate one workload group at a time, pointing it at Infisical while Secret Manager stays live as a fallback. Compare values read from each store during a monitored window, and watch application logs and error rates for authentication or permission failures. Keep a rollback path that switches the workload back to its original credentials. The step is done when each workload group runs on Infisical for an agreed observation period with no unexplained errors.
Export, verify and delete after cutover
Once a workload is stable on Infisical, retain the exported version history in your approved archive according to your retention policy, then disable and destroy the old Secret Manager versions and remove unused IAM bindings. Confirm the deletion scope with the owners of each secret before running it, because destroyed versions cannot be recovered. Record the evidence (the mapping, the cutover dates and the deletion logs) for your change records. The step is done when no workload references Secret Manager and the evidence is filed.
What drives the cost on each side
Google Cloud Secret Manager bills by usage, so its cost follows how many secrets, versions, reads and rotation events your workloads generate. Self-hosted Infisical moves the cost into infrastructure, database operations, licensing and staff time, most of which recurs after the initial setup.
Secret Manager usage charges
Google bills Secret Manager per active secret version, per access operation and per rotation notification. Each of these drivers grows with how often workloads read secrets, how many versions you keep and how many environments and replica locations you run. Pull the current rates from Google's pricing page and model them against your real counts of secrets, versions and daily reads before comparing. Ask whether replication settings change the bill for your regions.
Infisical software and infrastructure
Infisical itself is MIT-licensed outside its ee directory, so the core platform carries no per-seat or per-secret software fee. The recurring cost is the compute, storage, backups and network path for the Infisical servers in your cloud account or data center, plus high availability if you need it. Size these for peak secret reads from your CI, clusters and workloads, not for average traffic.
PostgreSQL and Redis operation
The self-hosted Helm chart bundles PostgreSQL and Redis, but a bundled database is rarely the production answer. Someone must own backups, point-in-time recovery, minor version patching, failover and capacity planning for both. Decide whether you run them on managed database services in your cloud or on your own clusters, and price that operating work into the comparison.
Enterprise license for SSO
The self-hosting documentation states that enterprise features such as SSO and gateways need an enterprise license, so the MIT core does not cover them. This is the main recurring license line in the comparison. Ask Infisical for a written quote covering the features you need, the number of identities and the support terms, and confirm which of your access requirements depend on those features.
One-time setup and migration
Setup covers architecture, the Kubernetes or VM deployment, identity provider integration, the GCP machine identity configuration and the move of secrets, projects and environments from Secret Manager. These costs are largely one-time, but they are paid in staff hours or partner fees rather than software fees. Agree the scope and deliverables in writing before work starts so the one-time portion stays predictable.
Staff time for upgrades and operations
After go-live, someone must patch the Infisical release line, test upgrades, rotate the encryption and root keys under your procedures, monitor availability and answer access reviews. This recurring effort is often the largest line in a self-hosted budget and it is easy to underestimate. Compare it with the time your team spends today on IAM bindings and rotation code, and decide whether support retainers should cover it.
Questions buyers ask before choosing or hiring help
How much effort does self-hosting Infisical take?
Self-hosting Infisical is a moderate, recurring operations task, and the effort depends mostly on the deployment pattern you choose. Infisical documents several options: a single Docker container, Docker Compose, an official Helm chart that bundles PostgreSQL and Redis, Linux packages, and AWS or GCP reference deployments. A single container suits evaluation, while production use needs a database and cache you can back up, patch and monitor, plus TLS, high availability planning and a tested restore path. Effort rises with the number of environments, the size of your identity and RBAC model, and how often you upgrade. Ask your team to confirm the chosen topology against the Infisical self-hosting overview and to estimate operator hours for patching and upgrades.
Can our team migrate from Secret Manager to Infisical alone?
A team with Kubernetes or cloud operations experience can often run a small pilot alone, but a full migration usually needs someone who understands both secret stores and your workload identities. The hard parts are not the copy itself. They are mapping Secret Manager projects, labels and IAM bindings to Infisical projects, environments and RBAC roles, moving each workload to a GCP machine identity or Kubernetes auth method, and deciding which secrets should be rotated by Infisical instead of your existing Pub/Sub functions. Before deciding, ask whether you have an owner for each application, a test environment and capacity for a staged cutover. DeployOpen can plan and implement this work under a written, fixed scope if you prefer outside help.
How long does a migration take, and what sets the timeline?
The timeline depends on the number of applications, secrets and environments, not on Infisical alone. Each workload needs its identity changed, a staged cutover, and verification that the application reads the right version. Teams with many secrets shared across services, CMEK-protected secrets or complex IAM bindings need more discovery and testing. Ask for a written timeline tied to a scope with named deliverables, and confirm which workloads are in scope. This page does not provide a duration because none was supplied for this migration; the scope conversation is where the figure should come from.
What does the work need from our side?
The work needs four things from your organization: access to the cloud accounts and clusters where the secrets and workloads run, an identity provider for administrator and user sign-in, a named owner for each secret or application, and a change window for cutovers. Cloud access should be scoped to the projects in the migration. The identity provider decides how people log in to Infisical, and that choice affects whether SSO needs a license (see the enterprise question below). Secret owners confirm which values are current, which are obsolete and which should rotate. Without owners, migrations stall at the discovery stage, so agree on these people before the scope is signed.
Does SSO with Infisical require an enterprise license?
Yes, according to Infisical's self-hosting documentation, enterprise features such as SSO and gateways require enterprise licensing. The core repository is MIT licensed, but content in any ee directory falls under a separate license in ee/LICENSE, so read that file before you rely on any enterprise feature. Confirm the current license terms and pricing directly with Infisical, since neither was supplied for this page. Machine identities do not need SSO: they authenticate with GCP, Kubernetes, AWS, Azure, OIDC or Universal Auth. Plan for SSO only if human access through your identity provider is a requirement.
Can Infisical replace Secret Manager rotation functions?
Infisical provides secret rotation and dynamic secrets for databases such as PostgreSQL and MySQL, which can replace custom rotation code that Secret Manager leaves to you. Secret Manager sends Pub/Sub notifications, and your own function performs the rotation. With Infisical, the rotation logic lives in the platform, so you need to confirm which database engines and rotation targets your environment uses. Non-database credentials, such as third-party API keys, may still need custom rotation. Test each rotation with your application restart or reload behavior, and keep the old Pub/Sub functions running until the new rotation is verified.
Does DeployOpen issue certifications for our Infisical deployment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. DeployOpen can plan and implement the self-hosted Infisical deployment, document access controls, backups and logging, and run security testing that supports an assessment. Ask your auditor which evidence they require before scoping the work, and confirm in writing which controls DeployOpen delivers and which remain your responsibility.
Who runs Infisical after the migration is complete?
After go-live, your team usually runs Infisical, and DeployOpen can support it under a retainer. The ongoing work includes upgrades, backups and restore tests, monitoring of the database and cache, access reviews and rotation checks. Upgrades matter because Infisical publishes new releases frequently, so confirm your upgrade cadence and the owner for each release. Ask any provider to put the support model, response expectations and upgrade responsibilities in writing before the engagement starts, since this page does not publish SLAs.
How DeployOpen helps evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Google Cloud Secret Manager to self-hosted Infisical, we start by agreeing on what the platform must cover and what it must not.
How we scope
- We inventory which application teams, projects, environments and GCP service accounts currently read from Secret Manager.
- We document which Infisical features you will use, such as Kubernetes operator delivery, GCP machine identity auth, secret syncs or dynamic secrets, and which need the enterprise license.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Infisical in your environment using the supported self-hosting method that fits your platform, such as Docker Compose, the Helm chart or reference deployments.
- We configure projects, environments, RBAC and GCP machine identity auth so workloads authenticate without static keys.
- We test secret delivery, operator reloads and access approvals against your staging workloads before any production cutover.
How we hand over
- You receive architecture notes, runbooks for backup, upgrades and access requests, and a record of configuration decisions.
- We map each Secret Manager secret and IAM binding to an Infisical project, environment and access policy in a documented table.
- We walk your platform and security teams through operating the system, including how to confirm the enterprise license scope for SSO.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can prepare access logs, configuration evidence and control documentation for your compliance team, while independent auditors issue any assessment outcome.
- We recommend confirming Infisical release notes and self-hosting requirements with the vendor before each upgrade window.
