Vindo do Hatchbox.io
Hatchbox e Railyard fazem a mesma aposta, seus servidores, push para fazer deploy. Veja como é migrar, e onde o Railyard faz mais pelo dia a dia.
Por que as equipes olham para além do Hatchbox
O Hatchbox acertou o essencial: deploy em servidores que você possui, sem markup em compute. Se isso está funcionando para você, não há motivo urgente para migrar.
Onde as pessoas começam a procurar outra coisa: o Hatchbox é uma camada fina sobre uma configuração bem manual, próxima do config do Nginx e dos detalhes internos do servidor, e a superfície gerenciada para logo no começo. Não existe um release com verificação e troca, com cutover baseado em health check, nem ambiente de preview por pull request, nem papéis / 2FA / trilha de auditoria, e os backups são por sua conta. Também é um produto mantido por uma única pessoa, com um roadmap silencioso.
O Railyard é a mesma aposta “seus servidores”, mas com mais do dia a dia já resolvido para você.
O que vai com você
- Seu repositório e seu Dockerfile, ou o caminho Nixpacks / buildpacks do Railyard, se hoje você faz deploy sem um Dockerfile.
- Os tipos de processo do seu Procfile.
- Suas variáveis de ambiente.
- Seu banco de dados. O Postgres / MySQL / Redis gerenciados do Hatchbox mapeiam para addons do Railyard com connection strings já injetadas.
- Seus servidores, se você quiser mantê-los: conecte uma máquina existente via SSH em vez de provisionar uma nova.
A migração
- Conecte um servidor. Aponte o Railyard para um dos seus servidores atuais do Hatchbox, ou um novo na sua conta de nuvem.
- Adicione seu repositório e confirme o build method. Um Dockerfile faz deploy como está.
- Traga seu env e conecte os bancos de dados que você precisa.
- Faça o deploy para uma URL temporária e teste de ponta a ponta, incluindo uma release task se você roda migrations.
- Mova seus dados com um dump e restore padrão para o addon gerenciado.
- Reaponte o DNS. O app antigo continua servindo até o registro mudar; nada fica fora do ar. Depois, desative o app no Hatchbox.
O que é diferente
Você ganha um cutover com health check e zero downtime em cada deploy, rollback de um clique com o commit e o autor registrados, um deploy de preview para cada PR, papéis reais e um log de auditoria, e backups testados para restore, além da propriedade que você já tinha.