Introduction
Primary intent: informational use case. People searching for “How Teams Use Sealed Secrets” usually want to know how engineering teams actually use Sealed Secrets in production, where it fits in a Kubernetes workflow, and whether it is the right secret management model in 2026.
Sealed Secrets, created for Kubernetes by Bitnami, lets teams store encrypted secrets safely in Git. The controller inside the cluster can decrypt them into standard Kubernetes Secrets. That makes it popular in GitOps setups built with Argo CD, Flux, Helm, and Kustomize.
Right now, this matters more because more startups are moving toward multi-environment Kubernetes deployments, infrastructure-as-code, and auditable CI/CD pipelines. Teams want Git-based workflows without leaking API keys, RPC credentials, WalletConnect project IDs, database passwords, or cloud tokens.
Quick Answer
- Teams use Sealed Secrets to commit encrypted Kubernetes secrets into Git repositories without exposing plaintext values.
- It works best in GitOps workflows with tools like Argo CD, Flux, Helm, and Kustomize.
- The Sealed Secrets controller decrypts data only inside the target Kubernetes cluster using its private key.
- Common use cases include staging and production credentials, internal service tokens, Web3 RPC keys, and CI-managed app configuration.
- It fails when teams need dynamic secret rotation, centralized access policies, or cross-cluster secret portability.
- Many teams later combine it with Vault, External Secrets Operator, AWS Secrets Manager, or GCP Secret Manager for more advanced control.
How Teams Actually Use Sealed Secrets
In practice, teams use Sealed Secrets as a Git-safe wrapper around Kubernetes Secrets. The value is not just encryption. The real value is that secret delivery becomes part of the same deployment workflow as manifests, Helm charts, and app releases.
A typical startup flow looks like this:
- A developer generates a Kubernetes Secret locally
- The secret is encrypted with kubeseal
- The encrypted manifest is committed to Git
- Argo CD or Flux syncs it to the cluster
- The Sealed Secrets controller decrypts it inside Kubernetes
- The app consumes the resulting Secret as env vars or mounted files
This is why teams like it. It fits how they already ship infrastructure.
Real Use Cases
1. GitOps-Friendly Secret Management
This is the most common use case. Platform teams want a full declarative repository where deployments, ingress rules, config maps, and secrets live together.
With Sealed Secrets, they can keep Git as the source of truth without storing plaintext credentials.
- Works well for Argo CD and Flux pipelines
- Useful for reproducible environments
- Helpful for auditability in regulated workflows
When this works: secrets are mostly static and tied to a cluster environment.
When it fails: teams expect Git to be a full secret manager with rotation, leasing, or runtime policy enforcement.
2. Environment-Specific App Credentials
Startups often run dev, staging, and production clusters with different credentials. Sealed Secrets lets each environment carry its own encrypted values.
Examples include:
- PostgreSQL usernames and passwords
- Redis auth tokens
- AWS access keys for app workloads
- Alchemy, Infura, or QuickNode RPC API keys
- WalletConnect Cloud project IDs
- Webhook signing secrets for Stripe, Telegram, or Discord bots
This is especially common in Web3 infrastructure teams that manage indexers, relayers, backend APIs, and on-chain event workers.
3. SaaS and Web3 Backend Deployments
Many crypto-native teams have backend services that interact with both traditional cloud systems and decentralized protocols. They might need credentials for Kafka, Postgres, S3, Cloudflare R2, RPC gateways, or observability tools like Grafana and Sentry.
Sealed Secrets helps these teams keep deployment manifests in one place while avoiding plaintext leakage in GitHub or GitLab.
Typical examples:
- NestJS or Go API services
- Worker services processing blockchain events
- Indexing jobs for Ethereum, Solana, or Base
- Backend nodes that talk to IPFS pinning providers
- Wallet session services using WalletConnect infrastructure
4. Platform Team Handoff Without Sharing Raw Secrets
In some organizations, the security or DevOps lead owns secret values, while application teams own deployments. Sealed Secrets creates a cleaner separation.
The security owner can generate and seal values. App teams can then deploy them through GitOps without ever seeing the plaintext.
This is not perfect isolation, but it reduces unnecessary secret exposure inside the organization.
5. Temporary Simplicity for Early-Stage Startups
Early-stage teams often do not need HashiCorp Vault, Doppler, or cloud-native secret orchestration on day one. They need something simple that works with Kubernetes and Git.
Sealed Secrets is often the first serious step beyond copying env files into CI variables.
That makes sense when:
- The team is small
- The infra is Kubernetes-first
- There are few secrets
- Rotation needs are low
It becomes less effective when the company grows and secret lifecycle complexity increases.
Typical Team Workflow
Example: A Web3 API Team
Imagine a startup running a wallet analytics API with Kubernetes, Argo CD, PostgreSQL, Redis, and Ethereum RPC providers.
They need these secrets:
- Database password
- Redis auth token
- Alchemy API key
- WalletConnect Cloud credentials
- Sentry DSN
The workflow usually looks like this:
| Step | What the Team Does | Why It Helps |
|---|---|---|
| 1 | Create a Kubernetes Secret manifest locally | Keeps format compatible with native Kubernetes |
| 2 | Encrypt it with kubeseal | Turns plaintext into a cluster-bound SealedSecret |
| 3 | Commit the SealedSecret to Git | Makes secret delivery auditable in GitOps |
| 4 | Deploy with Argo CD or Flux | Uses the same release path as other infrastructure |
| 5 | Controller decrypts inside the cluster | Prevents plaintext from living in source control |
| 6 | Pods consume the generated Secret | Application runs with standard Kubernetes semantics |
This workflow is operationally clean. But it still depends on how well the team manages encryption keys, Git access, and secret rotation.
Why Teams Choose Sealed Secrets
- It fits GitOps naturally
- It uses native Kubernetes Secret objects
- It reduces accidental plaintext commits
- It is simple to adopt compared to Vault-heavy setups
- It supports environment-based deployment workflows
For many engineering teams, the biggest benefit is workflow alignment, not cryptography itself. They want secrets to move through the same CI/CD path as everything else.
Where Sealed Secrets Works Best
Sealed Secrets is strongest in these conditions:
- Kubernetes-first teams
- GitOps-driven delivery
- Mostly static secrets
- Small to mid-sized engineering orgs
- Clear cluster boundaries
It is especially practical for startups building:
- DeFi dashboards
- NFT backends
- Wallet infrastructure
- RPC aggregation services
- Data indexing pipelines
- Cloud-native crypto analytics stacks
Where Sealed Secrets Breaks Down
Sealed Secrets is not a universal answer. The trade-offs matter.
1. Secret Rotation Is Clunky
If secrets rotate often, the Git-based resealing process becomes operational overhead. Teams must regenerate encrypted manifests and redeploy.
That is manageable for a few credentials. It is painful for dozens of services.
2. It Is Cluster-Tied by Design
A sealed secret is typically encrypted for a specific controller key. That means portability across clusters is limited unless teams deliberately manage key sharing or migration.
This is good for isolation. It is bad for mobility.
3. It Is Not Runtime Secret Issuance
Sealed Secrets does not provide dynamic credentials, short-lived tokens, or just-in-time database access. Tools like Vault do that better.
If your security model depends on ephemeral access, Sealed Secrets is the wrong core primitive.
4. Git Access Still Matters
Even though data is encrypted, Git repository access still becomes sensitive. Attackers cannot immediately read plaintext, but the repo still contains deployment logic and encrypted secret assets.
Teams sometimes treat encrypted Git data as harmless. That is a mistake.
5. Kubernetes Secrets Are Still Kubernetes Secrets
After decryption, the output is still a regular Kubernetes Secret. That means teams still need to think about:
- RBAC
- etcd encryption at rest
- namespace isolation
- pod access boundaries
- backup exposure
Sealed Secrets protects the Git stage. It does not erase downstream Kubernetes risk.
Expert Insight: Ali Hajimohamadi
Most founders frame Sealed Secrets as a security tool. In reality, it is a deployment workflow tool with security benefits. That distinction matters. If your biggest pain is developer coordination and GitOps drift, Sealed Secrets is often the right answer. If your biggest pain is credential lifecycle, rotation, and policy enforcement, it is usually the wrong foundation. A pattern I see teams miss: they adopt Vault too early for “enterprise security,” then create release friction their team cannot operate. My rule is simple: use Sealed Secrets when secrets change slower than deploys; move beyond it when secrets change faster than teams can safely reseal them.
Sealed Secrets vs Other Secret Management Approaches
| Approach | Best For | Strength | Weakness |
|---|---|---|---|
| Sealed Secrets | GitOps-based Kubernetes teams | Simple encrypted Git workflow | Weak for dynamic rotation |
| HashiCorp Vault | Security-heavy orgs | Dynamic secrets and policy control | Higher operational complexity |
| External Secrets Operator | Teams using cloud secret stores | Syncs from AWS, GCP, Azure, Vault | Adds external dependency chain |
| AWS Secrets Manager / GCP Secret Manager | Cloud-native startups | Managed secret storage and rotation | Less Git-native by default |
| SOPS | Teams wanting file-level encryption | Flexible with KMS, PGP, age | Workflow depends on team discipline |
How Web3 Teams Use It Specifically in 2026
Recently, more blockchain-based applications have adopted Kubernetes for indexers, relayers, transaction simulators, wallet middleware, and API gateways. That makes secret management a bigger issue than it was in earlier “single VPS plus env file” setups.
Common crypto-native secret types include:
- RPC provider credentials
- Bundler or paymaster API keys for account abstraction stacks
- Webhook secrets from exchanges and custodians
- Private service auth for IPFS pinning APIs
- Session service credentials for WalletConnect-based infrastructure
- Read-only signer configs for automation tooling
What teams should not do is use Sealed Secrets as a casual place for long-lived high-value signing keys. Transaction signing material, treasury keys, and validator-grade secrets usually need stronger controls such as HSM-backed custody, MPC, or specialized key management systems.
Best Practices Teams Follow
- Separate secrets by environment rather than sharing one sealed file across dev and prod
- Restrict Git repository access even when using encrypted manifests
- Enable etcd encryption in Kubernetes where possible
- Use RBAC strictly so not every workload can read every Secret
- Document secret ownership so rotation responsibility is clear
- Keep controller key backups secure or recovery becomes difficult
- Avoid storing crown-jewel private keys in standard Kubernetes Secret flows
Who Should Use Sealed Secrets
Good fit:
- Startups with Kubernetes and GitOps already in place
- Platform teams wanting a lightweight encrypted Git workflow
- Web3 backends with moderate secret complexity
- Teams that value auditability and deployment consistency
Bad fit:
- Organizations needing dynamic secrets and frequent rotation
- Teams without Kubernetes operational maturity
- Companies managing highly sensitive signing infrastructure
- Environments requiring deep policy-based access brokering
FAQ
What is Sealed Secrets in Kubernetes?
Sealed Secrets is a Kubernetes tool that lets teams encrypt secret manifests for safe storage in Git. A controller in the cluster decrypts them into standard Kubernetes Secret objects.
Why do teams use Sealed Secrets instead of plain Kubernetes Secrets?
Plain Kubernetes Secrets are only base64-encoded, not safely stored in Git. Sealed Secrets allows teams to keep encrypted secret definitions in source control while staying compatible with GitOps workflows.
Is Sealed Secrets enough for production security?
No, not by itself. It protects secrets in Git, but teams still need Kubernetes RBAC, etcd encryption, namespace isolation, audit controls, and secure secret handling after decryption.
Can Sealed Secrets rotate secrets automatically?
Not in the way Vault or cloud secret managers can. Teams usually need to update the source secret, reseal it, commit it, and redeploy.
Do Web3 startups use Sealed Secrets?
Yes. It is commonly used for infrastructure credentials such as RPC API keys, database passwords, webhook secrets, and internal service tokens in blockchain-based applications running on Kubernetes.
Should teams store wallet private keys with Sealed Secrets?
Usually no for high-value assets. Low-risk automation may use Kubernetes-based secret handling, but treasury keys, validator keys, and sensitive signing material should use stronger systems like HSMs, MPC, or dedicated custody infrastructure.
What is the alternative to Sealed Secrets?
Common alternatives include HashiCorp Vault, External Secrets Operator, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, and SOPS. The right choice depends on whether your priority is GitOps simplicity or advanced secret lifecycle management.
Final Summary
Teams use Sealed Secrets to make Kubernetes secret delivery Git-safe and GitOps-friendly. That is why it remains relevant in 2026, especially for startups and Web3 infrastructure teams shipping through Argo CD, Flux, Helm, and Kustomize.
It works best when secrets are relatively stable, cluster-scoped, and part of a declarative deployment model. It breaks down when organizations need dynamic secret issuance, heavy rotation, or stronger policy controls.
The practical decision is simple: use Sealed Secrets for operational simplicity in Kubernetes-centric teams, but do not confuse it with a full secret lifecycle platform.
