Variables de entorno en PHP: guía segura para producción

📅 Publicado el 27 de octubre, 2026 · Por Equipo RedServicio

Si llevas tiempo escribiendo PHP, sabes que hay detalles que marcan la diferencia entre un proyecto que aguanta y uno que se cae a la primera auditoría. Las variables de entorno son uno de esos detalles. Esta guía explica qué son, por qué conviene usarlas desde el primer día y cómo dejarlas bien configuradas en producción, sin cometer los descuidos típicos que acaban exponiendo credenciales.

¿Qué son las variables de entorno y por qué usarlas en PHP?

Las variables de entorno son pares clave-valor que viven fuera del código. Se definen a nivel del sistema operativo o del servidor web, y su función es simple: guardar ahí la información de configuración —credenciales de base de datos, claves de API, rutas, modos de ejecución— para que la aplicación las lea sin que nada sensible quede escrito en el código fuente.

En PHP las lees de dos formas, básicamente:

• Con getenv(‘NOMBRE_VARIABLE’): función nativa que lee las variables del entorno del proceso.
• Con $_ENV[‘NOMBRE_VARIABLE’]: la superglobal de turno, que solo estará poblada si la directiva variables_order de tu php.ini incluye la letra «E». Mucha gente se olvida de esto y pierde una tarde depurando.

Un ejemplo básico:

$dbHost = getenv(‘DB_HOST’) ?: ‘localhost’;

La gracia está en que el mismo código funciona en desarrollo, staging y producción sin tocar una línea. Solo cambian los valores del entorno. Eso agiliza los despliegues, evita errores de configuración y, sobre todo, mantiene los secretos fuera del repositorio.

Los riesgos de hardcodear credenciales en tu código

Poner credenciales directamente en los archivos PHP —lo que solemos llamar «hardcodear»— sigue siendo uno de los fallos más habituales en proyectos pequeños y medianos. Y los riesgos son bien concretos:

• Exposición en el repositorio: si subes el código a GitHub o GitLab, cualquiera con acceso (o un atacante que dé con un repositorio público) verá tus contraseñas. ¿Y si borras el archivo en un commit posterior? Nada. El historial de Git lo conserva para siempre.
• Filtraciones por archivos de backup: esos config.php.bak o config_old.php que quedan tirados pueden acabar accesibles públicamente si el servidor no está bien configurado.
• Dificultad de rotación: cuando una clave de API se compromete, tendrás que rastrearla y reemplazarla en decenas de archivos en lugar de cambiarla en un único sitio.
• Errores en despliegues: copiar configuración de producción a desarrollo (o al revés) provoca fallos difícilísimos de rastrear.

Un caso típico de código inseguro sería:

$pdo = new PDO(‘mysql:host=localhost;dbname=tienda’, ‘root’, ‘MiP4ssw0rd!’);

Esa contraseña queda registrada en el historial del repositorio, en las copias de seguridad del código y en la caché de cualquier herramienta de análisis que pase por ahí. La solución es externalizar estos valores, como veremos ahora.

Cómo configurar variables de entorno en PHP: métodos disponibles

Hay varios caminos para definir variables de entorno en PHP. ¿Cuál conviene? Depende de tu infraestructura:

1. Variables a nivel del servidor web

En Apache puedes definirlas en la configuración del virtual host o en el .htaccess:

SetEnv DB_HOST localhost

En Nginx se pasan a través del pool de PHP-FPM, en el archivo www.conf:

env[DB_HOST] = localhost

Para producción es el método más robusto: las variables no dependen de archivos dentro del proyecto, y eso se agradece.

2. Archivos .env con la librería vlucas/phpdotenv

El estándar de facto en proyectos modernos es un archivo .env en la raíz, gestionado con vlucas/phpdotenv vía Composer:

require ‘vendor/autoload.php’;
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();

Y el .env contendría algo así:

• DB_HOST=localhost
• DB_USER=usuario_bd
• DB_PASS=contrasena_segura

Imprescindible: añade .env al .gitignore y comprueba que el servidor deniegue el acceso directo a él. En Apache basta una regla Require all denied para ese archivo. Parece obvio, pero hay repositorios públicos llenos de .env olvidados.

3. Variables del sistema en el proveedor de hosting

Muchos paneles (cPanel, Plesk) y proveedores de hosting permiten definir variables de entorno desde su interfaz. Si trabajas con un hosting de calidad como el que ofrece RedServicio.net, con soporte 24/7, puedes pedir ayuda para configurarlas a nivel de PHP-FPM sin tocar archivos de configuración por tu cuenta.

Cualquiera de estos métodos es válido. Lo importante es elegir uno, aplicarlo de forma consistente en todo el proyecto y verificar —de verdad, no de memoria— que ninguna credencial queda expuesta en el código fuente.

Uso de archivos .env con la librería phpdotenv

En local, o en cualquier entorno de desarrollo, lo más cómodo para manejar variables de entorno en PHP suele ser un archivo .env acompañado de la librería phpdotenv. Se instala con Composer en un segundo:

composer require vlucas/phpdotenv

Luego creas el archivo .env en la raíz del proyecto, con este formato:

• DB_HOST=localhost
• DB_USER=mi_usuario
• DB_PASS=mi_contraseña_segura
• APP_ENV=production

Y lo cargas al principio de la aplicación:

<?php
require 'vendor/autoload.php';
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();

$dbHost = $_ENV['DB_HOST'];
?>

Un detalle crucial (y que se olvida más de lo que debería): el archivo .env nunca debe subirse al repositorio. Añádelo a tu .gitignore desde el primer commit y deja un .env.example con los nombres de las variables pero sin valores reales. Así tus compañeros saben qué tienen que configurar sin ver ninguna credencial.

Buenas prácticas de seguridad en el servidor de producción

Definir las variables es solo media tarea. Protegerlas en el servidor importa igual, y ahí es donde muchos proyectos se descuidan. Antes de dar por segura tu aplicación, repasa esta lista:

1. Bloquea el acceso web al archivo .env. Si lo usas en producción, configura Apache o Nginx para denegar peticiones a .env, .env.example y, de paso, a cualquier archivo oculto.
2. Pon permisos restrictivos. Un chmod 640 y asignar el archivo al usuario del servicio php-fpm evitan lecturas que no deberían producirse.
3. Desactiva la exposición de información. Comprueba que expose_php = Off y que display_errors esté apagado en producción. Un stack trace puede volcar variables sensibles en pantalla sin que te des cuenta.
4. Cuida las funciones de depuración. phpinfo(), var_dump($_ENV), print_r($_SERVER)… nada de eso debería llegar jamás a producción.
5. Rota credenciales periódicamente. ¿Sospechas una fuga? Cambia contraseñas de base de datos y claves de API de inmediato. Lo bueno es que solo tocas el archivo de entorno.

Y cuando el proyecto crezca, quizá merezca la pena mirar un gestor de secretos como HashiCorp Vault, AWS Secrets Manager o el almacén de secretos de tu propio proveedor. Centralizan las credenciales, registran los accesos y permiten rotar automáticamente sin despliegues extra. No hace falta desde el día uno, pero conviene saber que existen.

Conclusión: protege tu aplicación PHP desde hoy

Las variables de entorno en PHP no son un lujo ni una moda pasajera. Son la base de una aplicación segura, portable y mantenible. Separar la configuración del código evita fugas de credenciales en el repositorio, simplifica el salto entre desarrollo y producción, y te deja rotar claves sin tocar una sola línea de lógica de negocio.

El camino, en el fondo, es sencillo: elige un método de definición (php-fpm, configuración del servidor o un archivo .env con phpdotenv), aplícalo de forma consistente, bloquea el acceso web a los archivos de configuración y audita tu código buscando credenciales escritas a mano. Unos minutos hoy. Muchos quebraderos de cabeza menos mañana.

Eso sí, si prefieres no pelearte con configuraciones avanzadas, en RedServicio.net ofrecemos hosting con soporte para variables de entorno a nivel de php-fpm, certificados SSL y un equipo de soporte técnico disponible 24/7 para ayudarte a dejar tu aplicación PHP lista para producción con total tranquilidad.