Ligar a IA ao servidor: como um agente de IA faz deploy e administra o seu servidor

A maioria das pessoas ainda usa a IA como um colega muito culto ao telefone: descreve-se um problema do servidor, recebe-se um comando sugerido, copia-se esse comando para a consola, copia-se de volta a mensagem de erro e repete-se o ciclo até tudo funcionar. Assim que ligar a IA ao seu servidor, este desvio desaparece. Um agente de IA como o Claude Code, o OpenAI Codex CLI ou o Gemini CLI inicia sessão sozinho no servidor por SSH, lê os registos, verifica a configuração, aplica alterações, testa o resultado e deixa por escrito o que fez. Da sua parte, define a tarefa e aprova os passos que não se podem desfazer.

Este artigo é um relato prático. Na KernelHost, há meses que um agente de IA trabalha diariamente connosco na nossa própria infraestrutura: portal do cliente, monitorização, meios de pagamento, documentação. Mostramos como está montada a ligação entre o agente e o servidor, que processo o agente segue quando faz deploy em sistemas de produção, que regras impedem que algo corra mal ou que alguma informação vaze para o exterior, e o que um servidor tem de oferecer para que tudo isto funcione. As bases sobre ferramentas e arquiteturas estão no artigo Servidor gerido por IA: ligar agentes em segurança, e a instalação no servidor está no guia para o Claude Code e o Codex CLI.

Ligar a IA ao servidor: o que significa

Ligar uma IA ao servidor significa dar a um agente de IA um acesso próprio e controlado à linha de comandos do servidor, normalmente através de uma chave SSH. A partir desse momento, o agente já não se limita a sugerir comandos: executa-os ele próprio, lê a saída e deduz daí o passo seguinte. O modelo de linguagem continua a correr no fornecedor (Anthropic, OpenAI ou Google); no seu computador ou servidor corre apenas uma ferramenta leve de linha de comandos, que envia os comandos.

A palavra decisiva é «controlado». Um agente com acesso ao servidor não é um piloto automático, mas sim um colaborador muito rápido que pergunta antes de cada ação intrusiva. É a si que cabe decidir o que ele pode fazer sem perguntar: desde o simples acesso de leitura até à aplicação autónoma de atualizações segundo um processo fixo.

Chatbot ou agente: a diferença numa tabela

Assim, meia hora de idas e voltas transforma-se muitas vezes em poucos minutos, e a fonte de erro «mal transcrito» desaparece por completo.

O que um agente de IA faz no servidor: exemplos da nossa operação

Os exemplos seguintes vêm do nosso dia a dia. Omitimos nomes, endereços e credenciais; os processos são reais.

Deploys com cópia de segurança e reversão

Quando alteramos algo no portal do cliente ou num script do servidor, é o agente que faz o deploy. Primeiro compara o ficheiro no servidor com a última versão conhecida, para não sobrescrever uma alteração de outra pessoa. Depois cria uma cópia de segurança datada fora do diretório web, escreve um script de reversão, verifica a sintaxe do novo ficheiro, aplica-o com os mesmos proprietários e permissões de antes e, a seguir, testa a função afetada. Só quando está tudo verde é que dá o trabalho por concluído. O processo exato está descrito mais abaixo, na secção sobre o deploy.

Diagnóstico: do sintoma à causa em minutos

«A partir do escritório, o site não abre; fora dele, abre sem problemas.» Antigamente, isto teria significado uma procura demorada. O agente verifica as regras da firewall, procura o endereço do escritório nos registos do software de proteção, encontra a regra que foi acionada e explica que pedido a desencadeou. A decisão sobre o que fazer continua a ser nossa; o trabalho de detetive, não. Com erros típicos de servidor web, como 502 Bad Gateway ou discos cheios, trabalha da mesma forma: lê os registos com o journalctl e os registos da aplicação, formula uma hipótese e fundamenta-a antes de alterar o que quer que seja.

Monitorização feita pelo próprio agente

Grande parte da nossa monitorização nasceu em colaboração com o agente: pequenos scripts de verificação que, de poucos em poucos minutos, testam um serviço de ponta a ponta através de um cron job e, em caso de falha, enviam uma mensagem para o telemóvel, por exemplo através de um bot do Telegram. O agente escreve o script, testa-o com uma falha provocada de propósito, configura o cron job e documenta como se silencia o alarme. Como montar algo assim, em termos gerais, está descrito no artigo Configurar a monitorização do servidor.

Levantamentos e limpezas

Que servidores continuam a correr, apesar de o contrato correspondente já ter sido rescindido? Que serviços adicionais estão a ser pagos, mas já não são usados? O agente responde a perguntas destas consultando bases de dados e interfaces apenas em modo de leitura e apresentando o resultado numa tabela. Só pode fazer limpezas depois de aprovação e, antes disso, verifica se a máquina está mesmo sem uso, por exemplo pelo tráfego dos últimos dias.

Documentação que cresce sozinha

Cada alteração termina com uma entrada no registo de alterações e, se necessário, com um acrescento ao manual de operações. Isto custa segundos ao agente e poupa-nos horas mais tarde, porque a pergunta «Afinal, porque é que isto está assim?» tem uma resposta por escrito.

As vantagens de a IA trabalhar diretamente no servidor

• Rapidez: O agente lê em segundos o que uma pessoa demora minutos a ler e testa uma hipótese de imediato, em vez de primeiro a descrever.
• Rigor: Lê a configuração completa, com todos os ficheiros que ela inclui, e as linhas de registo em torno do erro, não apenas o excerto que alguém considerou relevante.
• Processo constante: Cópia de segurança, verificação da sintaxe e controlo acontecem sempre, também à sexta-feira à noite e também na vigésima pequena alteração.
• Documentação sem esforço adicional: Cada alteração fica descrita, com o motivo, o local da cópia de segurança e a forma de a reverter.
• Automatização sem aprender a programar scripts: Scripts de verificação, cron jobs e relatórios nascem de uma descrição em linguagem corrente e são testados antes de serem postos em uso.
• Aprendizagem pelo caminho: O agente explica o que faz e porquê. Quem acompanha as explicações percebe o seu servidor muito melhor ao fim de algumas semanas.

Três arquiteturas e a que usamos

Há três formas comprovadas de ligar um agente a um servidor. Diferem no sítio onde a ferramenta corre e onde ficam as credenciais.

A nossa escolha: agente no posto de trabalho, servidores por SSH

Trabalhamos com a primeira variante. O agente corre no computador de trabalho, cada servidor tem uma entrada na configuração SSH e o agente liga-se com uma chave própria. A razão principal: gerimos muitos sistemas e, desta forma, um único agente consegue seguir uma causa através de vários servidores numa só sessão, por exemplo do servidor web à base de dados e daí até à firewall. Além disso, o início de sessão no fornecedor de IA e as chaves ficam num sítio que já protegemos de qualquer forma. Quem tem apenas um servidor e quer relatórios automáticos durante a noite fica bem servido com a segunda variante. Mais sobre as vantagens e desvantagens no artigo sobre o servidor gerido por IA.

Guia: ligar um agente de IA ao servidor por SSH

Os sete passos seguintes funcionam da mesma forma com o Claude Code, o Codex CLI e o Gemini CLI. Os exemplos usam o endereço de documentação 203.0.113.10 e o nome de utilizador deploy; substitua ambos pelos seus valores. O pré-requisito é um servidor com início de sessão por chave SSH, como descrito no artigo Proteger o SSH e configurar a autenticação por chave.

Passo 1: gerar uma chave SSH própria só para o agente

O agente nunca recebe a sua chave pessoal, mas sim uma própria. Assim, pode retirar-lhe o acesso a qualquer momento sem perder o seu, e nos registos percebe-se que início de sessão veio do agente.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

As chaves Ed25519 são curtas, rápidas e consideradas seguras. O comentário ki-agent aparece mais tarde no ficheiro authorized_keys do servidor e torna a chave reconhecível à primeira vista.

Passo 2: colocar a chave pública no servidor

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Quem quiser restringir ainda mais o acesso acrescenta opções antes da chave no ficheiro ~/.ssh/authorized_keys do servidor. from= só permite o início de sessão a partir de um endereço específico, e no-agent-forwarding e no-port-forwarding impedem que a ligação sirva de trampolim:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Se o servidor responder depois com Permission denied (publickey), consulte o artigo Resolver o erro SSH Permission denied (publickey).

Passo 3: criar um alias de host na configuração SSH

Com um alias, o agente só precisa de conhecer um nome curto e usa sempre a chave certa:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

A partir daí, basta ssh web-prod "systemctl status nginx". IdentitiesOnly yes impede que o SSH experimente outras chaves do seu porta-chaves. Para cada servidor adicional, crie um bloco próprio, de preferência com nomes diferentes para os sistemas de teste e de produção, como web-test e web-prod, para que uma confusão se note logo pelo nome.

Passo 4: instalar o agente e iniciar sessão

O Claude Code, o Codex CLI e o Gemini CLI correm em Linux, macOS e Windows, e o início de sessão faz-se com uma conta do fornecedor ou com uma chave API. A instalação e o início de sessão sem navegador estão descritos no guia passo a passo. Na variante do posto de trabalho, instale a ferramenta no seu computador, não no servidor.

Passo 5: definir as regras que o agente segue

As três ferramentas leem, ao arrancar, um ficheiro de regras na pasta de trabalho: o Claude Code lê o CLAUDE.md, o Codex CLI o AGENTS.md e o Gemini CLI o GEMINI.md. É aí que fica escrito como se trabalha nos seus servidores. Um ponto de partida comprovado:

# Regras para trabalhar em servidores

- Antes de cada alteração, criar uma cópia de segurança datada, fora do diretório web.
- Antes de aplicar, verificar a sintaxe (nginx -t, php -l, apachectl configtest).
- Depois de aplicar, verificar o serviço, o registo e a função e comunicar o resultado.
- Nunca mostrar palavras-passe, chaves API ou tokens, nunca os copiar para ficheiros.
- Apagar, alterar bases de dados e tudo o que for irreversível só com aprovação expressa.
- Não alterar diretamente ficheiros geridos pelo painel de controlo.
- Remover os ficheiros de teste depois do teste.

As regras vão crescendo. Sempre que o agente fizer algo de maneira diferente da que quer, a correção entra neste ficheiro como regra. Ao fim de algumas semanas, ele trabalha como você próprio trabalharia.

Passo 6: configurar as aprovações e a lista branca

Por predefinição, as ferramentas perguntam antes de cada comando que altere alguma coisa. No início, é assim que deve ser. Os comandos de leitura que está sempre a confirmar podem ser autorizados. No Claude Code, isso faz-se no ficheiro .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Tudo o que não estiver nesta lista continua a precisar da sua aprovação. As opções que desligam todas as perguntas de confirmação pertencem, no máximo, a uma máquina de teste descartável.

Passo 7: a primeira tarefa, só de leitura

Comece com tarefas que não podem alterar nada e observe como o agente procede:

Verifica em web-prod os erros do nginx das últimas 24 horas e indica as três
causas mais frequentes, cada uma com uma prova tirada do registo. Não alteres nada.

Só quando as análises estiverem certas se seguem pequenas alterações, como uma nova rotação de registos ou um serviço systemd, e só depois disso os deploys no sistema de produção.

Como o agente faz deploy: o nosso processo para cada alteração no sistema de produção

Um agente de IA só deve fazer deploy num sistema de produção segundo um processo fixo, que inclua uma cópia de segurança, uma reversão preparada e uma verificação antes e depois da aplicação. No nosso caso, o processo é este:

1. Verificar o estado atual. O ficheiro no servidor é comparado com a última versão conhecida. Se entretanto outra pessoa o tiver alterado, o agente interrompe e pergunta, em vez de sobrescrever a alteração alheia.
2. Criar a cópia de segurança. Os ficheiros afetados vão, com data, para uma pasta de cópias de segurança fora do diretório web. Uma cópia dentro do diretório web poderia, em certas circunstâncias, ficar acessível publicamente.
3. Preparar a reversão. Um pequeno script que repõe a versão anterior com um único comando é escrito antes da alteração, e não só quando surge a emergência.
4. Verificar a sintaxe. O novo ficheiro é verificado antes de ser aplicado: no PHP com php -l, no nginx com nginx -t. Assim, um erro de sintaxe nem sequer chega ao sistema de produção.
5. Aplicar com as permissões certas. Proprietário, grupo e permissões do ficheiro são herdados da versão anterior. A seguir aos erros de sintaxe, as permissões erradas são a causa mais frequente de falhas depois de uma atualização.
6. Testar sem efeitos secundários. Os testes são feitos em modo de leitura, com dados de teste fictícios ou num ambiente isolado, nunca com encomendas reais nem com dados reais de clientes.
7. Verificar em produção. Depois da aplicação, controlam-se o código de estado HTTP, o registo de erros e a função alterada.
8. Documentar. O registo de alterações e o manual de operações são atualizados, incluindo o local da cópia de segurança e o comando de reversão.

Como sequência de comandos, com caminhos de exemplo em vez dos reais, fica mais ou menos assim:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Porque é que a reversão se prepara antes da alteração

Quando algo corre mal, ninguém está no seu melhor para pensar numa reversão limpa. Se o script já estiver pronto, desfazer a alteração é uma questão de segundos, e o agente pode até executá-la sozinho se a verificação após a aplicação falhar. Esta é a maior diferença entre um agente que altera algo «num instante» e um agente a quem se confia um sistema de produção.

Testes que não podem estragar nada

Muitas funções não se podem testar sem que algo aconteça: uma encomenda, um pagamento, um e-mail. Aqui ajudam três técnicas. Primeiro, as simulações (dry runs) que a própria ferramenta oferece. Segundo, identificadores fictícios que garantidamente não existem em lado nenhum. Terceiro, um ambiente isolado: um processo que corre num namespace de rede próprio, sem rede (unshare -n), não consegue chegar a nenhuma interface externa nem comprar nada por engano, mas continua a ver a base de dados local através do socket Unix. Depois do teste, todos os ficheiros de teste são removidos.

Ações que custam dinheiro precisam de um bloqueio

Quando um processo encomenda, fatura ou apaga alguma coisa, não pode correr duas vezes em simultâneo, nem mesmo quando alguém clica duas vezes ou o agente repete um comando. A solução mais simples em Linux é o flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "já está em execução"

Em aplicações com base de dados, um bloqueio com nome (GET_LOCK no MySQL e no MariaDB) cumpre o mesmo objetivo; nas API, uma Idempotency-Key. Voltamos a isso adiante, na secção sobre a KernelHost API.

Segurança: acesso para o agente sem que nada vaze

A preocupação que mais ouvimos é: «E os meus dados?» A resposta honesta: tudo o que o agente lê é enviado para processamento ao modelo de linguagem do fornecedor. Por isso, é com as regras seguintes que decide o que ele chega sequer a ver.

Os segredos não pertencem ao chat

Palavras-passe, chaves API e tokens nunca são escritos numa tarefa e o agente nunca os mostra. Os scripts leem-nos de ficheiros com permissões 600, que o agente não precisa de mostrar para usar o script. Se, mesmo assim, uma chave acabar no chat, é imediatamente revogada no fornecedor e gerada de novo. Os fragmentos também não pertencem ao chat: os primeiros caracteres de uma chave não ajudam ninguém a diagnosticar um problema, mas encurtam o trabalho de um atacante.

Chaves próprias, permissões próprias, revogáveis a qualquer momento

Cada agente recebe uma chave SSH própria, e cada chave é reconhecível pelo seu comentário no authorized_keys. Quem quiser retirar o acesso apaga essa única linha. Onde for suficiente, o agente trabalha com um utilizador próprio e uma regra sudo que só permite os comandos necessários. As API recebem chaves próprias com as permissões mínimas possíveis, só de leitura quando se trata apenas de análises.

Aprovações: o que nunca acontece sem uma pessoa

Sem autorização expressa, o nosso agente não pode apagar, escrever em bases de dados, afrouxar regras de firewall ou de proteção, parar máquinas nem encomendar nada. As ferramentas ajudam nisso: o Claude Code suspende as ações intrusivas e pode, além disso, ser configurado para que um filtro de segurança reconheça comandos arriscados e os bloqueie até serem aprovados. Do nosso dia a dia: este filtro já travou mais do que uma vez uma ação que estava tecnicamente correta, mas que era simplesmente irreversível. Só foi executada depois de uma pessoa a ter aprovado expressamente. É exatamente assim que deve ser.

Rastreabilidade: registos, lista de alterações, cópias de segurança

Cada sessão deixa rastos que uma pessoa consegue ler: as cópias de segurança datadas, o script de reversão, a entrada no registo de alterações e os inícios de sessão no registo do sistema. Quem, além disso, gere o /etc no Git com o etckeeper vê cada alteração de configuração como um diff. O que não é rastreável também não se pode reverter. A base continua a ser uma estratégia de backup que funcione, porque um agente não substitui uma cópia de segurança.

Que servidor é adequado para um agente de IA?

Um servidor para gestão assistida por IA precisa de acesso root completo, início de sessão por chave SSH, ligações de saída sem restrições, proteção DDoS permanente e, idealmente, uma API através da qual se possam encomendar e controlar servidores de forma automatizada. Não precisa de GPU, porque o modelo de linguagem corre no fornecedor.

Porquê a KernelHost para servidores geridos por IA

Em princípio, um agente de IA pode trabalhar com qualquer servidor onde tenha uma shell. Na prática, porém, é o ambiente que decide quanto trabalho lhe pode realmente entregar. Num servidor root KVM ou num servidor dedicado da KernelHost não há contas limitadas, nem obstáculos às ligações HTTPS aos fornecedores de IA, nem fidelização que torne cara a experimentação. A proteção DDoS permanente está ativa em todos os servidores sem custo adicional e, para tarefas de cálculo intensivo, existem os servidores root Professional com núcleos dedicados. A faturação é PrePaid: sem contrato, sem período mínimo, sem taxa de instalação. Quem quiser experimentar primeiro começa com o servidor de teste gratuito.

A KernelHost API: o seu agente encomenda e controla servidores sozinho

A maior alavanca está um nível acima do servidor individual. Através da KernelHost API, um agente pode consultar produtos e preços, encomendar servidores, ler o estado dos seus serviços, iniciar, parar e reiniciar servidores, bem como pedir e anular cancelamentos. Assim, «Prepara-me um servidor de teste» passa a ser uma única tarefa: o agente encomenda a máquina, espera pela disponibilização, liga-se por SSH, instala a aplicação e devolve o endereço.

Para ser usada por agentes, a API foi construída de forma propositadamente cautelosa. As chaves API só recebem as permissões de que precisam; uma chave para análises não consegue encomendar absolutamente nada. Uma Idempotency-Key garante que uma encomenda que o agente repita depois de um erro de tempo esgotado não seja executada duas vezes. Os pedidos estão limitados por chave, por conta e por endereço, de modo que nem um agente preso num ciclo infinito desencadeia uma avalanche. E cada consulta de credenciais gera uma notificação por e-mail, para que saiba quando um agente leu credenciais.

Quanto custa um servidor gerido por IA?

Há duas rubricas de custo. Primeiro, o próprio servidor: para um agente que trabalha por SSH, não precisa de nenhum equipamento especial; basta qualquer servidor root onde a sua aplicação já esteja a correr. Se o agente correr diretamente no servidor, a ferramenta em si precisa apenas de algumas centenas de megabytes de memória, e um servidor root com 2 vCPU e 4 GB de RAM chega, se pouco mais correr nele. Segundo, o modelo de linguagem: ou uma subscrição do fornecedor que inclui a utilização da ferramenta de linha de comandos, ou uma chave API com faturação por consumo. Com uso diário intensivo, a subscrição costuma ser mais barata; para tarefas automatizadas sem ninguém à frente, a chave API é o caminho limpo, porque pode ser limitada com um orçamento mensal. Os preços atuais dos servidores estão na página Alugar servidor root.

Erros frequentes e como evitá-los

• O agente trabalha com a chave pessoal do administrador. Nesse caso, o seu acesso não pode ser retirado em separado nem distinguido nos registos. Solução: uma chave própria com um comentário próprio.
• Todas as perguntas de confirmação estão desligadas. Isso poupa cliques no primeiro dia e, mais cedo ou mais tarde, custa um servidor. Solução: lista branca para comandos de leitura, aprovação para tudo o que seja intrusivo.
• Nenhuma cópia de segurança antes da alteração. Solução: cópia de segurança e script de reversão como regra fixa no CLAUDE.md ou no AGENTS.md.
• Cópias de segurança no diretório web. Um ficheiro como config.php.bak no webroot pode ficar acessível publicamente, incluindo a palavra-passe da base de dados. Solução: pasta de cópias de segurança fora do diretório web, com permissões 700.
• Segredos no prompt. Solução: credenciais apenas em ficheiros com permissões 600 que os scripts leem e, em caso de descuido, gerá-las de novo de imediato.
• Execução duplicada. Um duplo clique ou um pedido repetido encomenda duas vezes. Solução: bloqueio com flock ou Idempotency-Key.
• Ficheiros geridos pelo painel de controlo alterados diretamente. O painel sobrescreve-os na próxima atualização ou falha por causa deles. Solução: excluir esses ficheiros nas regras e fazer as alterações através do painel ou da respetiva interface.
• Saídas aceites sem verificação. Um agente que não entende uma saída adivinha. Solução: exigir provas («mostra-me a linha do registo») e mandar verificar os resultados em produção.

Em resumo

• Ligar uma IA ao servidor significa dar a um agente como o Claude Code, o Codex CLI ou o Gemini CLI uma chave SSH própria e regras claras.
• O agente lê registos, aplica alterações, verifica o resultado e documenta-o; os passos intrusivos só avançam com aprovação.
• Cada deploy segue um processo fixo: verificar o estado atual, fazer a cópia de segurança, preparar a reversão, verificar a sintaxe, aplicar, testar, verificar em produção, documentar.
• Os segredos nunca pertencem ao chat, e as ações que custam dinheiro precisam de um bloqueio contra a execução duplicada.
• O servidor precisa de acesso root, chaves SSH, ligações de saída livres e proteção DDoS, mas não de uma GPU.
• Os servidores da KernelHost cumprem todos os requisitos de origem, em PrePaid e sem fidelização, e através da KernelHost API o agente pode até encomendar e controlar servidores sozinho.