Secrets management for startups after shared passwords

Why shared passwords break down

Shared passwords feel harmless when a team has three people and one server. Then the company adds a staging app, a cloud account, a payment dashboard, and a CI pipeline. One password gets reused in several places, and one leak turns into a much bigger problem.

That leak usually does not start with a dramatic hack. Someone pastes a token into chat, drops a database password into a ticket, or saves an API key in a shared note "for later." Once a secret moves through chat, docs, and screenshots, nobody knows where the live copy is anymore. People keep using old values because they are easy to find.

Shared logins also wipe out the trail you need when something breaks. If five people use the same account, you cannot tell who changed a setting, rotated a key, or pulled data they should not have touched. When a deploy fails on Friday night, that missing history wastes real time.

Offboarding is where the mess becomes obvious. A contractor leaves, but the shared admin login stays active because changing it might break production. The team delays cleanup, and the risk sits there. Someone who should have zero access can still get into live systems with an old password saved in their browser.

A startup does not need heavy policy to fix this. It needs a few simple habits. Give each person their own access. Give each system its own secret. Remove old access quickly. At that point, secrets management stops feeling like extra security work and starts feeling like basic maintenance.

What actually counts as a secret

A secret is any piece of data that gives access, lets someone act as your app, or helps them fake trust. Teams usually spot the obvious ones and miss the quieter values that can do just as much damage.

API tokens, database passwords, and signing keys are the common examples. If a leaked value can read customer data, send email, charge a card, deploy code, or mint a session, treat it like a secret from day one.

Some secrets hide in places people forget to check. OAuth client secrets, webhook signing values, private SSH keys, deploy credentials, and cloud access tokens all belong in the same bucket. They may look like setup details, but they open real systems.

A simple test helps: what could an attacker do with this value in ten minutes? If the answer is "log in," "download data," "push code," or "pretend to be us," lock it down.

In practice, most secrets fall into four groups:

• credentials that open systems, such as database users and admin tokens
• values that prove identity, such as signing keys and webhook secrets
• machine access, such as SSH keys and deploy credentials
• third-party access, such as payment, email, and analytics API tokens

Teams also underestimate "temporary" test values. Sandbox credentials end up in CI variables, debug logs, screenshots, or copied config files, and the habit spreads to production secrets. The test value itself may be low risk. The workflow around it is the real problem.

Local development secrets count too. A developer laptop with a real cloud token or production database password is part of your attack surface, whether anyone likes that phrase or not.

If a value grants access, signs requests, or proves identity, call it a secret. That rule clears up most confusion.

Pick rules before tools

Most teams do not fail because they chose the wrong product. They fail because nobody agreed on basic rules.

Start with access, separation, and cleanup. Give each app and each person only the secrets they need. A developer working on the marketing site does not need the production database password. A CI job that runs tests does not need the same tokens as a deploy job. Small teams often share one big .env file because it feels easy, but that turns one leak into a full breach.

Keep every environment separate. Local development, CI, staging, and production should all use different values. If staging uses the same API token as production, a harmless test can become a real incident. Production secrets should stay off laptops unless someone truly needs direct access.

A few rules cover most cases:

• create separate secrets for local, CI, staging, and production
• give people and services the smallest access set possible
• rotate secrets on a schedule, and rotate again after team changes
• keep secrets out of git, chat, docs, and issue trackers

Rotation sounds annoying until you compare it with the alternative. If one contractor leaves and five systems still depend on a password they knew, you now have a cleanup project instead of a normal offboarding step.

Keep the leak response simple too. If someone pastes a token into chat or commits it to git, treat it as exposed. Delete the message if you can, then rotate the secret right away. Do not waste time debating whether anyone saw it.

Once these rules are clear, tool choices get much easier. You can judge any setup with one question: does it support the rules, or does it tempt people to break them?

Local development without drama

For local work, the safest setup is often the simplest. Keep one real .env file per project on each machine, keep it out of Git, and commit a .env.example with fake values or blank placeholders.

That example file helps more than people expect. A new developer can copy it, fill in the missing values, and run the app without asking five people where things live. When a variable changes, the repo shows the new config shape without exposing anything sensitive.

Real values should live in a team vault, not in chat, email, or scattered notes. When someone joins, they get vault access. When a token rotates, the team updates it in one place instead of digging through old messages.

Some secrets are too risky to share across the whole team. Payment providers, email services, and anything that touches real customer data should use separate sandbox credentials for each developer when possible. That makes mistakes smaller and logs easier to read.

Static cloud keys on laptops are another habit worth dropping early. If your cloud stack supports short-lived credentials through SSO, CLI login, or temporary session tokens, use that path. A token that expires this afternoon is a lot less dangerous than one sitting in a local file for a year.

A good local setup is boring. Copy .env.example to .env, pull real values from the vault, sign in for temporary cloud access if needed, and run the app. If a new hire can do that in ten minutes, the process is in good shape. If they need a long handoff call and three old Slack threads, fix the process before adding another tool.

CI secrets that stay scoped

Most startups do fine in CI with the secret store built into their CI platform. It is simple, close to the pipeline, and usually enough for build, test, and deploy steps. You do not need a giant vault rollout on day one.

Scope matters more than brand names. A secret should belong to one repo, one environment, or one pipeline job whenever possible. If the staging deploy token can also push to production, the setup is already too loose.

A clean CI setup is straightforward. Build jobs get only package registry or signing secrets. Test jobs get fake or low-risk credentials. Deploy jobs get environment-specific access, and only for the target they deploy to.

Long-lived personal access tokens are a bad fit for CI. They get copied, forgotten, and reused across too many systems. If your cloud or hosting provider supports short-lived tokens through workload identity or OIDC, use that first. The token expires quickly, and nobody has to paste a personal credential into a settings page.

Logs need the same care. Turn on masking for known secret values, but do not rely on masking alone. A bad script can still print a token in pieces or write it to an artifact. Builds should fail fast when commands dump env files, print full process environments, or run shell debug mode during deploy steps.

For production deploys, it is often better to let CI fetch secrets at runtime instead of storing the final database password or API token in pipeline settings forever. CI asks a secret manager for the current value, uses it, and exits. That makes rotation easier and cuts down the number of places you need to clean up later.

For most startups, the sweet spot is built-in CI secrets, tight scope, short-lived access, and runtime fetch for the few credentials that matter most.

Production secrets that do not leak everywhere

In production, keep secrets outside your app image and outside your repo. Put them in the secret store that already sits closest to where the app runs: AWS Secrets Manager or Parameter Store, Google Secret Manager, your hosting control plane, or Kubernetes Secrets with encryption turned on. On a small VPS, a root-only file written by the deploy process can still work if you lock it down carefully.

Inject secrets when the app starts. Your deploy job can fetch values and pass them as environment variables or mounted files. Do not bake them into Docker images during build. Build logs, image layers, and cached copies have a long memory.

Separate machine secrets from human access. The app needs database credentials, API tokens, and signing material. People need SSH, cloud console access, and admin dashboards. Keep those paths separate, with separate owners, so one stolen laptop does not open everything.

A simple production setup usually follows four rules:

• store runtime secrets in the same cloud account or control plane where the app runs
• give each service its own credentials
• pass secrets at startup, not at build time
• keep secret names stable so you can swap values without changing app code

Rotation should feel boring. If changing a database password means rebuilding three services and editing two pipelines, the setup is already too fragile. Stable secret names help. Short-lived credentials are even better when your cloud supports them.

Keep one emergency access path for outages and offboarding. Use a break-glass account, recovery codes, and written steps stored offline. Test that path once before you need it. Production secrets cause the most pain when nobody can reach them during an incident.

A migration plan that does not create panic

Big migrations create noise. Small, ordered changes work better.

Start with a plain inventory of every secret your team uses today. Include database passwords, API tokens, SSH keys, signing keys, cloud access tokens, payment provider credentials, and anything sitting in old docs or team chat. Most teams miss a few on the first pass.

Next, sort each secret by where people actually use it: local development, CI, staging, or production. That single step cuts through a lot of mess. When teams stop reusing the same token everywhere, leaks get easier to contain and cleanup gets faster.

A calm rollout usually looks like this:

• move production secrets first into one place with clear ownership
• move CI secrets next and give each pipeline its own access
• keep staging separate from production, even if the app is small
• replace shared accounts with named access wherever possible
• rotate and revoke the old shared passwords on a fixed date

Production goes first because mistakes there affect users right away. CI comes next because old CI secrets often sit in logs, copied variables, and forgotten project settings. Local laptops can come last, since developers usually need a short transition period to avoid blocking work.

Do not let the old and new setups run forever. Give the team a short overlap window, then remove the shared passwords. One week is often enough for a small team.

Write down the new flow on one short page. Show where secrets live, who can request access, who approves it, and how people rotate credentials when someone leaves or a token leaks. If that page is clear, the setup usually sticks.

What this looks like in a small SaaS team

Take a seven-person SaaS team. They started the way many teams do: one shared cloud login in a password manager, one copied .env file, and a lot of trust that nobody would change anything by accident.

That works for a month or two. Then someone leaves, another person needs staging access, and the team can no longer tell which app uses which token.

They clean it up without buying a giant platform. For local development, each developer pulls their own secrets from a vault, and the repo keeps only a .env.example file with variable names and fake values. New hires can boot the app quickly, but real secrets never sit in git.

CI gets its own identity next. The team creates one deploy token for the pipeline instead of reusing a founder's personal credentials. They also split staging values from production values, so a test deploy cannot touch live data because someone copied the wrong variable.

Production changes in one important way. The app no longer stores the database password or third-party API keys on the server image. At startup, it asks the cloud secret store for the values it needs, loads them into memory, and runs.

The biggest difference shows up during offboarding. Before, removing one engineer meant changing shared passwords, checking old laptops, and hoping nobody forgot a hidden token in CI. Now the team follows a short checklist: disable the person's vault access, revoke their cloud account, rotate the few secrets tied to their work, and confirm CI and production still use service accounts.

For a small team, that is what good secrets handling should look like. Not fancy. Just clear enough that access changes take ten minutes instead of half a day.

The mistakes that cause most leaks

Most leaks do not start with a clever attack. A team puts a secret somewhere convenient, forgets about it, and that secret spreads through logs, build systems, old laptops, and copied configs.

One common mistake is baking secrets into Docker images or shipping them inside a mobile app. Image layers get cached, pushed to registries, and copied between machines. A secret inside a client app is worse, because every user can extract it.

Teams also get burned when they reuse one token for staging and production. Staging usually has weaker controls, more people touching it, and more casual debugging. If the same credential works in production, a small staging leak becomes a production incident.

CI often gets far more access than it needs. A build job should not have the same reach as a senior engineer with full cloud access, database access, and secret admin rights. Keep CI scoped to one job, one environment, and one purpose.

Debugging creates another easy leak. Someone prints all environment variables to inspect a failing deploy, and now secrets sit in build logs, error tools, or chat screenshots. Log the name of the missing variable, not the value. If your tools support masking, turn it on.

Rotation can fail too. A team updates the new secret, sees the app working, and leaves the old one valid for weeks. That overlap defeats the point. When you rotate, set a short cutover window and revoke the old value as soon as the rollout finishes.

A sane setup keeps the blast radius small. Separate local, staging, and production secrets. Give CI narrow permissions and short lifetimes. Keep secrets out of images, apps, and logs. Revoke old credentials right after rotation.

If one secret leaks, the damage should stay limited and easy to contain.

Quick checks for a sane setup

A sane setup feels boring on purpose. Fancy tools do not matter much if normal work still depends on risky shortcuts.

If a new hire needs a database password from Slack on day one, the setup is still fragile. They should be able to pull local development secrets from one approved place, use a starter script, and get moving without asking who has the latest value.

A few quick checks tell you a lot:

• a lost laptop should be annoying, not a production incident
• CI should deploy without borrowing a founder's personal token or SSH key
• one secret should map to one job or one service, not half the company
• every secret needs an owner, a home, and a rotation history
• local values belong to local development, CI values to automation, and production secrets to production only

A reality test works even better than a checklist. Ask one teammate to set up a laptop with no prior access. Ask another to rotate a single credential. Ask a third to trace one deploy token from issue to owner. If those tasks turn into chat archaeology, the setup needs work.

That is usually when teams stop guessing and start cleaning up access rules before the next leak forces the issue.

When the setup starts to sprawl

Sprawl usually starts quietly. One app becomes three, staging gets its own credentials, CI adds a few tokens, and soon nobody feels sure which secret lives where.

When that happens, stop adding tools for a week and write down the smallest setup your team needs for the next six months. Keep it boring and specific. Decide where local development secrets live, where CI stores them, where production values live, who can read each set, and who rotates them.

A short written standard is often enough: one source for local secrets, one source for CI secrets, one source for production secrets, and one owner for access changes and rotation.

Add heavier tools only when a real limit forces the issue. That usually means you now need regular rotation, clear audit logs, or tighter control because more people and services touch the same systems. Until then, a plain setup that people follow beats a bigger system that only one engineer understands.

An outside review can help here. A fresh set of eyes often spots access gaps quickly: old contractor accounts, copied production tokens in CI, shared admin logins, or secrets still sitting on old laptops. Those problems hide in familiar setups because the team stops seeing them.

If your stack already feels messy, this is also the kind of problem a fractional CTO can clean up quickly. Oleg Sotnikov at oleg.is works with startups on infrastructure, product architecture, and AI-first development operations, and this sort of access review fits naturally into that work. In many cases, a careful cleanup and a few enforced rules do more than an expensive secrets platform bought too early.