Cuando despliegas una aplicación Python en distintos entornos, necesitas que ciertos valores cambien según dónde corra el código. Las variables de entorno resuelven este problema y te permiten separar configuración sensible del código fuente, algo clave si trabajas con Flask, Django o cualquier servidor WSGI.

¿Por qué usar variables de entorno en lugar de hardcodear valores?

Imagina que tienes una variable llamada APP_MODE. En tu máquina debería valer local, pero en producción debería ser production. Si dejas ese valor escrito directamente en el código y lo subes al repositorio, vas a tener conflictos cada vez que ejecutes la aplicación en un entorno distinto.

La solución es mantener esos valores fuera del código y leerlos desde el sistema operativo o desde un archivo de configuración local.

¿Qué es una variable de entorno? Es un valor tipo string que vive en el sistema operativo y que tu aplicación puede leer en tiempo de ejecución. Sirve para guardar configuración que cambia entre servidores.

¿Cómo se crea una variable de entorno con export en Linux?

En una terminal Linux usas el comando export seguido del nombre de la variable y su valor [01:00]. Por ejemplo:

bash export APP_MODE=local

Con eso defines APP_MODE en la sesión actual. Recuerda que las variables de entorno solo aceptan strings, así que no intentes guardar enteros, listas ni diccionarios directamente.

¿Cómo leo esa variable desde Python?

Python incluye la librería os por defecto, así que no necesitas instalar nada extra. Para obtener el valor usas os.environ.get y le pasas la key que definiste:

python import os

app_mode = os.environ.get("APP_MODE") print(app_mode)

Si ejecutas la aplicación con un servidor como Gunicorn y abres el navegador, verás el mensaje impreso en la terminal. Y aquí viene un detalle interesante: si el valor aparece dos veces, no es un error. Pasa porque tu servidor tiene dos workers, es decir, dos procesos de Python corriendo en paralelo aceptando requests [02:10].

¿Cómo usar un archivo .env con python-dotenv?

Definir variables con export cada vez que abres una terminal es engorroso. Por eso existe el archivo .env, donde concentras toda tu configuración local en un solo lugar [02:40].

Un .env típico se ve así:

APP_MODE=local SECRET=super_secret

Para leerlo desde Python necesitas instalar la librería python-dotenv:

bash pip install python-dotenv

La versión que se instala es la 1.0. Guárdala en tu requirements.txt para que cualquiera que clone el proyecto pueda replicar el entorno.

Luego, en tu código importas la función y le pasas la ruta del archivo:

python from dotenv import load_dotenv

load_dotenv(".env")

Esto inyecta todas las variables del archivo en el entorno del proceso, sin que tengas que ejecutar export manualmente. Después puedes leerlas con os.environ.get igual que antes.

¿Para qué sirve python-dotenv? Es una librería que carga variables desde un archivo .env al entorno de ejecución de Python, evitando que tengas que exportarlas a mano en cada sesión.

¿Por qué no debo subir el archivo .env al repositorio?

El .env suele contener información delicada: contraseñas de base de datos, claves de API, secretos de autenticación con servicios como Facebook Login. Si lo subes a Git, expones esos datos a todo el equipo y, peor aún, al público si el repositorio es abierto.

La regla práctica:

• Agrega .env a tu .gitignore desde el primer commit.
• Comparte un .env.example con las llaves pero sin los valores reales.
• Usa el archivo real solo en tu máquina y en el servidor de producción.

¿Qué casos reales resuelve un archivo .env?

Una vez que dominas el flujo, las aplicaciones son muchas. Algunos ejemplos directos:

• Guardar los secretos de un login con Facebook u otro proveedor OAuth.
• Configurar la contraseña de la base de datos en producción sin exponerla en el código.
• Definir flags como APP_MODE para cambiar comportamiento entre entornos.
• Almacenar tokens de servicios externos como Stripe, SendGrid o AWS.

Esto te permite proteger la información crítica de tu aplicación y controlar quién tiene acceso a qué.

¿Qué pasa si defino la misma variable con export y en el .env?

Este es justo el experimento que vale la pena hacer tú mismo. Crea una variable usando export en la terminal, luego define la misma variable en tu .env con un valor distinto y observa cuál toma prioridad cuando ejecutas la aplicación.

Entender ese orden de precedencia te va a ahorrar horas de debugging cuando una variable no tome el valor que esperas.

¿Qué variables sueles guardar en tu .env y cuáles dejas en el sistema operativo? Cuéntame tu setup en los comentarios.