Saudações.
Nesse tutorial vou ensinar como criar um servidor OpenCode 2, dedicado a tarefas 24/7, acesso remoto completo via web, terminal e controlável por outros agentes.
1 – A ideia
Diariamente rodamos agentes de IA em nossos dispositivos (PC/Notebook, smartphone) e pela web (Claude.ai, openai.com, etc).
Via web temos a liberdade de dar tarefas e tomar um café enquanto ela se desenvolve, já no PC/Notebook infelizmente ele precisa estar na tomada e com Internet.
Rodando o OpenCode em um servidor (máquina virtual) temos uma solução completa onde você dá as ordens e ele segue trabalhando sem depender de você.
Controle remoto:
- Controle remoto via WEB – Abra o navegador, entregue tarefas e feche o notebook;
- Controle remoto via ACP – o Agent Client Protocol, aqui o agente roda no servidor mas você controla ele com um software no seu ambiente (Antigravity, VSCode, etc);
- OpenCode Pair – Seu opencode local se conecta ao servidor OpenCode, ao abrir a interface Web local, terminal (TUI ou CLI) o trabalho pesado roda no servidor, com suporte a ferramentas que coletam e fazem trabalhos na sua máquina;
- Terminal do servidor – Ao acessar o servidor via SSH você cria ou continua sessões pelo terminal (TUI ou CLI).
2 – Segurança
Você tem opções de segurança ao criar um “ser vivo digital” que:
- Nunca dorme, poderá perseguir uma tarefa por horas e até dias;
- Pode ser aliciado por terceiros:
- Prompt injection;
- Biblioteca ou programa comprometido;
- Pode entender errado a tarefa e sair descontrolado por ai.
Criei uma abordagem onde rodo 4 servidores OpenCode no mesmo sistema:
- Servidor Watson: para tarefas remotas assistidas, arquivos locais;
- Servidor Wayne: para tarefas remotas autônomas, arquivos locais;
- Servidor Kirk: para todas as tarefas assistidas que precisam de poderes elevados e tem controle sobre arquivos locais (próprios e dos demais usuários);
- Servidor Borg: para todas as tarefas com poderes totais sem supervisão, é um “root digital”.
Esses ambientes são universos onde os agentes existem dentro de um “universo de bolso”. Um agente chamado “Jack” rodando no servidor “Watson” se chama “Jack Watson”, afinal ele é dessa família e herda poderes e limites.
2.1 – Nível 1 – Servidor Watson
Esse rodará com poderes de usuário, acesso restrito ao seu diretório (/home/watson), e fará precisará de confirmação para realizar todas as tarefas.
Ele é muito útil para tarefas que envolvem sistemas remotos (MCP, API, automação) cujas tarefas são sensíveis e supervisionada por humanos.
2.2 – Nível 2 – Servidor Wayne
Rodará como usuário, acesso restrito ao seu diretório (/home/wayne) mas com liberdade e autonomia pra fazer o que precisa ser feito sem supervisão humana.
Esse é meu favorito, ótimo para automatizar tarefas do dia-a-dia das quais eu não quero quero saber dos detalhes, apenas o resultado.
Melhor ambiente para planejamento de projetos de software e automações.
2.3 – Nível 3 – Servidor Kirk
Aqui temos um capitão, rodará no servidor em nome do usuário root:
- Acesso a leitura completa em todos os arquivos;
- Acesso a escrita restrito aos diretórios de trabalho (/storage, /home);
- Requer permissão do humano para executar comandos;
Esse é um ótimo assistente, com grandes capacidades mas sem liberdade para destruir o servidor ou sistema. Ele precisa de confirmação para tudo.
Melhor ambiente para planejamento.
2.4 – Nível 4 – Servidor Borg
Bom… esse é o que eu uso! Em vários servidores eu só tenho ele.
Esse roda como root e não tem nenhum limite, ele pode formatar o servidor, instalar qualquer programa ou ferramenta e se for aliciado para o mal, poderá destruir o planeta.
- Roda como root;
- Nenhuma restrição;
- Não requer nenhuma interação humana nem permissão adicional.
Se bem utilizado, ele é ótimo para:
- Delegar tarefas aos demais ambientes;
- Investigar problemas com autonomia;
- Produzir sistemas experimentais do zero à demonstração;
- Usar o servidor para instalar sistemas completos e deixá-los pronto para uso.
Eu gosto muito desse modo pois ele se comporta como uma “Mr. Meeseeks Box“: cada pedido cria um “deus temporário” dedicado a atingir um objetivo e desaparecer.
3 – Preparativos
Prepare o ambiente onde os diferentes servidores OpenCode serão instalados.
3.1 – Servidor Linux e máquina virtual
Instale o Debian com a configuração mínima (recomendo 4x mais):
- Debian 13 (Debian 13.7 no dia que edito esse tutorial);
- 2 vCPU e 8 GB de RAM;
- 80 GB de disco;
- IP público fixo (IPv4, e IPv6 se o seu provedor oferecer);
3.2 – DNS e HTTPs
Crie os nomes de DNS (FQDN) em seu domínio para acesso direto e seguro aos ambientes:
- watson.seudominio.com (CNAME watsonbox);
- wayne.seudominio.com (CNAME waynebox);
- kirk.seudominio.com (CNAME kirkbox);
- borg.seudominio.com (CNAME borgbox);
Obs: eu gosto dos nomes “kirklandbox” e “meeseeksbox” !
3.3 – Boas práticas no Linux
Boas práticas que recomendo para o Linux das suas caixas mágicas:
- Storage em disco secundário: Eu sempre monto o diretório /storage em disco secundário, NVME, usando ZFS (ótima performance e optimização por compressão e dedup) para que software e dados não se misturem e atrasem a reconstrução do sistema;
- Backup automático: Mapeie os diretórios onde dados, projetos, volumes e informações persistentes são gerados e faça o backup deles periodicamente, enviando o arquivo para nuvem (Google Drive, S3, rsync/ftp);
- Snapshot automático: Ao utilizar VM, vá na gestão das VMs (Proxmox, VMWare, painel do provedor) e ative o snapshot automático, 1 por dia basta, no mínimo 1 por semana. Com isso qualquer desastre pode ser recuperado rapidamente;
- Servidor de logs remoto: Tenha um servidor syslog/graylog externo para receber logs de tudo que acontece no servidor;
- Atualização automática: Crie uma rotina crontab para atualizar o servidor (apt update|upgrade|dist-upgrade) e reinicie sempre que um novo kernel for instalado (tem isso no tutorial de Debian Ajustes finos).
Tutoriais recomendados:
- Debian com Ajustes finos: https://blog.patrickbrandao.com/debian-ajustes-finos/
- Docker: https://blog.patrickbrandao.com/docker-instalando-e-usando/
3.4 – Caixa de areia
Para separação de ambientes, oriente seus agentes a usar:
- VENV: Instalar programas em ambiente virtual em pasta específica em vez de instalar programas e bibliotecas no sistema;
- Docker: Utilizar containers para sandbox ao criar e rodar programas, testar softwares e utilizar sistemas de terceiros para que esses sistemas não possam afetar o HOST;
- VM efêmera: Criar máquinas virtuais usando templates prontos para subir ambientes de sistemas operacionais completos (Windows, MacOS, Linux, FreeBSD, etc);
- Navegadores efêmeros: Ambientes para que os agentes usem navegadores reais (Browserbase, Steel, FireCrawl, Playwright).
Com essas práticas você não enche o servidor de tralhas que podem comprometê-lo ou tornar atualizações completas bem demoradas.
3.5 – Skills reaproveitaveis
Agentes instruídos a gerar skills (procedimento operacional padrão das IAs), podem aperfeiçoar processos por interações com atendentes humanos.
Se cada agente ou ambiente acumular suas skills outros ambientes não enxergam isso.
Fiz um sistema chamado Purple-Skills – https://purple-skills.langwizard.net/
que provê servidores MCPs virtuais onde seus agentes consultam skills prontas e podem armazenar novas skills para outras equipes de agentes utilizarem.
Com a separação de MCPs virtuais você pode separar departamentos que não podem ter acesso a dados uns dos outros (departamento de suporte não enxerga skills do RH).
3.6 – Servidores MCP
Se seus agentes precisam controlar algo, garanta que eles usem um servidor MCP adequado, de preferência que esse MCP faça log e auditoria por conta própria.
4 – Instalação
Vamos colocar a mão na massa. Mapa:
| Servidor | User | Diretório $HOME | Porta | Endereço |
|---|---|---|---|---|
Watson | watson | /home/watson | 4101 | watson.seudominio.com |
Wayne | wayne | /home/wayne | 4102 | wayne.seudominio.co |
Kirk | root | /storage | 4103 | kirk.seudominio.com |
Borg | root | /root | 4104 | borg.seudominio.com |
4.1 – Usuários
Watson e Wayne rodam como usuários comuns, cada um preso ao seu diretório.
Kirk e Borg rodam como root, então não precisam de usuário.
# Usuario 'watson' - trabalhos com interacao e aprovacao
adduser --disabled-password --gecos "OpenCode_Watson" watson;
# Usuario 'wayne' - trabalhos automatizados
adduser --disabled-password --gecos "OpenCode_Wayne" wayne;
Detalhes:
- O “
--disabled-password” impede login por senha, ninguém entra como watson ou wayne por SSH, só o root consegue “su - watson“; - Eles não têm “
sudo“, qualquer prompt injection que os convença a “instalar um pacote no sistema” falhará.
3.4 – Os diretórios de trabalho
Cada nível tem o seu território:
/home/watson– território do Watson’s;/home/wayne– território do Wayne’s;/storage– área compartilhada onde o Kirk’s pode escrever e os demais podem ler;/root– casa dos Borg, que na prática é o servidor inteiro.
# Diretorios particulares
# Propriedade e permissoes de pastas particulares
mkdir -p /home/watson;
mkdir -p /home/wayne;
chown -R watson:users /home/watson;
chown -R watson:users /home/wayne;
chmod 750 /home/watson;
chmod 750 /home/wayne;
# Diretorios compartilhados
mkdir -p /storage/projects;
mkdir -p /storage/shared;
chmod 755 /storage;
chmod 755 /storage/projects;
chmod 755 /storage/shared;
Os servidores Kirk e o Borg vão precisar de configurações separadas mesmo rodando ambos como root. Deixe as pastas criadas desde já:
# Diretorio de configuracoes do Opencode especificas para kirks e borgs
mkdir -p /opt/opencode/kirk;
mkdir -p /opt/opencode/borg;
x
x
x
x
x
3.1 – xxx
xxx
3.2 – xxx
xxx
x
x
x
x
x
CUIDADO
watson.seudominio.com
watson
watson
watson
Subscription
x
x
mínima
storage
x
x
x
Terminamos por hoje!
Patrick Brandão, patrickbrandao@gmail.com
“xxxxxxxxxxx“
Autor