Execute um agente de IA 24/7 num VPS.
Fora do portátil, sobre metal que não dorme.
Para executar um agente de IA 24/7 num VPS precisa de quatro coisas, nenhuma delas engenhosa: uma máquina que se mantém no ar, um supervisor que a reinicia, segredos que nunca entram na imagem, e um limite de gasto — mais um host que não exige a sua identidade.
- 01
A maioria dos agentes é cola limitada por I/O à volta de uma API de modelo alojada. A inferência não está na sua máquina, por isso a máquina é pequena: 2 vCPU e 4 GB são suficientes para um agente de loop único.
- 02
O uptime é um problema de supervisor, não de hardware. Uma unidade systemd ou uma política de restart do Docker — ativada, e testada com um reboot real — é tudo o que é preciso.
- 03
As duas coisas que realmente mordem: um segredo cozido numa camada da imagem, e um agente sem limite de gasto a fazer loop a noite toda contra uma API tarifada.
Porque é que o seu portátil não é um deployment. Quatro modos de falha, todos eles aborrecidos.
Um agente que funciona na sua máquina é um agente a funcionar, não um agente em produção. A diferença resume-se a quatro problemas pouco glamorosos, nenhum deles relacionado com prompt engineering.
Suspensão. Feche a tampa e o processo é suspenso. A gestão de energia já limita o trabalho em segundo plano bem antes de a tampa fechar, o que dá a pior versão desta falha: um agente que corre, mas tarde e de forma imprevisível.
Rotação de IP. Uma ligação de casa ou de um café dá-lhe um endereço novo a cada reconexão. Tudo o que tenha rate-limit por IP, qualquer webhook que precise de um callback estável, qualquer allowlist que tenha registado, parte de forma intermitente.
Reinícios. As atualizações do sistema operativo reiniciam a máquina segundo o seu próprio calendário. A menos que o agente esteja registado junto de um gestor de serviços, o que volta é um ambiente de trabalho, não um loop em execução. A maioria só repara uma semana depois.
Mudança. Viaja, troca de máquina, reinstala. Tudo o que só existe no seu histórico de shell não é reprodutível — um agente configurado numa tarde de março não tem procedimento de deployment nenhum.
Um servidor resolve estas quatro coisas e mais nada — não a correção, não o custo, não a segurança. Dá-lhe um runtime cujas falhas são suas para corrigir. Desconfie de quem o vender como mais do que isso.
Dimensionar a máquina. Que nível de VPS para que tipo de agente.
O instinto é sobre-dimensionar, porque inteligência artificial soa a algo pesado. Não é, desde que o modelo corra no hardware de outra pessoa: um agente que chama uma API alojada passa o tempo à espera de I/O de rede. Uma terceira forma — correr o próprio modelo — está fora do âmbito aqui; essa carga de trabalho quer uma GPU mais do que uma máquina virtual.
Forma um — o loop único. Um processo, um loop de polling ou agendado, uma API de modelo alojada, estado em SQLite. É o que a maioria dos agentes independentes e bots de monitorização são, e é genuinamente pequeno.
Forma dois — a pequena stack. O agente mais Postgres, uma fila com Redis, um worker e um vector store. A memória passa a ser a restrição dominante — um modelo de embeddings carregado no próprio processo quer um ou dois gigabytes só para si.
Olhando para o catálogo: Sentinel (NB-V1 — 2 vCPU, 4 GB RAM, 120 GB NVMe, 1 Gbps, largura de banda ilimitada, $3.90/month) cobre a forma um com folga de sobra. Garrison (NB-V2 — 4 vCPU, 8 GB, 240 GB, $7.90/month) é o piso honesto para a forma dois assim que Postgres e uma fila entram em cena. Ravelin (NB-V3 — 8 vCPU, 16 GB, 480 GB, 2.5 Gbps, $16.90/month) é para vários agentes a partilhar uma máquina. A inferência local pertence a hardware dedicado.
Os planos são mensais, com desconto para compromissos mais longos — 10% aos três meses, 20% aos seis, 30% aos doze. Se o seu agente for um cliente de trading apenas para Windows em vez de um processo Python, os planos de remote-desktop existem para esse caso.
O caminho do deploy — executar um agente de IA num VPS em cerca de quinze minutos.
Provisione a máquina com Ubuntu 24.04 LTS ou Debian 13 — ambos disponíveis no momento da encomenda, juntamente com Ubuntu 22.04, Debian 12, AlmaLinux 9 e Rocky Linux 9. Recebe credenciais de root; a primeira coisa a fazer com elas é deixar de as usar. Se a autenticação por chave SSH for território desconhecido, leia primeiro o guia de hardening ligado abaixo.
1 — Crie um utilizador de serviço. adduser --system --group --home /srv/agent agent. O agente não deve correr como root nem ter uma shell interativa. Um comando agora, e o raio de explosão mantém-se pequeno mais tarde se uma ferramenta que ele chama for usada contra ele.
2 — Coloque o código na máquina. git clone para /srv/agent, ou rsync se preferir não deixar uma deploy key no servidor. Fixe as dependências: um lockfile é a diferença entre um redeploy que reproduz e um que o surpreende.
3 — Construa o ambiente. python3 -m venv /srv/agent/.venv, depois instale a partir do lockfile com o pip desse virtualenv. Ou instale uv e deixe-o gerir tanto o interpretador como o lockfile. Qualquer um dos dois serve; misturar os dois não.
4 — Execute-o uma vez manualmente. sudo -u agent /srv/agent/.venv/bin/python -m agent --once. Não salte este passo para ir direto a uma unidade de serviço. Nove em cada dez falhas aqui são uma variável de ambiente em falta ou um caminho relativo ao seu portátil, e ambas leem-se com mais clareza num terminal do que no journald.
5 — Entregue-o a um supervisor. O próximo capítulo. É isto que transforma um script que iniciou num serviço que pertence à máquina. Se a sequência demorou consideravelmente mais do que quinze minutos, a causa é quase sempre uma dependência implícita da sua máquina de desenvolvimento — um binário global, uma credencial no seu perfil de shell, um caminho fora do repositório.
Mantê-lo vivo 24/7. systemd, Docker, e a armadilha do crash-loop.
Um processo que iniciou numa sessão SSH morre quando a sessão termina, e não volta depois de um reboot. A supervisão não é opcional, e tem duas opções razoáveis.
systemd, para um único processo. Uma unidade em /etc/systemd/system/agent.service com User=agent, WorkingDirectory=/srv/agent, ExecStart a apontar para o interpretador do virtualenv, Restart=always e RestartSec=5. Depois systemctl daemon-reload, depois systemctl enable --now agent. É o enable que sobrevive a um reboot; iniciar sem ativar é a forma mais comum de perder um agente três semanas depois.
Docker, para um conjunto de coisas. Quando o agente tem processos irmãos — uma base de dados, uma fila, um browser headless — descreva-os num único ficheiro Compose com restart: unless-stopped em cada serviço. unless-stopped difere de always num aspeto que importa: um container que parou deliberadamente permanece parado ao longo de um reinício do daemon.
A armadilha do crash-loop. Por predefinição, o systemd limita a taxa de reinícios. Falhe com frequência suficiente dentro do intervalo e a unidade entra no estado failed e para de tentar — um agente que parece ter morrido silenciosamente enquanto o ficheiro da unidade diz claramente Restart=always. Defina StartLimitIntervalSec=0 para tentar indefinidamente, e aumente RestartSec para que um agente avariado não gaste um núcleo a noite toda.
Liveness não é health. Um loop preso numa leitura de socket durante nove horas é um processo em execução segundo qualquer medida que o systemd consiga ver. Exponha um heartbeat: um watchdog com WatchdogSec, um HEALTHCHECK do Docker, ou um ficheiro de timestamp que o agente toca a cada ciclo, com um timer que alerta quando fica desatualizado.
Segredos. O ficheiro de ambiente que nunca deve chegar à imagem.
Um agente detém material mais perigoso do que uma aplicação web. Uma chave de API de modelo é um instrumento de gasto; uma chave de trading é uma com alavancagem; uma chave de wallet são os próprios fundos. E, ao contrário de uma aplicação web, um agente age sobre texto que não escreveu, o que torna ténue a fronteira entre o agente deter uma chave e um atacante detê-la.
Mantenha-as fora da imagem. Os valores ENV e ARG num Dockerfile são escritos nas camadas da imagem e ficam legíveis com docker history por qualquer pessoa que obtenha a imagem. Use env_file: no Compose, ou EnvironmentFile= na unidade systemd, e mantenha o ficheiro fora do contexto de build.
Mantenha-as fora do repositório. .gitignore e .dockerignore logo no primeiro commit, não no quinquagésimo. Uma chave que alguma vez tenha sido commitada está comprometida mesmo depois de o commit ser reescrito, porque o objeto sobrevive em clones e forks. Rode-a em vez de reescrever o histórico.
Restrinja o que o ficheiro consegue alcançar. Atribua o ficheiro de ambiente ao utilizador do serviço e defina mode 600. Combinado com um utilizador de serviço non-root, uma dependência comprometida noutro ponto da máquina não consegue simplesmente ler as suas chaves do disco.
Delimite cada chave junto do emissor. Uma chave por agente, com as permissões mais restritas que o fornecedor oferecer — read-only onde a leitura basta, levantamentos desativados nas chaves de exchange, com allowlist de IP para o servidor. Um IP estável é uma vantagem discreta de sair do portátil: o allowlisting finalmente torna-se possível. Se várias pessoas precisarem das mesmas credenciais, coloque-as atrás do vault self-hosted no guia complementar.
Agendamento. Loops, timers e o fuso horário que o morde.
Correr continuamente descreve três arquiteturas diferentes, e escolher a errada é uma fonte comum de trabalho duplicado e execuções perdidas.
O loop residente. Um processo de longa duração que dorme entre ciclos. É o mais simples de raciocinar, e a opção certa por defeito. A sua fraqueza é o estado: tudo o que está em memória perde-se ao reiniciar, por isso tudo o que deva sobreviver a um crash pertence ao SQLite ou ao Postgres, não a uma variável.
A execução agendada. Um processo que arranca, faz uma unidade de trabalho e termina. Um timer systemd com OnCalendar é a ferramenta melhor aqui, sobretudo por causa de Persistent=true: depois de um período de downtime, um timer persistente dispara a execução que perdeu, enquanto o cron simplesmente a salta.
A fila. Um produtor enfileira tarefas, workers consomem-nas. É isto que quer a partir do momento em que as tarefas chegam mais depressa do que são concluídas. Também lhe dá retries, tratamento de dead-letter e um teto de concorrência.
Duas regras seja qual for a escolha. Torne cada tarefa idempotente — um supervisor que reinicia após um crash vai repetir tarefas, e uma tarefa repetida não pode publicar em duplicado nem encomendar em duplicado. E deixe o relógio do servidor em UTC, convertendo apenas nas extremidades: um horário que desvia uma hora duas vezes por ano é um bug tedioso de encontrar.
Dar ferramentas ao agente. Um servidor de ferramentas na mesma máquina.
Um agente sem ferramentas é um loop de chat. São as ferramentas que lhe permitem ler um repositório, consultar uma base de dados, fazer uma encomenda ou abrir um issue — e assim que o agente passa a viver num servidor, elas também devem passar.
O Model Context Protocol tornou-se a forma comum de expor essas ferramentas, e um servidor que corre em privado é fácil de colocar junto do agente: mesma máquina, mesma interface privada, sem necessidade de exposição pública. Os guias complementares cobrem isto em detalhe — alojar um servidor MCP remoto percorre o TLS, o transporte streamable-HTTP, o OAuth e o agent card, enquanto o ângulo do alojamento sem ID cobre a mesma stack pelo lado da identidade.
Primeiro, ligue-o ao localhost. Se o único consumidor for o agente na mesma máquina, o servidor de ferramentas não tem motivo para ocupar uma porta pública. Ligue-o ao endereço de loopback e dispense o certificado. Exponha-o publicamente apenas quando uma segunda máquina precisar dele — e nesse caso precisa de TLS e autenticação, não de apenas um dos dois.
Dê às ferramentas a menor autoridade que funcione. O agente decide que ferramenta chamar com base em texto, e parte desse texto vem de fora. A prompt injection não é hipotética para um agente que lê páginas web ou caixas de entrada: é o caso esperado. Uma ferramenta que só pode ler não pode ser convencida a escrever. Onde uma ferramenta tiver mesmo de escrever, faça com que os caminhos destrutivos exijam confirmação humana.
Se está a construir ferramentas para agentes de outras pessoas em vez de para o seu próprio, a API de máquina e a superfície voltada para agentes documentam como esta plataforma expõe o provisionamento diretamente a um agente.
Observabilidade e custo. O que registar, e o kill-switch para descontrolos.
Dois modos de falha dominam os deployments reais de agentes, e nenhum deles é um crash. Um é o agente que corre perfeitamente e não produz nada útil. O outro é o agente que corre perfeitamente e produz uma fatura de API de quatro dígitos numa única noite.
Registe a forma, não o conteúdo. Timestamp, task id, contagem de passos, nomes das ferramentas invocadas, totais de tokens, duração, resultado. Isso responde a todas as perguntas operacionais que alguma vez fará. Prompts e completions completos são uma transcrição de tudo o que já foi pedido ao agente, em texto simples, num disco no edifício de outra pessoa.
Limite a retenção. O journald continua a crescer até lhe dizer para não o fazer. SystemMaxUse e MaxRetentionSec no journald.conf impõem um teto tanto ao tamanho como à idade. Sem isso, um agente tagarela enche um disco em semanas, e um disco cheio falha de formas muito mais difíceis de interpretar do que um crash limpo.
Três camadas de controlo de gasto. No fornecedor, um teto rígido na chave de API — o único limite que nenhum bug no seu código consegue contornar, e o que as pessoas costumam saltar. No agente, um contador de tokens por execução com um limiar de aborto. À volta do agente, uma contagem máxima de passos e um timeout de relógio real, para que um modelo a discutir consigo mesmo pare ao fim de vinte iterações em vez de quatro mil.
Construa o kill-switch antes de precisar dele. Um único comando que para tudo: systemctl stop agent, ou docker compose down. Certifique-se de que não exige um portátil com uma chave específica lá dentro. A diferença entre uma má noite e um mau mês é se parar um descontrolo demora dez segundos ou uma hora.
O piso da identidade. O que o host sabe — e do que não consegue protegê-lo.
Um agente é um processo de longa duração com credenciais, a agir em seu nome a partir de um endereço estável, continuamente. Isso torna o registo do aluguer mais interessante do que para um site estático: está a fazer coisas atribuíveis a si, todas as horas, durante meses.
O piso aqui é um endereço de email e uma palavra-passe para se registar, pagamento em oito ativos — Bitcoin, Ethereum, Tether em duas chains, Monero, Litecoin, TRON e Solana — e nenhum documento de identidade em nenhuma etapa. Os centros de dados situam-se em quatro regimes constitucionais nórdicos: Stockholm, Helsinki, Oslo e Reykjavík. A doutrina operacional estabelece o que é retido; a página de rede cobre o encaminhamento.
Agora o limite, que importa mais do que o discurso de venda. Um host que não pede identidade remove o registo do aluguer. Não toca na camada de inferência: o seu agente autentica-se junto de um fornecedor de modelo com uma chave ligada a uma conta, a partir de um IP estável, em cada chamada. Se essa conta estiver em seu nome legal — e, para a maioria das pessoas, está — a identidade fica estabelecida ali, independentemente de quem aluga o metal. A camada do host remove um elo: um elo real, e só um.
O que se segue não tem nada de glamoroso. Compartimente: um agente, um servidor, uma chave, uma wallet. Reforce a segurança da máquina no primeiro dia, não no trigésimo — a checklist da primeira hora é uma hora bem gasta numa máquina que corre sem vigilância durante meses. Se o agente precisar de alcançar uma rede privada, termine-a no servidor com um túnel em vez de expor serviços — o guia do túnel cobre a configuração. E pague em cripto a partir de uma wallet que não seja aquela de onde o seu agente negoceia.
Nada disto é exótico, e nada disto é uma garantia. É a disciplina comum de correr algo que age em seu nome enquanto está a dormir — que é tudo o que a operação contínua significa. O resto do cluster está no índice de guias.
Perguntas, respondidas.
Sete perguntas que os programadores fazem antes de tirar um agente do localhost — e no primeiro mês a seguir.
De quanto VPS preciso para executar um agente de IA 24/7?
Menos do que se costuma pensar, porque a inferência acontece no hardware do fornecedor, não no seu. Um agente que chama uma API de modelo alojada e corre num loop de polling é um processo limitado por I/O: o nível Sentinel (2 vCPU, 4 GB RAM, 120 GB NVMe, $3.90/month) chega e sobra. Suba para o Garrison (4 vCPU, 8 GB, $7.90/month) assim que acrescentar Postgres, uma fila e um modelo de embeddings local.
Devo usar systemd ou Docker para manter o agente em execução?
Qualquer um funciona; os modos de falha é que diferem. Uma unidade systemd com Restart=always é o caminho mais curto para um único processo e dá-lhe journald, limites de recursos e ordenação de arranque de graça. O Docker com restart: unless-stopped é melhor quando o agente tem processos irmãos, porque o Compose descreve todo o conjunto num único ficheiro. O que importa mais é realmente ativar isso, e testar um reboot antes de sair de cena.
Por que motivo o meu agente para de reiniciar depois de alguns crashes?
Porque o systemd limita a taxa de reinícios. StartLimitBurst e StartLimitIntervalSec permitem um pequeno número de reinícios dentro de uma janela curta; exceda-os e a unidade entra no estado failed e fica lá, o que parece exatamente uma morte silenciosa. Ou corrige a causa do crash — a resposta correta — ou define StartLimitIntervalSec=0 para desativar o limitador e RestartSec=10 para que um agente em crash-loop não queime um núcleo a tentar repetidamente.
Onde devo colocar as chaves de API?
Num ficheiro que a imagem do container nunca vê. Mantenha um ficheiro de ambiente fora do contexto de build, referenciado por EnvironmentFile= na unidade systemd ou env_file: no Compose, pertencente ao utilizador do serviço com mode 600. Nunca use ENV ou ARG num Dockerfile para um segredo: esses valores ficam cozidos nas camadas da imagem e são legíveis com docker history. Adicione o ficheiro ao .gitignore e ao .dockerignore antes do primeiro commit.
Como evito que um agente gaste todo o meu orçamento de API durante a noite?
Três camadas, e quer as três. No fornecedor: um limite rígido de gasto na chave de API, o único limite que nenhum bug no seu código consegue contornar. No agente: conte tokens ou chamadas por execução e aborte acima de um limiar. À volta do agente: um teto de passos por tarefa e um timeout de relógio real. Nenhum host consegue fazer isto por si — um VPS é capacidade alugada, não uma salvaguarda de orçamento sobre a API de outra pessoa.
O que nunca devo escrever nos registos do agente?
Prompts e completions completos, argumentos de ferramentas em bruto, chaves de API, material de wallets e tudo o que um utilizador tenha escrito. Registe antes a forma da execução: timestamp, task id, contagem de passos, nomes das ferramentas, totais de tokens, duração, resultado. Um registo de agente demasiado detalhado é uma transcrição de tudo o que já foi pedido ao agente, em texto simples, num disco que não controla fisicamente.
Um host sem KYC torna o meu agente anónimo?
Não, e vale a pena ser preciso. Um registo sem identificação e um pagamento em cripto significam que o host não tem identidade legal para associar ao servidor. Isso não altera nada quanto ao fornecedor do modelo: o seu agente autentica-se nessa API com uma chave ligada a uma conta, a partir de um IP de servidor estável, em cada chamada. A camada do host remove um elo da cadeia — o registo do aluguer — e é só isso que remove.
Alugue um VPS sem KYC, pague em cripto, tire o agente do portátil ainda esta noite.
Sentinel — 2 vCPU, 4 GB RAM, 120 GB NVMe, largura de banda ilimitada, $3.90/month — aguenta um agente de loop único com espaço para o seu servidor de ferramentas ao lado. Um endereço de email e uma palavra-passe para se registar; nenhum documento em nenhuma etapa.
Última revisão · 2026-08-24 · Fontes · Páginas de manual systemd.service, systemd.timer e journald.conf, documentação de restart-policy do Docker e do Compose, especificação do Model Context Protocol, catálogo NordBastion · Cadência · anualmente
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Docker Compose, PostgreSQL, webhooks que funcionam — automação que é sua.
Ollama em CPU, sem GPU — o que cabe em 4, 8, 16 ou 32 GB.