Colocamos a aplicação num servidor que controlamos, com publicação reversível, cópias de segurança verificadas e um local onde se vê quando algo caiu.

Onde você escolher, e verificamos que é mesmo aí. Os nossos sistemas estão na OVHcloud, Bucareste, e na Microsoft Azure, Poland Central, ambas no Espaço Económico Europeu, e a localização foi confirmada consultando o serviço de metadados da máquina virtual e o registo do endereço — não lendo a documentação do fornecedor. A verificação importa: para uma transferência no interior do Espaço Económico Europeu, o capítulo sobre transferências da Lei 195/2024 não se aplica e não são necessárias autorizações especiais. Fora dele, surge um dossier de garantias.

Nem sempre. Uma plataforma gerida é a escolha correta quando a equipa é pequena, o tráfego é irregular e nada da stack tem requisitos de residência. O servidor próprio torna-se o melhor argumento em três situações: quando os dados têm de permanecer numa jurisdição específica, quando o custo se torna imprevisível à escala, e quando vocês querem poder levar tudo e ir embora. Também fizemos a migração inversa para um sistema próprio: de uma base de dados alojada nos Estados Unidos para uma stack autoalojada na União Europeia, com oito contentores — base de dados, autenticação, interface REST, tempo real, armazenamento, metadados, painel e gate de acesso.

Reverte-se, e de preferência automaticamente. A versão anterior permanece no disco ao lado da nova, e após a publicação uma verificação solicita a página real e confirma que o ficheiro servido é o acabado de construir; se não for, o script reverte automaticamente. Onde usamos a comutação atómica de ligação simbólica, a reversão é uma única operação. Não é uma descrição de folheto — o mecanismo já apanhou uma publicação com um pacote antigo deixado no diretório de trabalho do runner e anulou-a.

Diariamente onde a construímos — e sublinhamos isto, porque uma cópia automática não aparece sozinha quando você muda uma aplicação para um servidor. A cópia corre à hora certa, é recuperada no boot seguinte se a máquina estava desligada, e se a exportação sair vazia a execução é tratada como falha. A cópia também sai da máquina, para uma região da União Europeia, com replicação, versionamento, eliminação reversível e expiração automática. O teste de restauro faz parte da entrega: uma cópia nunca restaurada é uma suposição, não uma cópia.

Depende do que construímos, e vale a pena dizê-lo sem floreios. As verificações de saúde ao nível do contentor e os pontos de estado das aplicações existem; o alerta para um canal de mensagens, com limitação de frequência, existe onde o construímos. Um ponto de verificação de estado que ninguém consulta não é monitorização — é uma página. Se você quer monitorização verdadeira, é uma etapa separada, com um observador externo que consulta periodicamente e com um destinatário do alerta que pode ser acordado.

Não, e é uma decisão tomada de forma consciente, não uma falha. A cadeia de publicação constrói e copia o código; só isso. As alterações de esquema são ficheiros versionados no repositório, aplicados manualmente, com uma cópia de segurança recente em back-up, e os componentes que mantêm o esquema em memória reiniciam depois. Uma migração aplicada automaticamente em produção por um processo que não sabe o que está na tabela é a forma habitual de perder dados de forma irreversível.

Através de três regras. As ações externas são fixadas na impressão digital completa do commit, e não na etiqueta — em março de 2026, uma ação usada em larga escala foi redirecionada das suas etiquetas para código malicioso e atingiu mais de 23.000 repositórios em 24 horas. A cópia de trabalho não mantém credenciais. A publicação não é feita com uma chave de acesso armazenada na plataforma de código, mas sim por um executante próprio que corre na máquina-alvo, com direitos concedidos pontualmente. Reconhecemos que nem todos os nossos projetos mais antigos ainda cumprem as três; a migração deles é um trabalho em si.

Sim, e a primeira passagem é sempre um inventário, não uma alteração. O que corre efetivamente, sob que supervisor, com que versões, que portas estão expostas, que cópias de segurança existem, se alguma foi alguma vez restaurada, que segredos chegaram aos repositórios e em que medida a configuração no repositório ainda se assemelha ao ficheiro no servidor. A última verificação quase sempre produz algo: temos documentado, num projeto próprio, um ficheiro de configuração editado diretamente em produção, que deixou uma cópia de segurança com marca temporal ao lado.

Vocês saem com tudo. A infraestrutura fica desde o início nas vossas contas junto do fornecedor, e a entrega inclui o repositório com todas as configurações de servidor, o procedimento de publicação e de reversão, o procedimento de restauro testado e a lista de tarefas programadas com o que cada uma faz. O bloqueio contra a eliminação acidental do grupo de recursos de produção é ativado desde a instalação. Se um fornecedor condiciona a vossa saída à reescrita da infraestrutura, esse era o problema, não a tecnologia.