> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ENV File Exploration

> Explains .env usage, why to exclude secrets from repos, example environment variables, and best practices for securely managing variables for local development and CI/CD

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.

```text theme={null}
This repo is organized as a teaching flow under `sections/`.

## Section roadmap
1. Cluster foundation
2. Airline app deployment
3. FinOps problems
4. Local Python agent
5. LLM decision flow (LangChain)
6. Issue tracker service
7. Agent to tracker integration
8. Kubernetes-native agent
9. Prebuilt MCP setup for local cluster access
10. Advanced MCP FinOps pipeline

Begin by reviewing the repository's section overview and the matching section goal files.

For local cleanup, use `helper/cleanup.sh`.
```

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:

```text theme={null}
.env.local
.env.*.local
.env_backup
.env.prod
.env.staging
.env.dev

# Logs
*.log
logs/

# Test coverage
.coverage
.coverage.*
htmlcov/
.pytest_cache/
.tox/
.nox/

# Kubernetes
kubeconfig
*.kubeconfig

# Docker
.docker/

# Local development
*.local
local/

# Temporary files
tmp/
temp/
*.tmp
```

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.

```env theme={null}
# ========================================
# Kubernetes Configuration
# ========================================
KUBECONFIG_PATH=~/.kube/config

# ========================================
# Agent Configuration
# ========================================
LOG_LEVEL=INFO
ISSUE_TRACKER_URL=http://localhost:8085
ISSUE_TRACKER_TIMEOUT=10

# ========================================
# OpenAI-Compatible Endpoint Configuration
# ========================================
OPENAI_BASE_URL=https://api.ai.kodekloud.com/v1
OPENAI_API_KEY=sk-L972B3fCD9o0trx05PBBYA
OPENAI_MODEL_ID=claude-haiku-4-5
OPENAI_MAX_TOKENS=1024
OPENAI_TEMPERATURE=0.3
```

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:

| Variable | Purpose | Typical values / Notes |
| - | - | - |
| `KUBECONFIG_PATH` | Path to kubeconfig used to access clusters | `~/.kube/config` or CI-provided file path |
| `LOG_LEVEL` | Controls logging verbosity | `DEBUG`, `INFO`, `WARNING`, `ERROR` |
| `ISSUE_TRACKER_URL` | Base URL for the issue-tracking service | Example: `http://localhost:8085` |
| `ISSUE_TRACKER_TIMEOUT` | HTTP timeout (seconds) for issue-tracker calls | Integer (e.g. `10`) |
| `OPENAI_BASE_URL` | Base API endpoint for the LLM provider | Use your provider’s OpenAI-compatible URL |
| `OPENAI_API_KEY` | API key or token for the LLM endpoint | Store in a secret manager; do not commit |
| `OPENAI_MODEL_ID` | Model identifier used by the provider | e.g. `gpt-4`, `claude-2`, `claude-haiku-4-5` |
| `OPENAI_MAX_TOKENS` | Max tokens for model responses | Integer — respect model limits |
| `OPENAI_TEMPERATURE` | Sampling temperature for responses | 0.0 = deterministic, higher = more creative |

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

* [Kubernetes Basics](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
* [Introduction to OpenAI](https://learn.kodekloud.com/user/courses/introduction-to-openai)
* [Introduction to Amazon Bedrock](https://learn.kodekloud.com/user/courses/introduction-to-amazon-bedrock)
* [Google Cloud Vertex AI](https://cloud.google.com/vertex-ai)

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](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/d9a1ac50-d5f4-4cc1-a8d4-379664950054/lesson/8bdad059-c147-4cc4-85f0-bc882c9953d3)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.