> ## 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

> Guide explaining .env file usage, example variables, .gitignore patterns, and best practices to avoid committing secrets and manage environment configuration for local development.

Welcome back. This short guide describes how a typical `.env` file is organized in this repository, why `.env` files are excluded from version control, and what each key in the example `.env` means. This helps keep sensitive data safe and makes local development reproducible.

Why exclude `.env` files?

* `.env` files commonly contain secrets or environment-specific configuration such as API keys, endpoints, and local paths.
* Committing them can leak credentials or environment details. Use `.gitignore` (or secret management) to prevent accidental commits.

```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 reading the overview and goals for each section.

For local cleanup, run the repository's cleanup script.
```

Never commit `.env` files that contain real secrets. Provide a `.env.example` to document required variables without including secret values. For local testing, use temporary credentials or mock endpoints.

Below is the repository's `.gitignore` excerpt showing common `.env` patterns and local files that should be excluded from version control:

```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
```

Multiple `.env` patterns are included so environment-specific and backup files remain private and are not committed accidentally.

Typical `.env` used for local development
This example follows the structure of `.env.example`. Replace placeholder values with your local paths and test credentials. Never store production secrets in a repository copy of `.env`.

```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-REDACTED
OPENAI_MODEL_ID=claude-haiku-4-5
OPENAI_MAX_TOKENS=1024
OPENAI_TEMPERATURE=0.3
```

Key descriptions
Use the table below to quickly identify each environment variable and a recommended example or tip.

| Variable | Purpose | Example / Notes |
| - | -: | - |
| `KUBECONFIG_PATH` | Path to the kubeconfig file used to access your Kubernetes cluster. | `~/.kube/config` — ensure this points to a valid kubeconfig for your cluster. |
| `LOG_LEVEL` | Controls logging verbosity of the local agent. | `INFO`, `DEBUG`, `WARNING`, `ERROR` |
| `ISSUE_TRACKER_URL` | Local URL for the issue tracker service used by the agent. | `http://localhost:8085` |
| `ISSUE_TRACKER_TIMEOUT` | Timeout (seconds) when contacting the issue tracker. | `10` |
| `OPENAI_BASE_URL` | Base URL for your LLM provider (API endpoint). | Could point to a hosted endpoint or vendor API. |
| `OPENAI_API_KEY` | API key used to authenticate with the LLM provider. | Never commit real keys. Use secret stores in production. |
| `OPENAI_MODEL_ID` | Model identifier for the LLM to use. | e.g., `claude-haiku-4-5`, `gpt-4o` |
| `OPENAI_MAX_TOKENS` | Maximum tokens the model should return. | `1024` |
| `OPENAI_TEMPERATURE` | Sampling temperature to control creativity. | `0.0` (deterministic) to `1.0+` (creative) — `0.3` shown |

How to load local environment variables (development)

* For bash/zsh: `set -o allexport; source .env; set +o allexport`
* For Docker Compose: use `env_file: .env` in `docker-compose.yml`
* For Python, use packages like `python-dotenv` to parse `.env` into `os.environ`

Best practices

* Keep a `.`env.example\` with no secrets that documents required variables and their expected types.
* Use secrets managers (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets, etc.) for production workloads.
* Rotate API keys and audit access to credentials regularly.

Links and references

* [Kubernetes Documentation](https://kubernetes.io/docs/)
* [OpenAI Platform](https://platform.openai.com/)
* [AWS Bedrock](https://aws.amazon.com/bedrock/)
* [Google Vertex AI](https://cloud.google.com/vertex-ai)
* Consider secret management options such as HashiCorp Vault or cloud provider secret stores.

Do not store production credentials or long-lived secrets in `.env` files checked into repositories. Use environment-specific secret injection, a secure secret store, or orchestration-level secrets for production deployments.

You should now be able to create or edit a local `.env` for development, mimic the `.env.example` pattern, and avoid committing secrets. Continue with the next section when ready.

> [card] [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.