Usar Configuraciones o Variables de Entorno? - Opinión
Índice de contenido
- ¿Por qué Laravel separa configuraciones y variables de entorno?
- El propósito del archivo .env
- Cómo funciona el sistema de configuración en /config/*.php
- Diferencias entre env() y config() en Laravel
- Cuándo usar variables de entorno
- Cuándo crear una configuración personalizada
- ¿Por qué no usar una configuración en lugar de variables de entorno?
- Cómo crear y leer configuraciones personalizadas en Laravel
- Crear un archivo en /config
- Establecer valores por defecto seguros
- Errores comunes y cómo evitarlos
- Cuándo sí crear una configuración personalizada
- Conclusión
- Preguntas frecuentes sobre configuraciones y variables en Laravel
En Laravel, uno de los temas más importantes al desarrollar una aplicación robusta es entender cómo manejar la configuración y las variables de entorno. Aunque ambos conceptos parecen similares, su propósito y momento de uso son distintos. En este artículo te explico, desde la práctica, cómo funcionan, cuándo conviene usar cada uno y cómo aplicarlos correctamente en proyectos reales.
¿Por qué Laravel separa configuraciones y variables de entorno?
Laravel organiza la información sensible y las configuraciones en dos niveles: las variables del entorno (.env) y los archivos de configuración (/config). Esta separación no es casual, sino una decisión clave para la seguridad y el mantenimiento del código.
El propósito del archivo .env
El archivo .env almacena datos que cambian según el entorno de ejecución: base de datos, API keys, servicios externos o modo de aplicación (desarrollo o producción). Laravel los gestiona a través del paquete Dotenv, que carga las variables al iniciar el framework.
Estas variables no deben compartirse ni versionarse. Son específicas del servidor, por lo que un cambio en producción no afecta a tu entorno local. Por ejemplo:
APP_ENV=local
APP_DEBUG=true
PAYPAL_CLIENT_ID=xxxxSe trata de que tu cliente pueda inspeccionar la aplicación sin poner en riesgo su estabilidad. Es decir, que no pueda “romperla”, crear datos extraños o eliminar la información de ejemplo. Creo que ya queda bastante claro: el modo demo permite ver e interactuar con la app, pero sin alterar los registros establecidos.
Cómo funciona el sistema de configuración en /config/*.php
Los archivos de configuración, en cambio, definen los parámetros internos de la aplicación: logging, cache, correo, colas, etc. Cada archivo en /config contiene un arreglo PHP con valores que pueden hacer referencia a variables del .env.
Por ejemplo, en config/app.php:
'name' => env('APP_NAME', 'MiAplicacion'),
'debug' => env('APP_DEBUG', false),Diferencias entre env() y config() en Laravel
La confusión más común es cuándo usar env() directamente o cuándo depender de config(). Aunque ambas funciones devuelven valores configurables, su ámbito y propósito son distintos.
Cuándo usar variables de entorno
Usa env() solo para inicializar configuraciones. Nunca deberías llamarla directamente dentro del código de tu aplicación (controladores, servicios, vistas). En esos lugares se recomienda usar config(), ya que las variables pueden quedar en caché y no actualizarse correctamente.
Cuándo crear una configuración personalizada
Cuando un valor afecta la lógica de negocio y no solo el entorno, conviene crear un archivo de configuración propio. Esto permite definir valores por defecto, mantener coherencia y evitar romper la aplicación si falta una variable.
Ejemplo práctico: modo demo controlado por variable de entorno
En mi caso, implementé un modo demo para una aplicación de ejemplo. Quería que los usuarios pudieran interactuar con la app sin alterar datos sensibles. Para eso creé una variable de entorno personalizada:
APP_DEMO=trueY en el código la utilicé de forma simple:
if (env('APP_DEMO')) {
// Bloquear ciertas acciones
}¿Por qué no usar una configuración en lugar de variables de entorno?
Seguramente te preguntarás: ¿por qué demonios no empleé una configuración?
En mi canal de YouTube tengo varios videos donde comento sobre el uso de variables de entorno y configuraciones personalizadas.
Ambas son opciones válidas, pero en resumen, casi siempre recomiendo usar configuraciones, ya que trabajar directamente con variables de entorno puede ser riesgoso.
Por ejemplo, si una variable no está definida —imaginemos que borras la variable de entorno de PayPal—, romperías toda la aplicación, porque PayPal necesita esas claves sí o sí.
Cómo crear y leer configuraciones personalizadas en Laravel
Crear un archivo en /config
Puedes crear un archivo config/demo.php con contenido como:
return [
'enabled' => env('APP_DEMO', false),
];Acceder a valores desde controladores o vistas
Luego, puedes acceder al valor desde cualquier parte de tu aplicación:
if (config('demo.enabled')) {
// Ejecutar modo demo
}Este enfoque es más seguro, ya que mantiene la lógica centralizada y compatible con la caché de configuración.
Establecer valores por defecto seguros
Siempre define valores por defecto en las llamadas a env(). Así, si una variable no está presente, el sistema sabrá qué hacer:
'paypal_client_id' => env('PAYPAL_CLIENT_ID', 'default'),Errores comunes y cómo evitarlos
Cuando usamos el esquema de configuraciones, el sistema está diseñado para que, por defecto, devuelva el valor de la variable de entorno si existe.
Esa es la de mayor prioridad. Pero si no está definida, entonces toma un valor por defecto.
Esto es lo que normalmente implementamos en el 99.9% de los casos.
Por eso digo que lo ideal es seguir esa estructura. Todo viene así por defecto: se usa la variable si está, y si no, se usa la configuración base.
Eliminar o renombrar una variable crítica puede romper la aplicación. Por eso es buena práctica definir configuraciones con valores por defecto.
En resumen, queremos obtener un valor ya sea desde la variable de entorno o desde la configuración, pero con seguridad de que exista.
Si lo hacemos bien, evitamos errores. Pero si lo hacemos mal y llamamos la variable directamente, es igual de riesgoso que no tener configuración alguna.
Cuándo sí crear una configuración personalizada
Cada vez que quieras crear una configuración personalizada —como hicimos en este curso con las de PayPal—, lo ideal es definirlas correctamente.
Aquí, por ejemplo, deberían estar las configuraciones de producción, aunque no las coloco por razones obvias (este es un proyecto de ejemplo).
Pero en una aplicación real sí deben estar establecidas.
Conclusión
La diferencia entre configuraciones y variables de entorno en Laravel es fundamental para desarrollar aplicaciones seguras, predecibles y escalables. Las variables de entorno sirven para definir el entorno y los datos sensibles; las configuraciones, para establecer el comportamiento interno de la aplicación.
En mi experiencia, prefiero mantener las cosas simples. Si solo necesito saber si algo está activo, uso una variable de entorno. Pero si el valor afecta la lógica del sistema o puede faltar, opto por una configuración con valor por defecto. Ese equilibrio entre simplicidad y robustez es la clave para un código limpio y estable.
Preguntas frecuentes sobre configuraciones y variables en Laravel
- ¿Cuál es la diferencia entre config() y env()?
env() lee variables del entorno, mientras que config() obtiene valores definidos en los archivos /config. - ¿Dónde se guardan las configuraciones en Laravel?
En la carpeta /config, donde cada archivo define un conjunto de parámetros de la aplicación. - ¿Es seguro usar variables de entorno directamente?
No. En producción deben accederse mediante config(), no con env() directamente. - ¿Qué pasa si falta una variable en el .env?
Si no se define un valor por defecto, Laravel puede lanzar errores o comportarse de forma inesperada.
Acepto recibir anuncios de interes sobre este Blog.
Hablamos sobre cuando usar Configuraciones o Variables de Entorno personalizadas en Laravel.