Saltar al contenido principal
Una plantilla con más de un servicio crea un stack: una aplicación y las bases de datos gestionadas que necesita, creadas juntas, conectadas y administradas como un grupo. En este tutorial escribes una plantilla que permite al usuario elegir entre Postgres o SQLite, activar opcionalmente una caché Redis, y conecta la aplicación con cada base de datos mediante placeholders y certificados de cliente TLS, sin que nadie escriba una cadena de conexión. Cada base de datos tiene su propia dirección y puerto públicos, y la aplicación se conecta con una contraseña más un certificado de cliente que la plataforma prepara antes del primer arranque.

Antes de empezar

Terminaste el tutorial del primera plantilla de código o conoces lo básico del manifiesto y de la CLI.
Un plan con margen para la aplicación y las bases de datos. Esta plantilla necesita al menos 512 MB para la aplicación, 1.024 MB para Postgres y 512 MB para Redis, es decir, 2.048 MB en el caso más grande. La memoria de cada servicio sale del total del plan, consulta Planes y límites.
Solo el propietario de un workspace puede desplegar una plantilla en él. Un miembro ve las plantillas y usa los stacks que ya existen.

Paso a paso

1

Decide qué cambia cada respuesta

Anota primero las preguntas y lo que activa cada respuesta. Esta tabla es el diseño del manifiesto:No hay un lenguaje de expresiones en el manifiesto. Tienes dos herramientas: sets en una opción, que cambia varias cosas a la vez, y when, que es una igualdad sobre una pregunta anterior. Usa sets cuando una elección cambia más de un servicio o variable, como hace storage, y when para un simple sí/no.
2

Escribe el código que lee el entorno

La aplicación nunca construye una dirección: lee variables y los archivos de certificado a los que apunta el manifiesto. Crea src/storage.js (el resto de la aplicación es tuyo):
src/storage.js
Añade pg, ioredis y better-sqlite3 a src/package.json, y un pequeño src/server.js que escuche en PORT y responda a /healthz. Como una base de datos desactivada deja sus variables vacías (la plataforma no las escribe), el código puede saber qué servicios existen comprobando la variable.
3

Escribe el manifiesto

vertracloud.template.yaml
Léelo de arriba abajo:
  • sets en las opciones. services: { db: "off" } elimina la base de datos en la opción SQLite; env: { app: ... } añade variables al servicio cuyo id es app. Gana la última opción elegida cuando varias definen lo mismo, y sets también puede añadir memoria con ram_extra.
  • when en una pregunta. cache_ttl solo se pregunta, y solo se valida, cuando cache es true. Un when solo puede apuntar a una pregunta que venga antes, y equals debe coincidir con el tipo de esa pregunta (true para un booleano, uno de los valores de las opciones para una elección).
  • when en un servicio. El servicio cache solo se crea cuando cache es true. db no tiene when porque el sets de storage ya lo controla: un servicio acepta una sola condición, así que elige un mecanismo por servicio.
  • Placeholders. {{services.db.host}} y los demás leen del servicio cuyo id es db. Un placeholder que apunta a un servicio desactivado se resuelve como vacío y la variable no se escribe, de modo que la aplicación nunca ve una configuración a medias.
4

Conoce lo que rellena la plataforma

Para un servicio de base de datos, están disponibles estos placeholders:Los archivos de certificado viven en /app/.vertra/certs/<database_id>/, los escribe la plataforma antes del primer arranque de la aplicación y se mantienen sincronizados cuando restableces una contraseña o un certificado. Las bases de datos de la plataforma siempre exigen TLS y un certificado de cliente; una contraseña sola nunca conecta, por eso el manifiesto pasa las tres rutas. Los placeholders de un servicio de aplicación son {{services.<id>.url}} y .domain, y {{app.url}} y {{app.domain}} dan la dirección del servicio que los está leyendo. Consulta Conecta la aplicación a las bases de datos del stack para ver la misma información desde el lado del usuario, con código para otros lenguajes y drivers.
Un output también puede usar placeholders, pero {{secret:<n>}} no se permite ahí. Para mostrar una sola vez un secreto generado, decláralo en secrets e imprime {{secrets.<name>}} con secret: true y once: true.
5

Valida

Intenta romperlo a propósito para aprender los mensajes. Cambia el id del servicio db en un solo sitio y obtendrás unknown_service; apunta cache_ttl a una pregunta declarada después de ella y obtendrás invalid_when; pon equals: "yes" en un booleano y obtendrás invalid_when (“must be true or false”). Déjalos como estaban y vuelve a ejecutarlo.
6

Crea la plantilla y despliega las dos variantes

La primera llamada crea solo la aplicación, con SQLite en su propio disco. La segunda crea un stack con la aplicación, un Postgres y un Redis: el despliegue crea las bases de datos, crea la aplicación con los certificados ya colocados, rellena las variables, la inicia y espera a /healthz. Cada despliegue es un job con una clave de idempotencia, y un fallo deshace todo lo que creó.Abre la dirección de cada aplicación y recarga: el contador sube en ambas. Después ejecuta vertra stack list y vertra stack get <id> para ver los miembros, las conexiones entre ellos y la plantilla del que procede el stack.
7

Convive con el stack

La página del stack lista cómo está conectada cada variable de la aplicación a cada base de datos, y el panel Cómo conectarte muestra código para el lenguaje del usuario. Cuando se restablece la contraseña o el certificado de una base de datos, se recalculan las variables y los archivos de certificado de la aplicación y esta necesita un reinicio, que el panel y la API anuncian. Cuando publicas una nueva versión de la plantilla, vertra stack update <id> --check muestra qué cambiaría antes de que te comprometas. Consulta Stacks y Actualizaciones y rollback.

Solución de problemas

Próximos pasos

Última modificación el 30 de octubre de 2026