Fundaia

Entrar Empezar

Variables

Las variables son lo que recibe el contenedor como entorno. Esta página explica los tipos que hay, cómo se referencia la variable de otro servicio y cuándo llega un cambio al contenedor.

Tipos

TipoQué guarda¿Se puede leer después?
NormalEl texto tal cualSí
SecretoEl valor cifrado con AES-256-GCMSí, revelándolo; queda registrado quién y cuándo
SelladoUn secreto que ya nadie puede leer ni cambiarNo. Solo se puede borrar
ReferenciaUna expresión que apunta a otra variableSe ve la expresión
fundaia vars list tienda api
fundaia vars list tienda api --reveal          # descifra los secretos; queda registrado
fundaia vars set tienda api JWT_SECRET … --secret
fundaia vars set tienda api STRIPE_KEY … --sealed
fundaia vars import tienda api .env --secret   # un .env entero, en una petición
fundaia vars unset tienda api JWT_SECRET

Si el valor de un secreto aparece en una línea de log, se tacha antes de guardarse. No cuentes con ello como única defensa: no los imprimas.

Variables selladas

Sellar una variable quita para siempre la posibilidad de leerla o sobrescribirla desde la web, el CLI, la API o el MCP; el contenedor la sigue recibiendo. Protege frente a una captura de pantalla, una terminal compartida o una sesión robada, y frente a cambiar una credencial por descuido. No protege frente a quien puede desplegar código en el proyecto: un contenedor puede imprimir su entorno.

fundaia vars seal tienda api STRIPE_KEY --confirm STRIPE_KEY

--sealed al crearla es la única forma de que el valor no sea legible en ningún momento. Una referencia no se puede sellar.

Variables compartidas

Lo que todos los servicios necesitan igual (una clave de API, una región, un interruptor) se escribe una vez en las variables compartidas del proyecto: el botón de controles en la barra del lienzo, Gestionar en la pestaña Variables de cualquier servicio, fundaia shared o set_shared_variable.

  • Todos los entornos o solo uno. Una compartida de proyecto llega a cada servicio de cada entorno; una de entorno (--env-only), solo a los de ese entorno, y gana a la de proyecto con la misma clave.
  • Gana lo más cercano. Si un servicio define la misma clave, se queda con la suya. La pestaña Variables de cada servicio enseña, aparte, las compartidas que recibe.
  • Llegan en el siguiente despliegue de cada servicio: cambiar una compartida no reinicia todo el proyecto de golpe.
  • Desde otra variable se leen con ${{ shared.CLAVE }}. Una compartida de entorno puede apuntar a un servicio de ese entorno (${{ Postgres.DATABASE_URL }}); una de proyecto no, porque no sabría de qué entorno.
fundaia shared set tienda STRIPE_SECRET_KEY sk_live_… --secret
fundaia --env staging shared set tienda REGION eu-west --env-only
fundaia shared list tienda
fundaia shared unset tienda REGION

Referencias

Una variable puede apuntar a la de otro servicio del proyecto, por su nombre:

DATABASE_URL = ${{ Postgres.DATABASE_URL }}
CONNECTION   = postgres://${{ Pg.USER }}@${{ Pg.HOST }}/db
PUBLIC_URL   = https://${{ INFRA_PUBLIC_DOMAIN }}
FormaApunta a
${{ Servicio.CLAVE }}Una variable de otro servicio del proyecto, en el mismo entorno
${{ CLAVE }}Otra variable de este mismo servicio
${{ shared.CLAVE }}Una variable compartida del proyecto o del entorno

En un proyecto con varios entornos, ${{ Postgres.DATABASE_URL }} en staging es el Postgres de staging: la misma referencia apunta a cada entorno por separado, y por eso una copia de un entorno funciona sin reescribir nada. Un valor escrito a mano (una URL pública de producción, por ejemplo) se copia tal cual.

La sintaxis es la de Railway. La referencia se resuelve al desplegar, no al escribirla: si se rota la contraseña del Postgres, todos los que la referencian la reciben en su siguiente despliegue sin tocar nada. Las referencias son también lo que dibuja las flechas del lienzo; para escribirlas de un gesto, usa Conexiones.

La plataforma rechaza al guardar:

  • una referencia a un servicio que no existe o que no está desplegado en este entorno;
  • una referencia que cerraría un ciclo (A lee de B, B lee de A); el mensaje nombra a los implicados.

Al renombrar un servicio, las referencias que lo nombran se reescriben solas.

Cuándo llegan al contenedor

Al desplegar. Un contenedor recibe su entorno una sola vez, al crearse. Por eso, al guardar una variable de un servicio que está en marcha, la plataforma lo vuelve a desplegar con la configuración nueva. Uno dormido o sin desplegar no se toca: la recibirá en su próximo despliegue (despertar arranca el mismo contenedor de antes, con su entorno de entonces).

Todo despliegue arranca con las variables de ese momento, también una vuelta atrás: lo que recupera es la imagen de entonces, no su configuración.

Las variables con prefijo público (VITE_, NEXT_PUBLIC_…) además entran en la construcción de un frontend; ver Frontends.

Para tenerlas en tu ordenador, fundaia run tienda web -- npm run dev arranca el comando con las mismas variables que recibe el contenedor, sin escribirlas en disco; las selladas no salen (CLI).

Variables que pone la plataforma

Todo contenedor recibe estas, que no se guardan y no se pueden pisar:

VariableValor
PORTEl puerto en el que debe escuchar el proceso
INFRA_PROJECT_NAME, INFRA_ENVIRONMENT_NAME, INFRA_SERVICE_NAMEDónde corre
INFRA_PRIVATE_HOSTSu nombre en la red del proyecto, el que usan sus vecinos
INFRA_PUBLIC_DOMAINSu host público, o vacío si es privado
INFRA_DEPLOYMENT_ID, INFRA_GIT_COMMIT_SHAEl despliegue y el commit que lo produjeron

Los componentes del catálogo traen además las suyas, generadas al crearlos: ver Bases de datos y componentes.