Skip to main content

Production Database Access

This document records the approved workflow for production database access so issue investigation can proceed without re-asking for access setup on each task.

Scope​

Production database access is reserved for debugging production issues, verifying live customer data behavior, and validating fixes against the real production environment.

Use this only when:

  • the issue is happening in production;
  • the customer-facing behavior needs live verification; or
  • a production-only data condition must be checked before a fix is considered complete.

Required access pattern​

  1. Use the approved source IP and network path already allowed for production access.
  2. Pull the database credentials from the local password manager / approved secret store, not from the repository.
  3. Do not commit credentials, connection strings, or raw secrets into Git.
  4. Use the least-privileged role needed to inspect or fix the issue.
  5. Record the purpose of the access in the working notes before making a production data read or write.

Connection workflow​

Typical workflow:

  • open the approved production environment connection from the allowed IP;
  • use the configured DB client or SSH tunnel for the production instance;
  • validate the exact customer record under investigation before changing code;
  • confirm the issue in the live system before shipping a fix.

Examples of valid use cases:

  • checking whether a company/member relation exists for a production user;
  • verifying whether a pending invite is present for a company owner action;
  • validating that the production record state matches the reported bug.

Important guardrails​

  • Never store database credentials in repository files, shell history, or notes checked into Git.
  • Never use development database state as proof for a production issue.
  • If a repair requires production data review, use the live production system and document what was verified.
  • If a data issue is tied to an invited-but-not-accepted user, confirm whether the record exists in the CompanyInvitation table or CompanyEmployee table before concluding that a removal request is invalid.

What to do for UI issues​

For front-end or user-facing issues:

  • log in as the exact production user or affected account;
  • open the page in the browser; and
  • verify the visible result, not just the underlying DOM or raw database rows.

This prevents "empty page" or "it exists in the database" mistakes from being treated as valid user-facing verification.

Production triage rule​

When a production issue is reported, validate against the production environment first. The repo should only be used to patch and test the root cause after the real production condition is understood.