Secrets Management for Startups: Keep API Keys Out of Code

Every startup eventually builds the same uncomfortable habit. A payment key is pasted into a chat message so a teammate can test something. A .env file gets emailed to a new contractor. A database password ends up hard coded in a script that "will be cleaned up later." None of these feels dangerous in the moment, yet together they are one of the most common ways small companies get breached.

This guide explains how to manage secrets (API keys, database credentials, signing keys and tokens) in a way that suits a small team. You do not need an enterprise security department. You need a few clear rules, a central place to keep secrets, and automation that catches mistakes before they reach production.

What counts as a secret, and why it matters

A secret is any value that grants access to a system or data. The obvious ones are API keys for payment gateways, cloud provider credentials and database connection strings. Less obvious ones include webhook signing secrets, JWT signing keys, OAuth client secrets, SSH keys and the tokens your CI pipeline uses to deploy.

The danger is not only theft. A leaked cloud key can be used to launch expensive compute jobs, a leaked email provider key can be used to send spam under your domain, and a leaked database credential can expose customer records. For companies handling personal data, that also creates legal exposure. Our guide on DPDP Act compliance for Indian startups explains why a preventable credential leak can become a regulatory problem and not just a technical one.

The common ways secrets leak

Before choosing tools, it helps to know where leaks actually happen. In most small teams the list is short and boring:

• Committed to git. A key lands in a repository, sometimes a public one, and stays in history even after the file is deleted.
• Shared in chat or email. Messages are searchable, forwarded and retained for years.
• Baked into client apps. Keys placed in a mobile app bundle or front-end JavaScript can be extracted by anyone who downloads it.
• Printed in logs. Debug logging that dumps request headers or config objects writes secrets to places many people can read.
• Left in old systems. Former employees, retired services and forgotten staging servers keep working credentials alive.
• Copied between laptops. A shared .env file drifts out of date and nobody knows who holds a copy.

A real-world example scenario

Consider a hypothetical early-stage marketplace with four developers. The team stores credentials in a shared document, and each developer keeps a local .env file. When a contractor finishes a three-month engagement, nobody can say with confidence which keys they saw. Rotating everything would take a day of coordinated work, so the team postpones it, and the contractor's access effectively never expires.

Now imagine the same team after a cleanup. Secrets live in a central manager, each environment has its own set of values, and developers receive access through their own identities rather than copied files. When the contractor leaves, an admin removes one account and rotates the two secrets that account could read. The offboarding takes minutes. The difference is not budget or sophistication. It is having one source of truth.

Step-by-step: building a practical secrets workflow

Here is an order of operations that works for most small teams. Each step delivers value on its own, so you can stop at any point and still be safer than before.

1. Inventory what you have. List every secret, where it is used, who can see it and which provider issued it. Searching your repositories, CI settings and cloud consoles usually turns up surprises. Even a spreadsheet of names (never values) is a useful starting map.
2. Scan your repositories and history. Run a secret scanner across all branches and past commits. Anything it finds should be treated as compromised and rotated, not just deleted.
3. Choose a central store. Use the managed secrets service from your cloud provider or a hosted vault. Pick the one that integrates with where your code runs, so applications can fetch secrets at start time using their own machine identity.
4. Separate environments. Development, staging and production should each have different credentials. A developer laptop should never hold production database access by default.
5. Apply least privilege. Give each service only the permissions it needs. A reporting job that reads one table does not need a credential that can drop the database.
6. Remove secrets from code and images. Applications read configuration at runtime. Container images, repositories and build artifacts should contain no live credentials.
7. Add scanning guardrails. Install a pre-commit hook locally, enable your git host's secret scanning, and fail CI builds when a pattern matches. Layered checks catch what any single one misses.
8. Automate rotation. Start with the highest-risk secrets, such as database passwords and payment keys. Many managed stores can rotate credentials on a schedule without downtime when the application reloads them.
9. Log and alert. Record who read which secret and when. Alert on unusual access, such as a production secret read from an unfamiliar location.
10. Write the incident runbook. Decide in advance who rotates what when a leak is suspected, so nobody improvises at 2 a.m.

Choosing where secrets should live

There is a spectrum of options, and the right one depends on team size and risk. Plain environment variables set in your hosting platform are fine for a prototype, but they offer little audit trail. Cloud provider secret managers add access control, versioning and logging with modest effort. Dedicated vault products add dynamic credentials (short-lived passwords generated on demand) and finer policy, at the cost of more operations work.

If your team is small, a cloud-native secret manager is typically the sweet spot. Where you host will influence this choice, and our comparison of Vercel, AWS and self-hosted startup stacks covers how each option handles configuration and access control.

Client-side applications are different

Anything shipped to a browser or phone is public in practice. Never place a secret key in front-end code or a mobile bundle, even if it is obfuscated. Instead, route sensitive calls through your own backend, which holds the real credential and enforces limits per user. Where a provider offers restricted public keys (limited by domain, bundle ID or scope), use those for the client and keep the powerful key on the server.

Secrets in CI/CD pipelines

Pipelines are a favourite target because they hold deployment credentials and run third-party code. A few habits reduce the risk considerably. Prefer short-lived tokens issued through your cloud provider's identity federation instead of long-lived keys stored in CI settings. Scope each token to a single environment and job. Avoid echoing variables in build logs, and mask values where the platform supports it. Finally, restrict who can edit pipeline definitions, because anyone who can change the workflow can often exfiltrate the secrets it uses.

If you are building a mobile or web product with a delivery partner, agree on this early. Our web development services include setting up environments and deployment pipelines so credentials are handled properly from the first release.

Rotation without downtime

Teams avoid rotation because they fear breaking production. The fix is designing for it. Support two valid credentials at once during a transition window: create the new one, deploy applications that use it, then retire the old one. Many providers allow multiple active keys for exactly this reason. Make applications fetch secrets at start or refresh them periodically, so a rotation does not require a code change. Test the process in staging so the first time you rotate is not during an emergency.

Key benefits of doing this well

• Smaller blast radius. Separate, narrowly scoped credentials mean one leak does not expose everything.
• Faster offboarding. Access is tied to identities, so removing a person removes their reach.
• An audit trail. You can answer who accessed what, which matters for customers, auditors and investors. If you are heading toward enterprise sales, this is groundwork for the controls described in our practical SOC 2 guide for B2B SaaS startups.
• Calmer incidents. A rehearsed runbook turns a crisis into a checklist.
• Less developer friction. New teammates get access through their account instead of hunting for the right .env file.

A secret that only one system can read, only for a short time, and only with a logged request is a secret you can afford to lose.

What to do when a secret leaks anyway

Even good teams have accidents, so prepare the response. First, revoke or rotate the credential at the provider. Speed matters because automated scrapers search public repositories continuously. Second, check the provider's usage logs for activity you do not recognise, covering the full window since the secret was exposed. Third, remove the secret from the code and, where appropriate, clean the git history, remembering that this does not undo exposure. Fourth, identify the root cause: was it a missing scanner, a confusing process or a one-off slip? Fix the system rather than blaming the person. Finally, if customer data may have been accessed, involve whoever handles legal and notification duties promptly.

Common mistakes to avoid

• Believing a private repository is a safe place for credentials. Repositories get shared, forked and compromised.
• Using one credential for every environment because it is convenient.
• Rotating a leaked key but forgetting the other places it was copied.
• Logging full request objects that include authorization headers.
• Giving the whole team production access "just in case."

Conclusion

Secrets management is not glamorous, but it is one of the highest-return security investments a small company can make. Start with an inventory, move credentials into a central store, separate environments, add scanners to your workflow and write down what happens when something leaks. Each of those steps takes hours rather than weeks, and together they remove the habits that cause most credential incidents.

If you would like help hardening an existing product or building a new one with secure foundations, the Mavani Solution team can review your current setup and suggest a practical, staged plan.

Frequently Asked Questions

Is it safe to store secrets in environment variables?

Environment variables are a reasonable starting point because they keep secrets out of source code. They are not a complete answer, though. They can leak through crash dumps, debug endpoints and child processes. For production, load them from a managed secrets store at deploy or start time, and limit who can read them.

What should I do if an API key was committed to GitHub?

Treat it as compromised immediately. Revoke or rotate the key at the provider first, then remove it from the repository. Deleting the commit is not enough because the key stays in git history and may already have been scraped. After rotating, review the provider's usage logs for activity you do not recognise.

How often should secrets be rotated?

There is no single correct interval. Many teams rotate high-risk credentials such as database passwords and payment keys on a schedule (for example every 90 days) and rotate any secret instantly after a suspected leak or when someone with access leaves. Automated rotation is better than relying on calendar reminders.

Do small startups really need a secrets manager?

Yes, but it can be lightweight. A managed option from your cloud provider or a hosted vault costs little and removes the biggest risks: shared spreadsheets, chat messages with passwords and .env files copied between laptops. The goal is central control and an audit trail, not enterprise complexity.

How can we stop secrets from being committed in the first place?

Combine a pre-commit scanner on developer machines with a scanner in your CI pipeline and the secret scanning feature of your git host. Layering these catches mistakes that slip past any single check. Pair them with clear team rules on where secrets live.