Vindo do Vercel
O Vercel é excelente pra frontends e funções serverless. Um worker, um bot, uma fila ou qualquer coisa que precise rodar continuamente precisa de outro tipo de host.
Por que as equipes procuram outra opção
O Vercel é construído em torno de funções: seu código roda a cada requisição, por um tempo limitado, e depois para. Esse é o formato certo pra um frontend e pra maioria das APIs. É o formato errado pra um worker de background, um bot que mantém uma conexão persistente, um consumidor de fila, um cron job que roda mais tempo do que o limite de uma função, ou um servidor WebSocket. Os próprios guias do Vercel pra rodar Docker ou um processo de longa duração na plataforma descrevem mover essa parte do trabalho pras queues ou workflows do Vercel, que é um modelo de programação diferente de um processo de servidor normal.
Bancos de dados no Vercel funcionam do mesmo jeito: não existe um banco de dados que o próprio Vercel roda. Postgres, Redis e o resto vêm do Vercel Marketplace, que conecta seu projeto a um provedor separado como Neon ou Upstash e injeta as credenciais. Backup, restauração point-in-time e o próprio uptime do banco são responsabilidade desse provedor, não do Vercel.
O Railyard é um servidor Linux normal na sua própria conta de nuvem. Qualquer coisa que roda como um processo, seguindo o modelo do Vercel ou não, roda lá: um worker, um bot, um consumidor de fila, um cron job de qualquer duração, Postgres ou Redis com os próprios backups agendados do Railyard.
O que vai com você
- O frontend continua onde já funciona bem, inclusive no Vercel. Isso é sobre as partes da aplicação que precisam de um servidor, não uma mudança completa.
- Sua API ou backend, buildado a partir do seu Dockerfile ou detectado a partir do repositório.
- Background workers, consumidores de fila e cron jobs, como processos de longa duração em vez de funções com limite de tempo.
- Um Postgres, MySQL ou Redis gerenciado, provisionado no servidor em vez de através de uma integração do Marketplace.
A migração
- Conecte um servidor: provisionado pelo Railyard na sua própria conta DigitalOcean, Hetzner, Vultr ou AWS, ou um que você já tem.
- Adicione o repositório da parte que precisa de um servidor de verdade: a API, o worker, o bot. O Railyard builda a partir do Dockerfile ou detecta o framework.
- Conecte um banco de dados se a aplicação precisar de um, com backups agendados incluídos.
- Aponte o frontend pra URL do novo backend, seja o frontend continuando no Vercel ou migrando também.
- Faça o deploy, confira os logs e confirme que o processo de longa duração realmente continua rodando.
O que é diferente
Um processo que roda continuamente em vez de esperar por uma requisição, um banco de dados que o próprio Railyard faz backup, e um servidor onde você pode entrar via SSH quando algo precisa de uma olhada mais de perto.