The problem most indie developers ignore until it’s too late

You’re building your first product. You grab API keys from dashboards, paste them into .env files, and push to GitHub. It works. It feels fine. Then someone finds your keys in a public repo, spins up resources on your cloud account, and suddenly you’re reading incident response threads at 2 AM.

This isn’t hypothetical. Leaked credentials are consistently among the top root causes of security incidents for small projects. For solo founders and indie developers, the stakes are personal — one breach can mean lost revenue, damaged reputation, and the kind of cleanup work that derails months of progress.

The good news: you don’t need an enterprise security team to protect your secrets. You need to understand the spectrum of options and pick the one that matches your actual risk level.

What secrets management actually is

Secrets management is the practice of securely storing, accessing, and controlling sensitive credentials — API keys, database passwords, encryption certificates, SSH keys, and tokens — throughout their lifecycle. Instead of hardcoding them in your repository or passing them through Slack and email, a secrets management approach centralizes them, injects them into your application at runtime, and gives you visibility into who accessed what and when.

The core problems it solves are straightforward:

  • Hardcoded secrets in source code — the most common leak vector. Once a key is in a repo, it’s in the history forever, even after you delete it.
  • Secrets sprawl — credentials scattered across .env files, config folders, CI/CD variables, and developer machines make it nearly impossible to track what exists or rotate them when needed.
  • Overly broad access — giving every developer and every service the same level of access to every secret increases your attack surface unnecessarily.
  • No audit trail — without logging, you have no way to know if a secret was accessed unusually or shared outside your team.

The spectrum: from environment variables to dedicated vaults

Not every project needs the same level of secrets management. The right approach depends on your risk profile, your team size, and how much operational overhead you’re willing to absorb. Here’s the spectrum, from simplest to most robust.

Level 1: Environment variables (the baseline)

Environment variables stored in .env files are the default for most indie projects, and they’re not nothing — they keep secrets out of your source code, which is the single most important step. If you’re using them, you’re already ahead of the developers who hardcode keys directly into their code.

But environment variables have real limitations. They live on your local machine and in your deployment environment, which means they’re duplicated across every machine that runs your app. If a developer’s laptop is compromised, their .env file is exposed. If you push a .env file to a repo by accident, it’s in Git history forever. There’s no central control, no rotation mechanism, and no audit trail.

Environment variables are fine for personal projects, early prototypes, and low-risk applications. They become a problem when you’re handling user data, processing payments, or running in production with multiple team members.

Level 2: CI/CD platform secrets

Most deployment platforms — Vercel, Railway, Render, Fly.io — offer built-in secret storage. You add keys in their dashboard, and they inject them into your application at build or runtime. This is a meaningful step up from local .env files because the secrets live in a managed environment with access controls and audit logging.

The trade-off is that you’re tied to that platform. If you move your deployment, you move your secrets manually. Some platforms also limit how many secrets you can store or how you access them programmatically. For a solo founder running one service on one platform, this is often the sweet spot — it removes the hardest problems without adding much complexity.

Level 3: Dedicated secrets managers

This is where you move from “keeping secrets out of code” to “actively managing secrets as a system.” Dedicated secrets managers like Infisical, Doppler, and HashiCorp Vault centralize all your credentials in one place, inject them into your applications through CLI commands or SDKs, and give you features like automatic rotation, fine-grained access controls, and full audit logs.

The main decision here is between managed cloud services and self-hosted open-source options.

Managed services (Doppler, AWS Secrets Manager, 1Password for Teams) handle the infrastructure for you. You get a dashboard, SDKs, CLI tools, and integrations with your deployment platform. The cost is monthly pricing per user or per secret, and you’re trusting a third party with your credentials. For most indie developers, the time saved by not managing infrastructure outweighs the monthly cost.

Self-hosted options (Infisical, HashiCorp Vault) give you full control. Your secrets never leave your infrastructure. You can self-host Infisical under an MIT license, which means no vendor lock-in and complete visibility into how your data is handled. The trade-off is operational overhead — you’re responsible for hosting, updating, and securing the secrets manager itself.

Level 4: Dynamic secrets and enterprise patterns

Dynamic secrets — credentials that are generated on-demand and automatically expire — are powerful but belong to a different category of operator. Tools like HashiCorp Vault can generate short-lived database credentials for each service connection, eliminating the need to store static passwords altogether. This is valuable for teams running complex microservice architectures or handling regulated data.

For a solo founder shipping a single application, dynamic secrets are almost certainly overengineering. The complexity of setting up and maintaining a system that generates and rotates credentials on the fly isn’t justified unless you’re already dealing with the problems that dynamic secrets solve.

How to choose without overthinking it

The best secrets management approach is the one you’ll actually use consistently. Here’s a practical framework for deciding:

Start with your risk level. Are you building a personal side project with no user data? Environment variables are sufficient. Are you processing payments, storing user information, or running a public-facing SaaS? You need at least CI/CD platform secrets, and likely a dedicated secrets manager.

Consider your team size. If you’re the only developer, the overhead of a full secrets manager may feel disproportionate. But the moment you bring on a second person or a contractor, centralized secret sharing becomes valuable — no more sharing keys via encrypted email or Slack DMs.

Factor in your deployment complexity. If you’re deploying to one platform, their built-in secret storage is probably enough. If you’re multi-cloud or using Kubernetes, a dedicated secrets manager that works across environments becomes worthwhile.

Don’t ignore the migration path. If you’re currently using .env files, moving to a secrets manager isn’t as scary as it sounds. Most tools provide CLI commands that replace your existing workflow with minimal changes. The goal isn’t perfection — it’s removing the highest-risk practices first.

Common mistakes to avoid

Even when you know better, it’s easy to fall back into bad habits. Here are the most common ones:

Sharing secrets through unsecured channels. Slack DMs, email, and text messages are convenient but insecure. If a secrets manager is available, use it. If not, at minimum use end-to-end encrypted sharing — but that’s a bandage, not a solution.

Reusing the same secret across environments. Your development database password should not be the same as your production password. If a dev environment is compromised, the attacker now has a starting point for your production system. Separate secrets for separate environments.

Over-provisioning access. The principle of least privilege applies to secrets just as much as to anything else. Give each service and each team member only the access they need. A CI/CD pipeline that only deploys your frontend doesn’t need your database password.

Skipping rotation. Secrets that never change are secrets that, once leaked, are compromised forever. Even if you can’t automate rotation yet, schedule periodic changes and update your secrets manager accordingly.

What to do next

If you’re currently hardcoding secrets or storing them in .env files that live in your repository, the first step is simple: move them out of version control. Add .env to your .gitignore immediately. Then evaluate whether your deployment platform’s built-in secret storage meets your needs, or whether a dedicated secrets manager is worth the setup.

For most indie developers, the progression looks like this: .env files → platform secret storage → dedicated secrets manager. Each step removes a real risk without requiring a complete rewrite of your workflow. The goal isn’t to build the most secure system possible — it’s to remove the mistakes that actually cause breaches while you focus on building your product.

FAQ

Do I really need a secrets manager if I’m just one person? If you’re handling any user data, payments, or running in production, yes. The cost of a breach — lost time, cleanup work, damaged trust — far exceeds the monthly price of a secrets manager. If your project is truly personal with no external data, environment variables are acceptable.

Can I use a secrets manager for free? Several options offer free tiers. Infisical has a free tier for up to five users. Bitwarden Secrets Manager offers a free option. Doppler has a free tier with limited features. These are sufficient for solo founders and small teams getting started.

What’s the difference between a secrets manager and a password manager? Password managers like 1Password and Bitwarden are designed for human users — storing login credentials for websites and apps. Secrets managers are designed for applications and services — storing API keys, database passwords, and tokens that programs need to authenticate. Some tools, like 1Password Developer and Bitwarden Secrets Manager, bridge this gap by offering features for both humans and machines.

Should I self-host or use a managed service? Self-hosting gives you full control and avoids vendor lock-in, but requires DevOps effort. Managed services reduce operational overhead at the cost of trusting a third party. For most indie developers, a managed service is the better trade-off unless you have specific compliance or data sovereignty requirements.

How do I rotate secrets without breaking my application? Most dedicated secrets managers support automatic rotation or provide webhooks that trigger rotation on a schedule. If you’re using CI/CD platform secrets, check whether your platform supports automatic rotation. The key is to treat rotation as a regular maintenance task, not an emergency response.

Sources