Skip to main content
Welcome back. In this short lesson we inspect a typical .env file layout, why .env files are usually excluded from repositories, and how to safely document required environment variables for local development and CI/CD. Below is a repository header that appears in the project files. It documents the repo structure and where to start; keep this in your repo for orientation.
Why exclude .env files from version control
  • .env files often contain secrets (API keys, tokens) and environment-specific configuration that should not be committed.
  • Use a .env.example (or documented README) to list required variables without exposing secrets.
  • Rely on CI/CD environment variables, vaults, or secret managers for production credentials.
Here is the relevant portion of the repository .gitignore that prevents .env files (and other local artifacts) from being committed:
Keep sensitive keys and environment-specific configuration out of your repository. Use a sample file (for example .env.example) that documents required variables without secrets.
Example .env (local or .env.example) Below is an example .env file used for local development. Treat this as a template: copy it to .env and fill real secrets from a secure source.
Do not commit real API keys or secrets. The OPENAI_API_KEY shown above is an example. Replace it with a secure value from your organization’s secret store and rotate keys if they are ever exposed.
What each variable means (quick reference) The table below summarizes each environment variable and common usage patterns: Line-by-line explanation and guidance
  • KUBECONFIG_PATH
    Points to the kubeconfig file used to access Kubernetes clusters (default ~/.kube/config). Override this when using multiple kubeconfigs or when CI mounts a kubeconfig file.
  • LOG_LEVEL
    Controls the verbosity of agent logs. Use DEBUG for local troubleshooting and INFO or WARNING for production runs.
  • ISSUE_TRACKER_URL and ISSUE_TRACKER_TIMEOUT
    ISSUE_TRACKER_URL is the base URL for your issue-tracking service (the local example uses http://localhost:8085). ISSUE_TRACKER_TIMEOUT sets the HTTP timeout in seconds for calls to that service.
  • OPENAI_BASE_URL
    The base endpoint for the model API. If your organization uses an OpenAI-compatible API gateway or third-party provider, set the URL accordingly. Some providers (Amazon Bedrock, Anthropic, or GCP Vertex AI) use different SDKs or endpoints—consult provider docs and update this variable to match.
  • OPENAI_API_KEY
    Authentication token for the LLM provider. Never store production keys in plaintext in your repo. Prefer vaults, platform secrets, or CI environment variables.
  • OPENAI_MODEL_ID
    Identifier for the model to interact with. Choose a model that fits your latency, cost, and capability requirements.
  • OPENAI_MAX_TOKENS and OPENAI_TEMPERATURE
    Configure response length and randomness. Tune OPENAI_MAX_TOKENS to avoid truncated responses and set OPENAI_TEMPERATURE depending on whether you need deterministic outputs or creative variation.
Best practices for managing .env values
  • Use .env.example to document required variables without including secrets.
  • For CI/CD and production, inject secrets via the runtime environment (e.g., GitHub Actions secrets, GitLab CI variables, Kubernetes Secrets, HashiCorp Vault).
  • Rotate keys immediately if they are ever exposed.
  • Consider provider-specific libraries or SDKs that can fetch credentials from managed services.
Quick tips for secure workflows
  • Never commit .env (add it to .gitignore).
  • Use different credentials per environment (dev/staging/prod).
  • Audit access to secret stores and enable expiry/rotation.
Links and references Now that you’ve reviewed the .env layout and .gitignore rules that keep secrets out of your repository, create a .env.example that mirrors this structure and inject real credentials securely via your secrets mechanism. Let’s move on to the next lesson.

Watch Video