Guías
Variables de entorno
La configuración y los secretos se guardan por app y por entorno. Los valores están pensados para escribirse: puedes definirlos con libertad, pero volver a leer uno es un acto deliberado que queda auditado.
Definir variables
Desde la consola, abre una app y ve a la pestaña Variables. Desde la CLI:
# Set one or several at once$ codaracloud env set my-api DATABASE_POOL_SIZE=20 LOG_LEVEL=info # Import a .env file$ codaracloud env set my-api --from-file .env.production # List (values are masked)$ codaracloud env list my-api # Remove$ codaracloud env unset my-api LOG_LEVELAplica juntos los cambios relacionados
Volver a leer los valores
Al listar las variables nunca obtienes el texto en claro: todos los valores vuelven enmascarados. Mostrar un valor es una acción aparte, con su propio permiso, que deja un registro de auditoría con quién leyó qué clave y cuándo.
# Reveal a single value (audit-logged)$ codaracloud env get my-api DATABASE_URL # Dump everything in .env format (reveals every value, all audit-logged)$ codaracloud env export my-api > .env.productionUn token de API necesita el scope env:reveal para hacer cualquiera de las dos cosas. Con env:read solo se listan las claves con los valores enmascarados.
Cuándo se aplican los cambios
Cambiar una variable reinicia la app. En las apps sin volumen persistente, Kubernetes sustituye las réplicas de forma gradual; aun así, el proceso tiene que atender las señales de terminación y terminar o traspasar el trabajo en curso dentro de su periodo de gracia de apagado. Agrupa los cambios relacionados en lugar de aplicarlos uno a uno.
Reglas y límites
| Regla | Detalle |
|---|---|
| Formato de la clave | Un identificador de shell válido: letras, dígitos y guiones bajos, sin empezar por un dígito. |
| Tamaño del valor | Hasta 65.536 caracteres. |
| Ámbito | Por app y por entorno. Staging y producción nunca comparten valores. |
| Claves reservadas | PORT y todo lo que empiece por CODARA_ lo gestiona la plataforma y no se puede definir. |
PORT ya viene definido
PORT según el puerto configurado en la app. Si intentas definirlo tú, se rechaza. Léelo del entorno en tu código y funcionará en todas partes sin cambios.Variables que proporciona Codara
Cada contenedor recibe unas cuantas variables de solo lectura que describen dónde se está ejecutando. Las ves en la consola, en Proporcionadas por Codara.
| Variable | Contiene |
|---|---|
| PORT | El puerto en el que debe escuchar tu app. |
| CODARA_PRIVATE_URL | La URL interna de esta app, para otras apps del mismo entorno. |
| CODARA_PRIVATE_DOMAIN | Solo el hostname interno. |
| CODARA_* | Identificadores adicionales del espacio de trabajo, el proyecto y el entorno al que pertenece el contenedor. |
Variables compartidas
Cuando varias apps de un mismo entorno necesitan el mismo valor, defínelo una sola vez como variable compartida en lugar de copiarlo en cada app.
# Share a value with every service in the environment$ codaracloud shared-vars set SENTRY_DSN=https://... \ --client my-workspace --project website --env production --all-services # Or attach it to specific services only$ codaracloud shared-vars set REDIS_URL=redis://... \ --client my-workspace --project website --env production \ --service api --service worker $ codaracloud shared-vars list --client my-workspace --project website --env productionLas variables propias de una app tienen prioridad, así que un valor local siempre sustituye a uno compartido con el mismo nombre. Por eso las variables compartidas son seguras como valores por defecto.
Si al actualizar una variable compartida falla una parte
codaracloud shared-vars reconcile --client … --project … --env ….Conectar una base de datos
Las credenciales de la base de datos no se definen a mano. Al conectar una base de datos a una app, se inyectan automáticamente sus variables de conexión y se mantienen al día. Consulta Bases de datos.
$ codaracloud apps connections add my-api main-db --client my-workspaceCopiar entre entornos
Cuando preparas un entorno nuevo, la consola puede copiar las variables de otro entorno. Las claves gestionadas por la base de datos o por la plataforma no se copian, porque se crean para cada entorno y no deben compartirse.
Build frente a runtime
Las variables de entorno son solo de runtime. No están disponibles mientras se hace el build de tu imagen. Si el build necesita un valor público (por ejemplo, la URL de una API que se compila dentro del bundle de un frontend), guárdalo en el repositorio, en un archivo que tu framework lea durante el build (una app de Next.js usa .env.production), o haz el build con tu propio Dockerfile y pásalo como argumento de build. Los argumentos de build solo llegan a un Dockerfile tuyo, no a los builds con Railpack, Nixpacks o de sitios estáticos. Nunca pongas un secreto en ninguno de los dos. Consulta Build y deploy.
Buenas prácticas
- Lee
PORTdel entorno en lugar de fijar un puerto en el código. - Ten un
.env.exampleen tu repositorio: el asistente de deploy te ofrece sus claves al crear la app. - Si se filtra un secreto, cámbialo en su origen y después actualízalo aquí. Mostrar un valor queda auditado, pero todo lo demás también: trata el registro de auditoría como un historial, no como un control.
- Usa variables compartidas para todo lo que necesite más de una app del entorno.
Última actualización:
