Status
Ativo, substituído, falhou, revertido ou expirado. A versão no ar fica destacada no topo da lista.
Deploys · rollback · sem downtime
Cada deploy vira uma versão. Voltar leva um clique.
Todo envio de código, pelo GitHub, pela CLI ou pelo painel, entra no histórico do app. Se a versão nova der problema, você volta para a anterior sem refazer nada. Nos planos maiores, a plataforma volta sozinha ou nem tira o app do ar.
vertracloud.app/dashboard/apps/loja-api/deploys
loja-api
4 versõesRollback automático
AtivoBuild de 41 s
- Ver log
feat: cupom de primeira compra
Falhou7c4e2f1mainBuild de 38 s
fix: timeout no checkout
SubstituídoCLIBuild de 12 s
Enviado pelo painel
SubstituídoPainel
≤ 30versões anteriores guardadas
≤ 30dias de validade por versão
60 sde janela do rollback automático
Aba Rollbacks
O histórico do código, versão por versão.
Cada envio de código vira uma versão completa, venha de onde vier. A aba Rollbacks mostra qual está no ar e o que veio antes. Quem fez o quê continua na aba Atividades.
Commit e mensagem
O SHA curto e a mensagem do commit. Envio sem mensagem ganha um rótulo pela origem, como “Enviado pela CLI”.
Origem
GitHub com a branch, CLI, painel ou editor de arquivos. Um rollback também entra na lista, como versão nova.
Build e log
Quanto tempo o build levou. Quando a versão falha, “Ver log” abre o registro daquela queda.
No Economy, a aba mostra o histórico sem voltar versões. Em apps que já existiam, o histórico começa no próximo envio de código.
Rollback · a partir do Pro
Volta o código. Os dados ficam.
Escolha a versão e confirme. A plataforma troca os arquivos e reinicia o app na mesma operação. O rollback entra no histórico como uma versão nova, então dá para desfazê-lo do mesmo jeito.
O código volta
Todos os arquivos do código voltam como estavam naquela versão. Arquivos que chegaram por commits depois dela são removidos.
Os dados ficam
O que o app grava rodando, como um banco SQLite ou uploads, não faz parte de nenhuma versão e fica como está. Para voltar dados, use os Snapshots.
Variáveis, só se você marcar
Por padrão, as variáveis atuais ficam. Marque a opção para voltar as variáveis com que aquela versão rodava. O diálogo lista quais mudariam, só pelo nome, sem mostrar valores.
Voltar para 3b9a0d4
“fix: timeout no checkout” (ontem, 18:04)
Arquivos do código: sempre voltam.
Voltar as variáveis de ambiente daquele deploy
Variáveis que mudam
- DISCORD_TOKENalterada
- NEW_FEATUREserá removida
Os dados que o app criou rodando não voltam. O app reinicia ao confirmar.
Rollback automático · a partir do Intermediary
Se a versão nova cair ao iniciar, a anterior volta sozinha.
Vem ligado nos planos que incluem o recurso, e dá para desligar nas configurações do app.
- 01
O deploy reinicia o app
A versão nova sobe com o código que acabou de chegar.
- 02
Caiu no primeiro minuto
Se o app parar nos primeiros 60 segundos, o auto-restart não insiste na versão nova: a plataforma volta para a anterior, uma vez só.
- 03
Você fica sabendo
Uma notificação diz que o deploy caiu e para qual versão o app voltou, com link para o log da versão que falhou.
- Só os arquivos do código voltam. As variáveis ficam como estão.
- Se a versão anterior também cair, o app fica parado e você é avisado. Não existe loop de rollbacks.
- Uma queda depois do primeiro minuto é tratada como queda normal, pelo auto-restart.
Deploy sem downtime · Enterprise
A versão nova sobe ao lado. O tráfego só muda quando ela responde.
Num app que recebe tráfego web, o deploy não derruba a versão no ar: a nova sobe junto, passa pela checagem de saúde e só então assume.
- 01
Sobe ao lado
A versão nova instala as dependências, faz o build e inicia enquanto a atual continua atendendo.
- 02
Checagem de saúde
A plataforma faz requisições no caminho configurado (padrão “/”) até ter duas respostas boas seguidas. Qualquer resposta HTTP conta, até 404; erro 5xx ou conexão recusada, não.
- 03
Troca
Saudável, a versão nova passa a receber o tráfego e a anterior é desligada.
- 04
Ou descarta
Se a versão nova não ficar saudável em cerca de 2 minutos, ela é descartada e a anterior segue no ar, sem ter parado.
O que saber antes de ligar
A segunda cópia não conta na RAM do seu plano durante a troca. Se o servidor não tiver memória livre para ela, o deploy para a versão atual antes de subir a nova, com o rollback automático valendo.
- As duas versões usam a mesma pasta e rodam juntas por até cerca de 2 minutos. Um arquivo JSON gravado pelas duas ao mesmo tempo pode se corromper; SQLite costuma aguentar. Uma migração de banco feita na inicialização roda com a versão anterior ainda atendendo.
- Um app que lê arquivos a cada requisição (PHP, site estático, Next.js ou Nuxt já buildado, imports tardios em Python) pode servir arquivos misturados enquanto o deploy instala e faz o build. Para esses, use o modo Desligado.
- Um app que só escuta em 127.0.0.1 não passa na checagem de saúde. O log diz o motivo.
- Durante o build, o terminal mostra a versão que está no ar. O build aparece nos logs de instalação.
- Perto da troca, as duas versões atendem juntas por alguns segundos.
Bots e workers
Por que bots não usam deploy sem downtime por padrão.
Dois processos com o mesmo token recebem os mesmos eventos. Durante a troca, um comando por prefixo seria respondido duas vezes, um slash command daria erro de interação já respondida numa das cópias e tarefas agendadas rodariam em dobro. E um bot não recebe tráfego web, então não há tráfego para trocar de versão.
Três modos, nas configurações do app
Automático
O padrão. Sem downtime só para apps que recebem tráfego web; bots e workers param e sobem, com o rollback automático.
Ligado
Força o deploy sem downtime em qualquer app, inclusive bots. Sem tráfego web, a versão nova é saudável depois de 30 segundos rodando sem cair. Durante a troca, um evento pode ser respondido duas vezes.
Desligado
A versão atual para antes de a nova subir. Serve para apps que leem arquivos a cada requisição; o app fica alguns segundos fora do ar.
Limites por plano
Quantas versões ficam guardadas, e por quanto tempo.
As versões contam além da que está no ar. A validade começa quando a versão deixa de ser a ativa; a versão no ar nunca expira. Depois da validade, a versão continua no histórico, mas não dá mais para voltar a ela.
| Plano | Versões anteriores | Validade | Rollback automático | Sem downtime |
|---|---|---|---|---|
| Economy | Só leitura | Não incluído | Não incluído | |
| Pro | 3 | 7 dias | Não incluído | Não incluído |
| Scale | 5 | 14 dias | Não incluído | Não incluído |
| Intermediary | 10 | 30 dias | Incluído | Não incluído |
| Enterprise-4 · 6 · 8 | 15 | 30 dias | Incluído | Incluído |
| Enterprise-12 · 14 · 16 | 20 | 30 dias | Incluído | Incluído |
| Enterprise-18 · 20 · 22 · 24 | 25 | 30 dias | Incluído | Incluído |
| Enterprise-26 · 28 · 30 · 32 | 30 | 30 dias | Incluído | Incluído |
No Enterprise, o número de versões cresce com o degrau do plano.
Comparar planosPerguntas frequentes
Antes do seu próximo deploy
O que acontece com código, dados e variáveis quando você volta uma versão.
O rollback apaga os dados do meu app?
Não. O rollback troca só o código. O que o app grava rodando, como um banco SQLite ou arquivos enviados pelos usuários, fica como está. Um arquivo que você mesmo commitou volta como qualquer outro arquivo do código. Para voltar dados, use os Snapshots.
Dá para voltar as variáveis de ambiente junto?
Sim, se você marcar a opção no diálogo. Ela volta as variáveis com que aquela versão rodava. Antes de confirmar, o diálogo lista só os nomes das variáveis que mudariam; os valores nunca aparecem.
Funciona com GitHub, CLI e upload pelo painel?
Sim. Todo envio de código vira uma versão completa, venha de onde vier, e qualquer uma delas pode ser o destino de um rollback enquanto estiver dentro do limite e da validade do plano.
Meu app já existia. Consigo voltar para versões antigas?
O histórico começa no primeiro envio de código depois do lançamento do recurso. Versões anteriores a isso não foram guardadas, então não há como voltar para elas.
O que acontece com as versões se eu mudar de plano?
Valem o número de versões e a validade do plano novo. Num downgrade, as versões além do limite deixam de estar disponíveis; num upgrade, o que já foi apagado não volta.
Posso desligar o rollback automático?
Sim, nas configurações do app ou pela API, em PATCH /v1/apps/:id/config. Desligado, uma queda logo depois do deploy segue o auto-restart normal.
A partir do Pro
Faça deploy sabendo que dá para voltar.
Crie a conta, suba o app e o histórico começa no primeiro envio de código.