Skip to main content
In this lesson we’ll cover Telepresence’s built-in env-file feature: how it captures the environment from a container in-cluster and writes it to a local file so your locally run process can use the same environment as the intercepted service.
A blue-to-teal gradient slide with the white text "Env file" centered. A small "© Copyright KodeKloud" label appears in the bottom-left corner.
What happens when you intercept a Kubernetes service with Telepresence? The telepresence intercept command routes the service traffic to a process running on your local machine. For example, intercepting a “products” deployment and forwarding port 8000 on your machine to port 3000 in the cluster looks like this:
If the original in-cluster container requires environment variables (for example, an API_URL or DB connection string defined in the deployment spec), your local process typically needs the same variables to behave identically. To simplify this, Telepresence can export the container’s environment into a local file using the --env-file flag. Example: create a .env file that matches the container environment and run the intercept:
When you pass --env-file .env, Telepresence writes the container’s environment to the named file (for example .env) using the KEY=VALUE format. You can then source or otherwise load that file to run your local process with the same environment.
Telepresence will create a local file with the exact name you specify containing the container’s environment variables. Source or consume that file so your local process runs with the same environment as the in-cluster container.
Usage patterns: how to consume the generated env file
  • Shell (bash/zsh): source the file so environment variables are exported into the current shell session.
  • Export all variables in one line (useful in some CI/test scripts):
  • Node.js (dotenv): install and use the dotenv package to load .env into process.env.
  • Python (python-dotenv):
  • Docker CLI (when launching a container locally that needs the same environment):
Quick reference table Security note
The generated env file may contain sensitive values (API keys, DB credentials, tokens). Treat it like a secret: do not commit it to version control, avoid logging it, and delete it when you no longer need it.
Examples and considerations
  • If your deployment defines environment variables via env or envFrom in the pod spec, those values will be captured. For example, a deployment snippet might include:
    Telepresence will resolve the container’s final environment and write it to the file.
  • If values are injected at runtime by an init container or an entrypoint script, ensure those values exist in the running container environment before creating the intercept, otherwise they won’t be captured.
  • For local frameworks that use configuration libraries (e.g., Spring Boot, Twelve-Factor apps), a .env file can often be wired in directly or via the framework’s environment loader.
Links and references

Watch Video