Vercel vs Railway vs Render depende do risco de rollback

Um SaaS Next.js herdado não é seguro só porque a hospedagem oferece um botão de Rollback. Ele é seguro quando a aplicação anterior ainda consegue funcionar com o banco de dados atual e os segredos corretos enquanto alguém que não escreveu o sistema descobre o que mudou. Nesse teste, a Vercel oferece o rollback de código mais limpo para uma aplicação Next.js convencional, a Render apresenta o modelo de ambiente completo mais explícito e a Railway ocupa um meio termo prático para uma pilha de serviço e banco.

Minha escolha padrão é a Vercel quando a aplicação cabe no seu modelo gerenciado de Next.js e o banco já segue um processo disciplinado de migrações. Escolho a Render quando preciso de cópias descartáveis de vários serviços e armazenamentos definidos como infraestrutura. Escolho a Railway quando a aplicação herdada se comporta mais como um serviço em contêiner e a equipe quer um painel de projeto simples com ambientes isolados. Nenhuma dessas escolhas desfaz uma migração SQL destrutiva nem reverte a rotação de uma credencial.

A decisão, portanto, começa pelo limite de recuperação, não por uma tabela de recursos. Código, configuração, dados, tarefas em segundo plano e recursos do navegador avançam em ritmos diferentes. Uma hospedagem pode trocar o código perfeitamente e o sistema continuar quebrado porque um dos outros elementos já avançou.

A mesma falha revela três modelos de recuperação

Uma comparação justa precisa de um único incidente. Considere este: uma agência herda um SaaS Next.js com Postgres, login por e-mail, webhook de cobrança e um worker que envia mensagens em fila. Uma versão renomeia users.plan para users.plan_code, muda a carga do worker e rotaciona AUTH_SECRET. O desenvolvedor testou uma página de preview com dados de produção, fez o merge às 16:00 e viu verificações de saúde aprovadas. Às 16:07, sessões existentes começaram a falhar, o worker antigo passou a rejeitar novas cargas e uma rota administrativa pouco usada ainda consultava users.plan.

O operador quer colocar o código anterior no ar. A ação parece simples, mas faz cinco perguntas separadas:

• A hospedagem consegue direcionar o tráfego para uma compilação conhecida sem recompilá-la?
• Quais valores de variáveis de ambiente essa compilação receberá?
• A migração removeu dados de que a compilação anterior precisa?
• O tráfego do preview pode chegar a dados reais ou enviar e-mails reais?
• Um deploy automático substituirá imediatamente a compilação de recuperação?

A Vercel consegue redirecionar o tráfego de produção para um deploy anterior elegível na camada de roteamento. Seu guia atual de rollback diz que isso acontece sem recompilação, e a documentação de Instant Rollback avisa que bancos e APIs externos não voltam com o deploy. Esse aviso está no centro da comparação, não em uma nota de rodapé.

A Railway descreve o rollback como um novo deploy da versão anterior selecionada, restaurando sua imagem Docker e variáveis personalizadas. A Render inicia um novo deploy usando o artefato de compilação escolhido e reutiliza as variáveis do serviço daquele deploy, enquanto alguns valores de grupos de ambiente compartilhados continuam atuais. As três preservam parte do estado anterior da aplicação. Elas diferem no que preservam e na velocidade com que devolvem esse estado ao serviço.

Nesse incidente, o primeiro rollback provavelmente só recuperará a rota administrativa se o banco ainda expuser users.plan. Ele pode invalidar todas as sessões se o deploy restaurado receber o AUTH_SECRET errado. Também pode deixar duas versões do worker consumindo tarefas incompatíveis. Um evento verde na plataforma prova que o mecanismo de deploy funcionou. Não prova que o SaaS se recuperou.

Deploy imutável é mais restrito que versão reversível

As três hospedagens preservam artefatos de deploy de alguma forma, mas um deploy imutável não torna a versão reversível. Imutabilidade significa que o artefato compilado não muda depois de criado. Reversibilidade significa que todo o comportamento visto pelo usuário pode voltar a um estado conhecido depois de mudanças em código, configuração e dados. A primeira propriedade ajuda a segunda, mas não a garante.

Essa distinção pega sistemas Next.js herdados porque um repositório costuma conter várias unidades de publicação que parecem uma única aplicação. O deploy web pode incluir componentes de servidor, handlers de rota e recursos estáticos. Outro processo pode consumir filas. Uma tarefa agendada pode rodar a partir da configuração da plataforma. Postgres, armazenamento de objetos, cobrança e envio de e-mails mantêm estado em outros lugares. Reverter um artefato imutável muda apenas uma linha desse inventário.

As verificações de saúde estreitam ainda mais a visão. Uma chamada a /api/health pode provar que o processo iniciou e responde por HTTP. Ela não prova que uma sessão criptografada existente pode ser lida, uma linha antiga pode ser atualizada, uma assinatura de webhook pode ser verificada ou uma tarefa em fila pode ser consumida. Para esse SaaS, a verificação útil da versão precisa percorrer esses caminhos sem gerar efeitos reais para clientes.

Uso dois níveis de verificação. O endpoint de saúde da plataforma continua rápido e sem efeitos colaterais para que a hospedagem decida se uma instância deve receber tráfego. Uma sonda de publicação separada entra com uma conta sintética, lê e altera um registro descartável, envia uma tarefa de teste e confirma o resultado do worker. Ela roda antes da promoção e depois do rollback; o balanceador nunca deve chamá-la.

O navegador acrescenta outro limite de versão. Um usuário pode manter uma aba aberta durante o deploy e depois enviar um formulário ou solicitar uma ação do servidor a partir de código carregado antes da troca. O Skew Protection da Vercel cuida do desencontro entre recursos e funções Next.js compatíveis, mas os contratos da aplicação ainda precisam tolerar a transição. Deploys da Railway e da Render também exigem que a aplicação processe requisições iniciadas antes da mudança de tráfego. Evite alterar identificadores de ações, formatos de cookies e campos obrigatórios de forma que uma sessão aberta falhe imediatamente.

Tarefas em segundo plano criam a sobreposição mais longa. Uma tarefa escrita às 15:58 pode rodar depois da versão das 16:00, e uma nova tentativa pode ocorrer depois do rollback das 16:07. Produtores e consumidores precisam de uma janela de compatibilidade maior que a troca do tráfego web. Versione as cargas, torne campos novos opcionais no início e permita que consumidores enviem uma versão desconhecida para quarentena em vez de descartá-la ou tentar para sempre.

A reprodutibilidade da compilação merece a mesma cautela. Um rollback que reutiliza um artefato preservado é mais seguro que recompilar um commit antigo com o registro de pacotes, a tag da imagem base e as ferramentas de hoje. A Vercel aponta para um deploy existente. A Render afirma que reutiliza um artefato retido em rollbacks comuns. A Railway restaura a imagem Docker selecionada em seu fluxo documentado. Os limites de retenção ainda decidem se o artefato existirá quando for necessário.

Tags mutáveis de contêiner enfraquecem essa promessa. A Render avisa expressamente que o rollback de uma imagem referenciada por tag pode baixar o que a tag aponta agora, enquanto um digest identifica a mesma imagem. A regra geral vai além de uma hospedagem: registre um digest ou um identificador de deploy da plataforma como alvo de recuperação. Um commit Git não é um binário, e recompilá-lo é um novo evento.

Chame uma versão de reversível apenas quando a equipe puder restaurar um conjunto testado de versões web, worker, esquema e configuração sem adivinhar. Essa definição é mais rígida que o vocabulário das plataformas e evita a pior surpresa em um incidente: descobrir que o botão funcionou exatamente como documentado enquanto a aplicação continuou indisponível.

A Vercel vence no rollback puro de código Next.js

A Vercel é a primeira opção mais segura quando a unidade de recuperação é um deploy Next.js e os sistemas com estado ficam fora dela. Cada deploy recebe um endereço único, e os domínios de produção apontam para um deles. O Instant Rollback muda esse ponteiro para um deploy anterior de produção em vez de recompilar o código fonte. Das três opções, é o mais próximo de uma troca atômica de código.

A vantagem operacional é a baixa carga mental durante um incidente. Um operador pode examinar deploys recentes, identificar um commit conhecido, fazer rollback, conferir o estado e comparar logs. A sequência da CLI tem um formato de saída claro:

vercel list
vercel inspect <bad-deployment-url>
vercel rollback <good-deployment-url>
vercel rollback status

vercel list retorna deploys recentes com seus endereços e idades; o operador escolhe o candidato de produção. vercel inspect liga esse candidato ao commit Git e aos metadados de configuração. vercel rollback status informa se a mudança de roteamento terminou. A documentação também diz que um rollback desativa a atribuição automática do domínio de produção até que alguém promova um deploy, o que evita que o próximo push desfaça silenciosamente a recuperação.

Há limites. Contas Hobby só podem voltar ao deploy de produção imediatamente anterior, enquanto planos superiores permitem escolher outros deploys de produção elegíveis. Um preview que nunca recebeu um domínio de produção geralmente não serve como alvo de Instant Rollback. A política de retenção merece revisão antes do incidente, mesmo que a Vercel mantenha deploys recentes de produção sob regras documentadas.

A Vercel também oferece Skew Protection para versões compatíveis do Next.js. Ele ajuda o navegador a permanecer nos recursos e funções de servidor de um mesmo deploy enquanto uma versão nova entra no ar. Isso reduz o desencontro durante publicações normais, mas não concilia dois esquemas de banco ou dois formatos de tarefa. Trate-o como proteção contra recursos misturados da aplicação, não como uma transação para toda a pilha.

Escolha a Vercel para esse SaaS herdado somente após confirmar que as premissas de execução do Next.js cabem na plataforma, que tarefas longas têm um lugar adequado e que toda mudança de banco continua compatível com a aplicação anterior. Se essas condições falharem, a troca rápida de ponteiro pode devolver código antigo a um mundo que ele não entende mais.

A Railway mantém a pilha de serviços compreensível

A Railway costuma ser mais fácil de entender quando a aplicação Next.js é um serviço entre Postgres, um worker e talvez uma API privada. Seu modelo de projeto e ambiente agrupa esses recursos sem fingir que são um único objeto reversível. Ambientes da Railway isolam mudanças de configuração, e ambientes temporários de PR podem provisionar os serviços afetados por uma proposta.

Um rollback da Railway usa o código fonte ou a imagem do deploy escolhido e restaura as variáveis personalizadas associadas, sujeito à retenção do plano. Essa combinação importa no incidente porque a aplicação anterior e seu antigo AUTH_SECRET podem voltar juntas. Ainda é um novo deploy, não uma mudança de ponteiro, então a recuperação inclui inicialização e verificações de saúde. Meça no seu serviço em vez de supor que a palavra rollback significa instantâneo.

Ambientes de PR podem copiar a forma de um ambiente base, inclusive referências entre serviços e variáveis. O guia atual da Railway explica que ambientes padrão replicam todo o ambiente base, enquanto os focados publicam serviços afetados e dependências. Isso torna um repositório herdado com vários serviços mais acessível: quem revisa pode ver se o serviço web e o worker concordam sobre a carga antes do merge.

O risco está na herança. Se um ambiente de PR herda credenciais de produção ou uma conexão que chega aos dados reais, o isolamento no painel é só visual. Dê aos previews um banco separado, um coletor de e-mails, uma conta de cobrança de teste e segredos incapazes de autorizar ações de produção. Um ambiente temporário deve falhar de modo seguro quando falta uma variável exclusiva de produção.

A Railway oferece um comando de pré-deploy que roda depois da compilação e antes da aplicação, com acesso à rede privada e às variáveis. É um lugar sensato para executar uma migração, mas o lugar não a torna reversível. Se o comando remove users.plan com sucesso e o novo serviço falha depois, o rollback da aplicação não consegue recriar o conteúdo da coluna.

A Railway é minha escolha intermediária. Ela expõe a relação entre serviços melhor que uma visão centrada no frontend e pede menos definição de infraestrutura que um Blueprint completo da Render. Fica menos segura quando pessoas editam variáveis de produção casualmente ou deixam cada serviço publicar sozinho sem registrar quais versões pertencem ao mesmo conjunto.

A Render deixa explícito o limite do ambiente

A Render é mais forte quando a recuperação inclui serviço web, worker, banco e configuração compartilhada declarados. Um Blueprint pode definir esses recursos, e um ambiente de preview pode criar novas instâncias de serviços e armazenamentos para cada PR. A documentação da Render deixa claro que armazenamentos de preview não copiam dados de produção. Esse padrão obriga a equipe a decidir como fornecer dados de teste, o que é saudável.

Ambientes de preview exigem um Blueprint e um plano elegível. Eles podem aplicar valores previewValue e executar um initialDeployHook depois do primeiro deploy bem-sucedido. Para um SaaS herdado, isso permite um teste contido: criar um banco vazio, aplicar migrações, carregar contas sintéticas e exercitar web e worker. Exige mais preparação que uma página de preview, mas testa o limite de falha que importa.

O rollback da Render não é uma troca de ponteiro. A plataforma inicia um novo deploy a partir de um artefato retido. O deploy alvo fornece seu artefato, comando de início, caminho de saúde, quantidade de instâncias e variáveis do serviço. Configurações atuais continuam controlando itens como discos e domínios personalizados, enquanto grupos de ambiente têm comportamento misto. A tabela oficial é bastante franca sobre essa divisão.

A divisão tem duas consequências. Uma variável de serviço salva com o deploy antigo pode voltar, mas um valor dentro de um grupo compartilhado pode continuar atual. Além disso, um disco persistente nunca volta com o serviço. A Render permite restaurar snapshots de disco separadamente, mas rollback da aplicação e recuperação do disco são operações diferentes com riscos diferentes.

Um rollback iniciado no painel desativa deploys automáticos, enquanto um iniciado pela API não. O manual de incidente precisa indicar o caminho usado; caso contrário, duas pessoas podem executar rollbacks aparentemente iguais e deixar estados distintos de automação. A retenção de artefatos também varia conforme o plano, então teste até onde a ação Rollback fica disponível.

No cenário, a Render oferece a melhor fidelidade de preview se toda a pilha estiver descrita em um Blueprint. Também dá ao operador mais detalhes de configuração para entender durante a recuperação. Escolha quando essa explicitude combinar com a equipe. Não escolha só porque um Blueprint parece documentação enquanto segredos, serviços externos ou alterações manuais continuam fora dele.

A migração de banco decide se o rollback é real

A compatibilidade do banco importa mais que a hospedagem quando uma versão altera dados persistentes. Rollback seguro significa que a versão N e a versão N menos um conseguem funcionar durante a janela de recuperação. O padrão confiável adiciona estruturas novas primeiro, move leituras e escritas aos poucos e remove as antigas somente depois que a aplicação anterior já não puder voltar.

Para renomear plan, não renomeie nem remova a coluna na mesma versão que muda o código. Adicione a coluna nova, preencha e mantenha os dois valores sincronizados enquanto código antigo puder rodar:

ALTER TABLE users ADD COLUMN plan_code text;
UPDATE users SET plan_code = plan WHERE plan_code IS NULL;

A nova aplicação deve ler plan_code com fallback temporário para plan e escrever nos dois campos. Uma versão posterior pode parar de ler o campo antigo. Somente após a janela de rollback expirar outra migração deve remover plan. Isso exige mais versões que uma renomeação direta, e essa inconveniência compra recuperação de verdade.

A mesma regra vale para cargas de tarefas. Adicione um campo de versão e faça consumidores aceitarem os formatos antigo e novo antes de produtores emitirem apenas o novo:

{"version":2,"userId":"usr_123","template":"welcome"}

Um worker que rejeita toda carga sem version: 2 não pode coexistir com tarefas de versão 1 na fila. Fazer rollback do processo web pode ampliar o desencontro ao produzir mais tarefas antigas. Drene, coloque em quarentena ou traduza tarefas incompatíveis de propósito; nunca dependa de uma reinicialização para tornar a fila coerente.

Um comando de migração antes do deploy ajuda no sequenciamento, mas uma migração destrutiva precisa de aprovação separada e conferência do backup. Registre o identificador, o horário de início, o estado final e a ação de recuperação testada. Se voltar exige restaurar um backup, declare antes da versão a janela esperada de perda de dados. Restaurar um snapshot pode descartar escritas válidas posteriores ao deploy, então não é um rollback comum.

Sou contra a recomendação popular de colocar prisma migrate deploy no comando de inicialização da aplicação. Ela parece segura porque cada instância se configura sozinha. Em um serviço escalado, várias instâncias podem disputar ou bloquear a inicialização, e uma falha de migração pode transformar um reinício em indisponibilidade. Execute a migração uma vez como ação de publicação, examine o resultado e só então inicie o código novo.

Segredos têm versões mesmo quando o painel esconde

Um rollback precisa do conjunto de segredos que fazia a aplicação alvo funcionar, mas restaurar um segredo antigo pode reabrir uma credencial rotacionada por segurança. Trate rollback de configuração e rotação de credenciais como decisões separadas. A hospedagem guarda valores; seu manual precisa explicar o significado e a validade aceitável.

Variáveis da Vercel são associadas a Production, Preview, Development e ambientes personalizados opcionais, e as mudanças valem para deploys posteriores. A documentação avisa que a compilação restaurada pode assumir uma configuração diferente dos sistemas externos atuais. A Railway diz restaurar as variáveis personalizadas do deploy selecionado. A Render restaura variáveis do serviço, mas não retrocede valores de grupos compartilhados.

Essas diferenças tornam útil um inventário simples de segredos. Guarde nomes e responsáveis junto ao código, nunca os valores:

AUTH_SECRET:
  owner: application
  rotation: dual-read
  rollback: previous value valid for 24 hours
BILLING_WEBHOOK_SECRET:
  owner: billing-provider
  rotation: accept old and new signatures
DATABASE_URL:
  owner: operations
  rollback: never point production code at preview data

dual-read significa que a aplicação aceita temporariamente sessões ou assinaturas feitas com o segredo antigo ou o novo enquanto emite novas com o segredo atual. O suporte depende da biblioteca. Se ela não oferecer isso, espere que uma rotação ou rollback desconecte usuários e registre esse impacto no documento da versão.

Nunca coloque segredos de produção em um preview para deixá-lo realista. Use credenciais de teste restritas e dados separados. Confira também a exposição na compilação: qualquer variável inserida em um valor NEXT_PUBLIC_ fica visível no navegador por definição, independentemente da segurança de armazenamento da plataforma. Uma base herdada merece uma busca por nomes de segredos nos bundles do cliente antes da primeira mudança para produção.

Previews precisam isolar os efeitos colaterais

Um preview só é seguro quando seus efeitos não conseguem escapar. Uma URL única e uma instância separada não impedem envio de e-mails a clientes, cobrança de cartão, consumo de tarefas de produção, alteração de banco compartilhado ou aceitação de webhook real.

A Vercel cria automaticamente previews para branches fora de produção e aceita variáveis de preview, inclusive por branch. Isso funciona bem para a superfície Next.js, mas bancos e workers geralmente precisam de provisionamento externo. Ambientes de PR da Railway podem reproduzir serviços conectados e variáveis do projeto. Ambientes da Render podem criar serviços e armazenamentos novos a partir de um Blueprint sem copiar dados existentes.

Use o mesmo contrato de aceitação em cada hospedagem:

1. Crie um usuário sintético, faça login e atualize a sessão após um novo deploy.
2. Aplique migrações a um banco vazio e a uma cópia limpa com o esquema anterior.
3. Envie e-mails a um coletor e requisições de cobrança a uma conta de teste.
4. Processe uma carga antiga e uma nova com o worker candidato.
5. Faça rollback do candidato e repita o login e o caminho de escrita.

A quinta verificação é a que as equipes pulam. Elas testam o deploy para frente no preview e presumem que o rollback acompanha. Um banco criado apenas com o esquema mais novo não prova que o código antigo tolera o estado posterior à migração. Mantenha uma fixture da versão anterior, execute a migração, publique o código novo e depois republique o antigo contra a fixture migrada.

Proteja previews do acesso público quando contiverem fluxos realistas de clientes. A Vercel oferece opções de proteção, enquanto Railway e Render permitem controlar o acesso com seus modelos de projeto e a autenticação da aplicação. O controle da plataforma não substitui a autorização da aplicação. Teste se um usuário comum do preview não alcança rotas administrativas nem integrações de produção.

O manual de recuperação deve caber em uma tela

Durante uma indisponibilidade, a hospedagem mais segura é aquela cuja sequência de recuperação o operador real já ensaiou. Um manual deve citar evidências e condições de parada, não dizer “faça rollback se precisar”. Coloque este registro compacto no repositório e preencha em cada versão de produção:

release: <git-sha>
previous: <known-good-deployment>
migration: <id-or-none>
compatible_with_previous_code: <yes-or-no>
secret_change: <name-or-none>
web: <deployment-id>
worker: <deployment-id>
recovery_owner: <person>

Quando o incidente começar, congele os deploys automáticos de produção, preserve o deploy com falha e os logs e descubra se os dados mudaram. Se a migração foi aditiva e o segredo anterior ainda é aceito, restaure web e worker como um único conjunto de versão. Verifique login, uma leitura, uma escrita, uma tarefa em fila e o webhook de cobrança. Observe os erros antes de declarar recuperação.

Se a migração foi destrutiva, pare de chamar a ação de rollback de código. Escolha entre corrigir para frente, aplicar um patch de compatibilidade à aplicação anterior ou recuperar o banco. Uma correção para frente costuma preservar mais dados. Restaurar o banco pode se justificar quando a corrupção continua, mas precisa de um corte explícito e de um plano para reconciliar escritas posteriores ao backup.

Na Vercel, registre o endereço exato do deploy de produção e confirme o estado do rollback e do domínio. Na Railway, registre cada deploy de serviço porque web e worker podem se separar. Na Render, registre o deploy alvo, se o rollback partiu do painel ou da API e quais grupos ou discos continuam atuais.

Execute esse exercício antes de mudar de hospedagem. Cronometre a recuperação, abra uma sessão existente e complete uma escrita. Se a plataforma diz que deu certo e esse fluxo falha, a etapa ausente precisa entrar no manual. Migrar de hospedagem não corrige uma dependência desconhecida.

Escolha a hospedagem depois de mapear o sistema herdado

A escolha é Vercel para a troca mais limpa de deploy Next.js, Railway para um espaço compacto de serviço e banco, e Render para um ambiente declarado com vários recursos e previews fiéis. Essa ordem muda se o código herdado usa disco persistente, execução incomum, vários workers independentes ou infraestrutura manual fora da hospedagem.

Antes de decidir, mapeie cinco elementos: processos de execução, armazenamentos de dados, filas e tarefas agendadas, responsáveis por segredos e efeitos externos. Marque qual objeto da hospedagem controla cada um e se sua ação de rollback o altera. Toda célula vazia faz parte do plano de recuperação, não é motivo para supor que a plataforma resolve.

Um projeto herdado gerado por IA costuma esconder chamadas ao banco em ações de servidor, repetir lógica de autenticação e misturar configuração de deploy com código. A FixMyMess pode diagnosticar essa base, reparar lógica e segurança, refatorar e preparar o deploy com verificação especializada, mas a escolha da hospedagem ainda exige o limite de recuperação descrito aqui.

Faça um experimento destrutivo antes de aprovar: suponha que o código novo está no ar há sete minutos, usuários gravaram dados, um segredo mudou e o worker antigo ainda tem tarefas. Peça ao operador que recupere sem o desenvolvedor original. Escolha a hospedagem pela qualidade dessa resposta. Um botão rápido de Rollback só é útil depois que a aplicação conquistou o direito de voltar.