Pular para o conteúdo principal
Um template com mais de um serviço cria uma stack: uma aplicação e os bancos de dados gerenciados de que ela precisa, criados juntos, conectados e gerenciados como um grupo. Neste tutorial você escreve um template que deixa o usuário escolher Postgres ou SQLite, ativar opcionalmente um cache Redis e conecta o app a cada banco com placeholders e certificados de cliente TLS, sem que ninguém digite uma string de conexão. Cada banco tem endereço e porta públicos próprios, e o app se conecta com uma senha mais um certificado de cliente que a plataforma prepara antes do primeiro boot.

Antes de começar

Você concluiu o tutorial do primeiro template de código ou conhece o básico do manifesto e da CLI.
Um plano com espaço para o app e os bancos de dados. Este template precisa de no mínimo 512 MB para o app, 1.024 MB para o Postgres e 512 MB para o Redis, ou seja, 2.048 MB no maior caso. A memória de cada serviço sai do total do plano, veja Planos e limites.
Só o dono de um workspace pode fazer deploy de um template nele. Um membro vê os templates e usa as stacks que já existem.

Passo a passo

1

Decida o que cada resposta altera

Anote primeiro as perguntas e o que cada resposta liga. Esta tabela é o desenho do manifesto:Não há linguagem de expressões no manifesto. Você tem duas ferramentas: sets em uma opção, que altera várias coisas de uma vez, e when, que é uma igualdade sobre uma pergunta anterior. Use sets quando uma escolha muda mais de um serviço ou variável, como o storage faz, e when para um simples sim/não.
2

Escreva o código que lê o ambiente

O app nunca monta um endereço: ele lê variáveis e os arquivos de certificado para os quais o manifesto aponta. Crie o src/storage.js (o resto do app é seu):
src/storage.js
Adicione pg, ioredis e better-sqlite3 ao src/package.json, e um pequeno src/server.js que escute em PORT e responda /healthz. Como um banco desligado deixa suas variáveis vazias (a plataforma não as grava), o código consegue saber quais serviços existem checando a variável.
3

Escreva o manifesto

vertracloud.template.yaml
Leia de cima para baixo:
  • sets nas opções. services: { db: "off" } remove o banco na escolha do SQLite; env: { app: ... } adiciona variáveis ao serviço cujo id é app. A última opção escolhida vence quando várias definem a mesma coisa, e sets também pode adicionar memória com ram_extra.
  • when em uma pergunta. cache_ttl só é perguntada, e só é validada, quando cache é true. Um when só pode apontar para uma pergunta que vem antes dele, e equals precisa corresponder ao tipo dessa pergunta (true para booleano, um dos valores das opções para uma escolha).
  • when em um serviço. O serviço cache só é criado quando cache é true. O db não tem when porque o sets de storage já o controla: um serviço aceita apenas uma condição, então escolha um mecanismo por serviço.
  • Placeholders. {{services.db.host}} e os demais leem do serviço cujo id é db. Um placeholder que aponta para um serviço desligado resolve para vazio e a variável não é gravada, então o app nunca vê uma configuração pela metade.
4

Saiba o que a plataforma preenche

Para um serviço de banco de dados, estes placeholders estão disponíveis:Os arquivos de certificado ficam em /app/.vertra/certs/<database_id>/, gravados pela plataforma antes do primeiro boot do app e mantidos em sincronia quando você redefine uma senha ou um certificado. Os bancos de dados na plataforma sempre exigem TLS e certificado de cliente; só a senha nunca conecta, e por isso o manifesto passa os três caminhos. Os placeholders de um serviço de app são {{services.<id>.url}} e .domain, e {{app.url}} e {{app.domain}} dão o endereço do serviço que os está lendo. Veja Conecte o app aos bancos de dados da stack para a mesma informação do lado do usuário, com código para outras linguagens e drivers.
Uma saída também pode usar placeholders, mas {{secret:<n>}} não é permitido ali. Para mostrar um segredo gerado uma única vez, declare-o em secrets e imprima {{secrets.<name>}} com secret: true e once: true.
5

Valide

Tente quebrá-lo de propósito para aprender as mensagens. Renomeie o id do serviço db em um só lugar e você recebe unknown_service; aponte cache_ttl para uma pergunta declarada depois dela e você recebe invalid_when; coloque equals: "yes" em um booleano e você recebe invalid_when (“must be true or false”). Desfaça as alterações e execute de novo.
6

Crie o template e faça o deploy das duas variantes

A primeira chamada cria só a aplicação, com SQLite no próprio disco. A segunda cria uma stack com o app, um Postgres e um Redis: o deploy cria os bancos de dados, cria o app com os certificados já no lugar, preenche as variáveis, inicia o app e espera o /healthz. Cada deploy é um job com chave de idempotência, e uma falha desfaz tudo o que ele criou.Abra o endereço de cada app e recarregue: o contador sobe nos dois. Depois execute vertra stack list e vertra stack get <id> para ver os membros, as conexões entre eles e o template de onde a stack veio.
7

Conviva com a stack

A página da stack lista como cada variável do app está conectada a cada banco de dados, e o painel How to connect mostra o código para a linguagem do usuário. Quando a senha ou o certificado de um banco é redefinido, as variáveis e os arquivos de certificado do app são recalculados e o app precisa de um reinício, o que o painel e a API avisam. Quando você publica uma nova versão do template, vertra stack update <id> --check mostra o que mudaria antes de você confirmar. Veja Stacks e Atualizações e rollback.

Solução de problemas

Próximos passos

Última modificação em 30 de outubro de 2026