Manutenção de servidor

Atualizações de sistema operacional

A página de cada servidor tem um card Operating system. O Railyard reporta atualizações pendentes em até meia hora após conectar o servidor, e depois diariamente: quantas no total, quantas são atualizações de segurança, e se é necessário reiniciar.

• Install all updates ou Install security updates and restart. Atualizar pode reiniciar o Docker, então os apps podem oscilar por alguns segundos; um reinício deixa os apps do servidor fora do ar por cerca de um minuto.
• As atualizações de segurança noturnas são aplicadas sem supervisão; um reinício nunca é feito automaticamente.
• O selo desaparece assim que o servidor reinicia.

Upgrades de versão major do Postgres

Um Postgres gerenciado pode migrar da versão 16 para a 17 ou 18 a partir do seu card. O Railyard verifica a compatibilidade primeiro, faz um backup, atualiza no lugar e confere a contagem de tabelas. A versão antiga fica guardada por sete dias para você poder voltar atrás. Novos servidores de banco de dados usam Postgres 17 por padrão.

Point-in-time recovery

Maintenance → Point-in-time recovery → Turn on arquiva cada segmento de WAL e um backup base do Postgres do servidor no backup store da sua equipe, então qualquer banco de dados nele pode ser reconstruído para qualquer segundo dos últimos 7 dias.

Para restaurar, abra o console do banco de dados (App → Resources → Database card → Console) e use a aba Restore to a time: escolha um segundo dentro da janela arquivada, depois Into a new copy (<db>_at_YYYYMMDDHHMM, inspecione e copie de volta o que precisar) ou Replace the live database (tudo depois daquele momento é perdido). Restaurar precisa do mesmo backup store usado para os backups normais.

Snapshots

Antes de um resize ou de um upgrade de sistema operacional, tire um snapshot do provedor pela página do servidor e restaure se algo der errado. Os snapshots ficam guardados pelo seu provedor de nuvem e são cobrados por ele.

Isolamento reforçado (beta)

Em Settings → General de um app, duas configurações opcionais e desativadas por padrão reforçam a fronteira entre containers de apps que compartilham um servidor:

• Hardened isolation: o container do app roda com seu próprio uid não-root, com capabilities removidas e sua própria rede Docker, então não consegue alcançar nem ser alcançado por outro app no servidor. Teste primeiro — isso pode quebrar uma imagem que precisa de root.
• Read-only filesystem: monta o filesystem raiz do container como somente leitura, com um /tmp gravável. Ative só depois de confirmar que o app não grava em nenhum outro lugar.

As duas têm efeito no próximo deploy. Todo servidor ainda compartilha um único kernel; isolamento com runtime sandboxed (gVisor) está no roadmap, mas ainda não foi construído.

Pontuação de segurança

Settings → Security dá uma nota de 0 a 100 para a equipe contra uma checklist, com um link de correção para cada item; veja Teams, SSO and access para a lista completa. Toda conexão com o seu servidor é autenticada via TLS com credenciais únicas para aquele servidor.