env File Exploration

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.

This repo is organized as a teaching flow under `sections/`.

## Section roadmap
Cluster foundation
Airline app deployment
FinOps problems
Local Python agent
LLM decision flow (LangChain)
Issue tracker service
Agent to tracker integration
Kubernetes-native agent
Prebuilt MCP setup for local cluster access
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:

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

# ========================================
# 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
OpenAI Platform
AWS Bedrock
Google 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.

Introduction

The Problem Statement

Introduction to FinOps

Setting Up SkyLine Air Kubernetes Services

MCP Gateway for Kubernetes

LangChain MCP Agents

LLM Policy-Aware Label Audit

From Findings to Actionable Tickets

env File Exploration

Watch Video