Keel

Where should a startup keep database passwords and API keys on AWS?

By the Keel team · Last checked · 4 min read

Short answer

A startup should keep database passwords and API keys in a managed secrets store such as AWS Secrets Manager and have the application fetch them at runtime, rather than hard-coding them in source code, environment files on laptops or chat messages. Rotate them on a schedule, scan your repositories for leaked ones, and change them when someone with access leaves. Hardcoded secrets are among the most common findings in SaaS security reviews.

  • Days

    Time AKF Partners says hardcoded-credential findings typically take to fix

    Source: AKF Partners, Sep 2026

  • 0

    Hard-coded credentials needed in source code when secrets are fetched at runtime

    Source: AWS docs, Oct 2026

Why are secrets a problem for small teams?

Secrets are a problem for small teams because they start in the quickest place, usually a config file or a message, and stay there.

AKF Partners lists hardcoded credentials and production secrets stored in version control among the most frequently cited findings in SaaS audits, and says each is fixable in days.

The cost of a leak is high: a database password or cloud key in the wrong hands can expose customer data. It is also an easy item for investors and customer security reviewers to find.

Where should you not keep secrets?

Do not keep secrets in source code, in a repository's history, in environment files shared between laptops, or in chat and email.

Once a secret is in any of those places you cannot tell who has a copy.

  • Source code and repository history, including private repositories.
  • .env files copied between developers.
  • Slack, email and tickets.
  • Build logs and container images.
  • A document that anyone in the company can open.

What does AWS Secrets Manager do?

AWS Secrets Manager helps you manage, retrieve and rotate database credentials, application credentials, OAuth tokens, API keys and other secrets throughout their lifecycles.

Your application replaces a hard-coded credential with a runtime call to retrieve it when needed.

AWS says this improves your security posture because you no longer need hard-coded credentials in application source code, and that it avoids compromise by anyone who can inspect your application or its components. Pricing is based on the number of secrets stored and the API calls made, with no upfront costs or long-term contracts, so check the pricing page for current rates.

How often should you rotate secrets?

Rotate secrets on a schedule you can keep, and straight away when there is a reason to doubt them.

Secrets Manager can rotate on an automatic schedule, which AWS says lets you replace long-term secrets with short-term ones and reduces the risk of compromise.

AWS also notes that because applications fetch credentials at runtime, rotating them no longer requires updating your applications and deploying changes. One caution: automatic rotation, other than managed rotation, uses an AWS Lambda function, which has its own charges.

How do you find secrets that have already leaked?

Find leaked secrets by scanning for them.

Trivy can scan code repositories and filesystems for secrets as well as vulnerabilities, so a scan in your pipeline catches a password committed by mistake before it ships. Treat any secret that was ever committed as exposed, even if you have since deleted it.

Rotate the exposed value, then fix how it got there. Trivy and SonarQube in CI for a small team explains how to add the scan without slowing releases.

What should happen to secrets when someone leaves?

Any secret a leaving person could read should be rotated, and their access removed on the day they go.

If secrets live in a managed store with access controlled by roles, that is a short list; if they live in files on laptops, it can be everything.

What happens to your AWS setup if the engineer who built it leaves covers the wider handover, including the root user. A record of who can read which secret is part of an AWS infrastructure audit for a small SaaS.

Can a very small team get secrets handled without hiring?

A very small team can get secrets, access and patching handled through Keel's Startup programme, a foundation-level service for small teams already live with paying customers.

The programme offers a deploy pipeline with rollback, tested backups, monitoring and monthly patching in your own AWS account, with a monthly check-in with a Keel account manager. Keel's plans also cover secrets and least-privilege access; ask on application what the programme includes.

It is for teams of fewer than 5 at pre-seed to Series A, live in production with at least one paying customer, on AWS with code on GitHub or GitLab. Places are limited and awarded on merit. If that fits, apply for a place in the pricing section.

Are your secrets under control?

Tick each item that is true today.

  • No secrets sit in source code or repository history.
  • Production secrets live in a managed store, not shared files.
  • Applications fetch secrets at runtime.
  • Rotation happens on a schedule or when there is doubt.
  • Your pipeline scans for committed secrets.
  • Leaving someone's access is removed and their secrets are rotated.

Decision point: Five or six ticks: secrets are well handled. Three or fewer: assume at least one secret is already in the wrong place.

Sources

  1. AWS docs, What is AWS Secrets Manager? (checked October 2026)
  2. AWS, Secrets Manager pricing (checked October 2026)
  3. AKF Partners, Technical Due Diligence for SaaS Founders in 2026 (September 2026)
  4. Trivy docs, Scanner coverage (checked October 2026)

Keep reading

Keel is an AWS release and recovery operations service for SaaS teams of 3 to 15 developers, provided by Bargainn Services Ltd, a UK company registered at Companies House (16497746). Registered office: 3rd Floor, 86-90 Paul Street, London, EC2A 4NE, United Kingdom.