Variables y referencias
Variables de servicio, variables compartidas, referencias `${{Service.VAR}}` entre servicios y las variables integradas SKIFFLY_* que recibe cada contenedor.
Las variables se guardan por entorno, ya sea para un servicio o compartidas por todos los servicios del entorno. Las variables de servicio tienen prioridad sobre las compartidas con el mismo nombre. Los valores se cifran en reposo y se inyectan en el contenedor como variables de entorno en el momento del despliegue.
Servicio → Variables. Las variables compartidas viven en Variables compartidas del entorno. El editor en bruto acepta texto con formato .env para ediciones en bloque.
Referencias#
Un valor puede apuntar a otra variable en lugar de repetirla:
| Sintaxis | Significado |
|---|---|
${{Postgres.DATABASE_URL}} | variable DATABASE_URL del servicio llamado Postgres (funcionan el nombre, el slug o el id) |
${{shared.REGION}} | variable compartida REGION del entorno |
${{Postgres.SKIFFLY_PRIVATE_DOMAIN}} | una variable integrada de otro servicio |
https://${{self.SKIFFLY_PUBLIC_DOMAIN}} | self: el servicio dueño de la variable (también en plantillas y @skiffly/config) |
https://${{SKIFFLY_PUBLIC_DOMAIN}} | sin ámbito: igual que self; un nombre desconocido sin ámbito se deja como texto literal |
Las referencias se resuelven en el momento del despliegue, de forma recursiva (una variable que referencia una variable que referencia una integrada funciona). Cada servicio se renderiza con su propio entorno, así que la misma referencia da la base de datos de staging en staging y la de producción en production. Las referencias que no se pueden resolver se convierten en una cadena vacía y en una advertencia en el log del despliegue.
skiffly variables set 'DATABASE_URL=${{Postgres.DATABASE_URL}}' 'REDIS_URL=${{Redis.REDIS_URL}}'Las plantillas de Postgres, MySQL, Redis y MongoDB ya exponen DATABASE_URL, MYSQL_URL, REDIS_URL y MONGO_URL construidas a partir de sus propias credenciales y hostname privado, así que una app normalmente necesita una referencia por base de datos.
Variables integradas#
Cada contenedor recibe estas, y otros servicios pueden referenciarlas:
| Variable | Valor |
|---|---|
PORT | el puerto en el que el servicio debe escuchar |
SKIFFLY_PUBLIC_DOMAIN | primer dominio público del servicio (api-x1y2.skiffly.cloud o un dominio propio verificado); sin definir si no hay dominio |
SKIFFLY_PRIVATE_DOMAIN | hostname en la red privada (api) |
SKIFFLY_SERVICE_NAME, SKIFFLY_SERVICE_ID | nombre e id del servicio |
SKIFFLY_PROJECT_ID | id del proyecto |
SKIFFLY_ENVIRONMENT, SKIFFLY_ENVIRONMENT_ID | slug del entorno (production, pr-42) e id |
SKIFFLY_DEPLOYMENT_ID | id del despliegue en ejecución |
SKIFFLY_GIT_COMMIT_SHA | commit que se construyó (servicios de repositorio) |
SKIFFLY_DEPLOYMENT_ID y SKIFFLY_GIT_COMMIT_SHA solo existen en el propio servicio. PORT y SKIFFLY_PUBLIC_DOMAIN también se pueden referenciar desde otro servicio: ${{api.SKIFFLY_PUBLIC_DOMAIN}} se resuelve al primer dominio público de api en el mismo entorno (${{api.PORT}} a su puerto) en el momento en que se despliega el servicio que lo referencia; sin dominio, la referencia se resuelve a una cadena vacía y el log del despliegue lo avisa. Añadir un dominio a api más tarde no actualiza web hasta que web se vuelva a desplegar.
Secretos#
Las variables se guardan cifradas (AES-256-GCM) y en el panel solo las ven los miembros del espacio de trabajo. La CLI enmascara los valores en las tablas y solo los imprime con --kv/--json; list-variables del servidor MCP devuelve los nombres a menos que el agente pida los valores. En configuración como código usa preserve() y generate() para que los secretos nunca terminen en el archivo.