Tudo o que você precisa para ir do cadastro a uma aplicação no ar.
git push
publique a partir daí.Com algo rodando, o menu da esquerda cobre o resto da máquina: bancos de dados, tarefas agendadas, o firewall and Acesso SSH.
Tudo é gratuito durante o beta, até 17 de setembro de 2026. Os planos pagos abrem depois disso; o gratuito continua gratuito.
| Plano | Preço | O que permite |
|---|---|---|
| Gratuito | $0 | 1 servidor · 1 domínio · 3 aplicações |
| Pro | US$ 12/mês | 5 servidores · domínios ilimitados · aplicações ilimitadas |
| Business | US$ 29/mês | servidores ilimitados · domínios ilimitados · aplicações ilimitadas |
Os limites contam o que existe, não o que você já criou algum dia: apague uma aplicação e a vaga volta. Uma cópia de staging é uma aplicação como outra qualquer, então conta. O Buddy nunca apaga nada seu para abrir espaço — ele se recusa a criar a próxima e diz qual limite você atingiu.
Nada disso é o custo dos seus servidores. Esses você paga direto ao seu provedor de cloud, no preço dele, sem margem nossa.
O Buddy guarda toda credencial criptografada e a usa apenas para as operações que você dispara.
Use um Personal Access Token — a Tokens aba de API no painel de controle, não OAuth Applications (essas são para aplicações agindo na conta de outra pessoa).
droplet: create, read, update, delete.dop_v1_ e é mostrado uma única vez.Ainda não liberado, então o Buddy não aceita um token da Hetzner: a integração está escrita, mas nunca criou um servidor numa conta de verdade, e lançá-la assim faria de você a pessoa que descobre. Quando abrir, o token sai do Cloud Console (não do painel Robot) → seu projeto → Security → API tokens → Generate, com Read & Write.
Account → API → habilite a API e copie o Personal Access Token. Em Access Control libere
0.0.0.0/0: o Buddy chama a Vultr a partir do Google Cloud e o IP de origem não é fixo, então uma lista de permissão só com o seu endereço bloqueia. As chaves da Vultr valem para a conta inteira — não há escopo por recurso.
Crie um usuário IAM — não a sua conta root, cujas chaves não têm como ser restritas — e gere uma access key (Security credentials → Create access key → Third-party service). Cole o ID da chave e o segredo; o segredo é mostrado uma vez e não tem como recuperar.
AmazonEC2FullAccess para servidores,
AmazonS3FullAccess para backups, AmazonSSMReadOnlyAccess para o Buddy conseguir descobrir a imagem Ubuntu atual da região que você escolher, e AmazonRDSFullAccess para bancos de dados.
AmazonRDSReadOnlyAccess basta se você só quer que o Buddy liste as instâncias que você já roda; criar uma pela página de Bancos de dados exige a política completa. De todo jeito, esta chave nunca cria um banco nem um login dentro de uma instância — a AWS não tem API para isso, então o Buddy faz por meio de um servidor seu.buddy-managed por VPC, abrindo as portas 22, 80 e 443. Nada mais é tocado.Crie uma service account com roles/compute.admin (mais roles/storage.admin se você quiser backups), gere uma chave JSON e cole o JSON:
gcloud iam service-accounts create buddy-deployer --project=SEU-PROJETO gcloud projects add-iam-policy-binding SEU-PROJETO \ --member="serviceAccount:buddy-deployer@SEU-PROJETO.iam.gserviceaccount.com" \ --role="roles/compute.admin" gcloud iam service-accounts keys create key.json \ --iam-account=buddy-deployer@SEU-PROJETO.iam.gserviceaccount.com
My Profile → API Tokens → Create Token → Edit zone DNS modelo, restrito em Zone Resources aos domínios que o Buddy deve administrar. Use um tokende API, não a Global API Key — esta última dá acesso a tudo na sua conta e não tem como ser restrita.
Acesso somente leitura aos repositórios que você publica. Veja repositórios privados.
Servidores → Adicionar servidor → escolha provedor, credencial, região, tamanho e sistema operacional. Por enquanto são oferecidas versões LTS do Ubuntu; a lista vem da sua própria conta no provedor, então está sempre atual.
Depois escolha como as aplicações rodam na máquina:
Guarde suas chaves públicas em Acesso SSH e escolha-as ao criar um servidor; o Buddy as instala para o root no primeiro boot. Remover uma chave dessa lista nunca mexe num servidor que já a tem — tirar acesso é coisa que se faz na máquina, de propósito. Um servidor que você trouxe não recebe chave nenhuma, porque não há primeiro boot onde instalá-las: ele já é seu e já está acessível.
A script de inicialização é algo seu para rodar num servidor novo — pacotes que você sempre quer, um agente de monitoramento, seus dotfiles. Escreva em Servidores e escolha no formulário.
Ele não roda pelo cloud-init, que é como os provedores fazem, e a diferença vale ser conhecida. Um script de boot que falha deixa um servidor que nunca aparece no painel, ou aparece quebrado, com o motivo num log de uma máquina que talvez você não consiga alcançar. O Buddy roda o seu como um comando comum no instante em que o agente dá o primeiro sinal: depois de a máquina estar pronta e acessível, então um erro no seu script não quebra a instalação; uma vez só, como root; e com a saída no registro de atividade daquele servidor, onde a falha é visível e dá para ler o que aconteceu. Funciona igual num servidor que você mesmo trouxe.
Editar ou apagar um script muda o que o próximo servidor recebe. Um servidor que já o executou não é tocado, e nada roda de novo sozinho.
A página de Bancos de dados pode criar três coisas para você, e elas não custam a mesma coisa.
Apagar só é oferecido para instâncias que o Buddy criou, e pede que você digite o nome antes. Uma instância que já existia na sua conta é listada e pode ser administrada, nunca removida — um clique errado no banco de produção de alguém não vale a comodidade de um botão. Remover um motor que o Buddy instalou num servidor seu tira a entrada da página e deixa o software instalado, porque outra aplicação daquela máquina pode estar usando.
Um servidor clássico é criado com um banco de dados, instalado no primeiro deploy e compartilhado por todos os sites daquela máquina — então a escolha não muda depois. Só versões de suporte longo são oferecidas, porque esta é a única coisa na máquina que você não troca por capricho mais tarde:
As aplicações prontas daqui — WordPress, Drupal, Joomla, Nextcloud, Magento — todas precisam de MySQL ou MariaDB, então um servidor clássico criado com PostgreSQL não as oferece. Ele avisa quando você tenta, em vez de falhar no meio da instalação. Uma aplicação publicada via Git usa livremente o motor que o servidor dela tiver.
O Buddy fala com MariaDB, MySQL e PostgreSQL do mesmo jeito: cria um banco e um usuário restrito a ele para cada aplicação, faz dump nos backups e apaga quando a aplicação é excluída.
A Bancos de dados página faz mais do que listar o que existe. Num servidor clássico você pode criar um banco, criar um login e dar acesso a ele, definir uma senha nova para um login, e remover qualquer um dos dois — cada operação é executada pelo agente na máquina. O Buddy nunca se conecta ao seu banco; ele não tem rota até lá, e nem deveria ter.
Fazer backup ao lado de um banco faz o dump só daquele schema num bucket do seu próprio projeto de cloud, e Restaurar devolve. Uma restauração pode ir para outro banco, se você informar o nome — é assim que se leva uma cópia de produção para um banco de rascunho sem tocar no original. Restaurar substitui o que estiver no destino.
O banco e o login próprios de uma aplicação não são oferecidos para exclusão aqui: removê-los deixaria o site no ar e sem alcançar os próprios dados. Apague a aplicação, que remove os dois.
Senhas geradas são mostradas uma vez e nunca ficam guardadas — o Buddy não tem como te dizer uma de novo, só definir outra.
Uma aplicação num servidor clássico pode usar uma instância Cloud SQL no seu próprio projeto do Google Cloud em vez do banco da máquina. Conecte a conta do Google Cloud dona dela em
Contas de cloud — a service account precisa de roles/cloudsql.admin — e a instância aparece no formulário da aplicação.
A cada deploy o Buddy cria o schema da aplicação e um usuário restrito a ele, e adiciona o IP do servidor às redes autorizadas da instância. Apagar a aplicação remove esse schema e esse usuário. A instância continua sempre sua: o Buddy nunca cria, redimensiona nem apaga uma, então nada aqui começa a te custar dinheiro por conta própria. A instância precisa ter IP público — o Buddy conecta no endpoint público por trás da lista de permissão, não pelo Cloud SQL Auth Proxy.
Conecte uma conta AWS e toda instância MySQL, MariaDB e PostgreSQL que ela enxerga é listada, em todas as regiões que o Buddy oferece. Oracle e SQL Server ficam de fora — não há nada de útil que o Buddy pudesse fazer com eles.
O RDS funciona diferente do Cloud SQL, e vale saber por quê. A API do Google consegue criar um banco, criar um login e exportar um schema; a AWS não tem equivalente — a API do RDS cria instâncias e snapshots, e tudo o que existe dentro de uma instância só é alcançável por uma conexão SQL. Então administrar uma instância RDS passa por um servidor seu: escolha o servidor que alcança o endpoint, dê ao Buddy o login mestre, e esse servidor executa o SQL. A senha mestra é guardada criptografada e só é enviada ao servidor que você escolheu; a AWS nunca a revela, e é por isso que é preciso informá-la ao Buddy.
O servidor precisa conseguir alcançar o endpoint — mesma VPC, ou um security group que o deixe entrar. Uma instância privada é invisível para qualquer coisa fora da VPC dela, então um servidor em outro lugar não consegue administrá-la por mais correta que a senha esteja.
Fazer backup aqui é o dump de um banco no seu próprio bucket S3, não um snapshot do RDS: um snapshot cobre a instância inteira e só restaura como uma instância nova, o que é uma coisa bem maior e mais cara do que devolver um schema para o lugar de onde ele saiu. O Buddy nunca cria, redimensiona nem apaga uma instância.
Qualquer servidor Debian/Ubuntu com Docker serve. Crie um servidor com “Eu já tenho um servidor” e rode o comando de instalação mostrado na página dele:
curl -fsSL https://devopsbuddy.io/install.sh | sudo BUDDY_TOKEN=… BUDDY_URL=https://devopsbuddy.io bash
O agente é só de saída: ele consulta por HTTPS e nada passa a escutar no seu servidor. Nota: em servidores seus, o proxy reverso é responsabilidade sua, a menos que você deixe o Buddy provisionar o Traefik.
Escolha Repositório Git como origem, cole a URL e, se quiser, uma branch. O agente clona e compila com Nixpacks — PHP/composer, Node, Python, Go, Ruby e outros são detectados automaticamente. Sua aplicação precisa escutar na variável de ambiente PORT (padrão 8080).
Escolha Aplicação pronta como origem e o Buddy publica a aplicação com o banco dela, o cache onde houver, e HTTPS — e então a instala. Você chega num site funcionando, com a conta de administrador mostrada na página da aplicação, não num assistente de instalação. A senha é gerada para você e guardada criptografada.
| Aplicação | Roda em | Vem com |
|---|---|---|
| WordPress | container + clássico | MySQL ou MariaDB, cache de objetos Redis opcional, PHP ajustado com OPcache |
| Drupal | container + clássico | MariaDB, o perfil padrão instalado, e o Drush para caches e atualizações |
| Joomla | container + clássico | MariaDB, com o instalador removido depois de rodar |
| Nextcloud | container + clássico | MariaDB, travamento de arquivos com Redis, arquivos dos usuários fora da raiz web |
| Magento | container + clássico | MySQL, OpenSearch, Redis para sessões e cache |
A instalação roda de novo a cada deploy e para assim que percebe que a aplicação já existe, então refazer o deploy é seguro e leva cerca de um segundo.
O Magento é o pesado, nos dois tipos de servidor. A Adobe não publica imagem, então a loja é compilada a partir do código na sua máquina. Antes de escolher:
127.0.0.1, então nada de fora da máquina o alcança.Não é preciso conta no Adobe Marketplace: a versão Open Source é uma tag pública e as dependências vêm do Packagist.
Num servidor clássico, o login de administrador do Joomla precisa ser só letras — o instalador do próprio Joomla recusa qualquer outra coisa, e recusa no servidor, não no formulário.
Conecte Bitbucket, GitHub ou GitLab em Contas de cloud, e depois escolha essa conta na caixa Repositório privado? do formulário da aplicação. O Buddy precisa de acesso somente leitura — ele clona, nunca faz push.
Use sempre o endereço https:// do repositório. Uma URL ssh:// or
git@host:caminho não tem onde carregar um token, e o Buddy avisa isso em vez de falhar na hora do deploy.
repository:read. Cole o token e deixe o usuário em branco.read_repository.Criptografado, na credencial — nunca na aplicação e nunca no histórico de deploy. Cada deploy carrega apenas uma referência à credencial; a URL de clone é montada no momento em que o seu servidor pede o trabalho. Se um clone falha, o git repete o remote que tentou, então as credenciais são removidas do log antes de ele ser guardado. E como o token chega à sua máquina, ele acaba em .git/config dentro do diretório da aplicação lá — em servidores clássicos o vhost bloqueia arquivos ocultos, então ele nunca é alcançável pela web.
Revogue um token no Bitbucket ou no GitHub e o próximo deploy falha de forma limpa; desconectar a conta em Contas de cloud não mexe nas aplicações que estão rodando, mas impede deploys futuros de repositórios privados.
Cole qualquer arquivo compose. Quando há um domínio definido, o Buddy remove os vínculos de porta do host no serviço web, injeta os labels do Traefik (TLS via Let's Encrypt) e liga os serviços à rede compartilhada buddy Dados persistentes vão em ./data (montado em /var/lib/buddy/apps/<slug>/data na VM).
Escolha um domínio e um subdomínio no formulário da aplicação. O Buddy cria ou atualiza o registro A na Cloudflare para o IP da VM e o Traefik obtém o certificado — a aplicação fica no ar em https://sub.seudominio.com logo depois do primeiro deploy.
Na página de uma aplicação, Proteção por senha pede usuário e senha antes de qualquer coisa do site carregar. Deixe a senha em branco e o Buddy gera uma; ela aparece nessa página. Vale a partir do próximo deploy.
Cópias de staging recebem isso automaticamente. Um clone é uma segunda cópia de um site no ar — o conteúdo dele, e muitas vezes os dados dos clientes — parada na internet pública sob um nome que qualquer um adivinha. As credenciais estão na página do clone; desligue por lá se a cópia é para ser vista.
O certificado continua renovando de qualquer forma: a verificação do Let's Encrypt passa sem senha — do contrário, esta seria uma excelente maneira de fazer um site expirar em noventa dias.
Numa aplicação Git, abra e ligue o Deploy no push. O Buddy mostra uma URL e um segredo para colar nas configurações de webhook do seu repositório:
application/json, segredo no campo Segredo , evento: apenas pushes.?secret=…; esse link é o segredo, e quem o tiver consegue disparar um deploy.Só pushes na branch que a aplicação acompanha disparam deploy — um push em qualquer outra branch é respondido com educação e ignorado. Requisições do GitHub e do GitLab são conferidas contra o segredo antes de qualquer coisa acontecer, então um estranho que adivinhe a URL recebe 401. Se o segredo vazar, Trocar o segredo o substitui; os deploys param até você colar o novo no repositório.
Em Tarefas agendadas, escolha um servidor e dê à tarefa um nome, um horário de cinco campos, o usuário que a executa e um comando. O Buddy escreve um único arquivo, /etc/cron.d/buddy, e o reescreve inteiro toda vez que você muda algo aqui — a sua própria crontab e qualquer outra coisa em /etc/cron.d nunca são lidas nem modificadas.
Use caminhos absolutos: o ambiente do cron não é o do seu shell de login. Atalhos nomeados como @daily
não são aceitos; escreva por extenso (0 3 * * *). Pausar uma tarefa a tira do arquivo sem esquecer o que ela era.
Um worker é um processo que deve estar sempre rodando — um worker de fila do Laravel, um consumidor, um daemon agendador. Na página da aplicação (servidores clássicos), adicione um com nome, comando, usuário e quantos processos você quer. O Buddy escreve uma unidade do systemd por processo, então cada um é reiniciado se terminar e ligado de novo após um reboot, e a saída vai para o journal (journalctl -u buddy-worker-<app>-<nome>).
Parar envia SIGTERM e espera o tempo limite que você definiu (60 segundos por padrão) antes de matá-lo — é isso que permite a um worker de fila terminar o trabalho que está segurando em vez de perdê-lo. Num servidor de containers, adicione o processo ao seu arquivo compose.
Servidores começam alcançáveis apenas como root, com a chave que você colou ao criá-los. Em
Acesso SSH você pode dar a cada pessoa uma conta própria: um usuário e uma ou mais chaves públicas, com a opção de sudo.
As contas são só com chave — nenhuma senha é definida — e o Buddy administra apenas as contas que ele criou, então o que você configurou na máquina fica intacto. Remover um login apaga a conta e o diretório pessoal dela na próxima sincronização, que é como se tira o acesso de uma pessoa sem tocar no de ninguém mais.
Toda VM criada pelo Buddy instala as próprias atualizações de segurança: unattended-upgrades é configurado só para o repositório de segurança, e nunca reinicia a máquina sozinho. Atualizações de kernel, portanto, esperam um reboot que você escolher. Num servidor que você trouxe, o que já existia fica como está.
Todo site num servidor clássico é servido por uma configuração de nginx que o Buddy escreve e reescreve a cada deploy. Você não precisa pedir nada disso:
X-Content-Type-Options: nosniff,
X-Frame-Options: SAMEORIGIN e uma política de referrer estrita..php que chegue por upload de arquivo é recusado em vez de executado — a forma mais comum de um site de conteúdo ser tomado..env, .git, dumps de banco de dados, .bak, .log e parentes devolvem 403. Os bots começam a pedir minutos depois de um endereço novo aparecer./.well-known/, de que os certificados precisam.xmlrpc.php fica bloqueado — ele aceita tentativas de senha em lote e pode ser usado para refletir tráfego contra outra pessoa — e wp-login.php tem limite de 20 tentativas por minuto por endereço, que uma pessoa nunca percebe e uma lista de senhas não vence. Entregas legíveis como readme.html e um wp-config.php esquecido também são recusados..htaccess proteja são bloqueados no nginx, que não lê
.htaccess.pub/, e tudo acima disso — código, configuração, código gerado — é bloqueado além de estar fora da raiz de documentos.Servidores de container ficam atrás do Traefik, que termina o TLS e roteia por nome de host; a imagem da própria aplicação decide o que ela serve.
Os dois tipos de servidor foram feitos para abrigar mais de um site, e cada aplicação se mantém no seu canto:
/var/www/<app>, regras de nginx próprias, logs de acesso e de erro próprios.O plano gratuito permite um servidor e um domínio, com quantas aplicações você quiser nele.
Desligado por padrão. Ligar num servidor abre as portas 80 e 443 para o mundo e fecha todo o resto; adicione uma regra para qualquer coisa além disso, se quiser limitada a uma rede (10.0.0.0/8, o endereço do seu escritório). Todos os seus servidores ficam numa página só em Firewall.
As regras são aplicadas com iptables em duas chains. Isso não é um detalhe de implementação que dê para ignorar: o Docker publica portas escrevendo regras avaliadas antes da chain de entrada usual, então um firewall que só guardasse o host deixaria passar, calado, toda porta de container publicada. O Buddy guarda as duas.
SSH, tráfego de loopback e ping são sempre permitidos, digam as regras o que disserem — um firewall capaz de te trancar do lado de fora é pior que nenhum.
Uma regra fecha uma porta; isto fecha a porta para um visitante. Ligue o Bloquear endereços que insistem em errar e o Buddy instala o fail2ban com quatro jails: falhas repetidas de SSH, senhas erradas repetidas num site protegido por senha, quem martela uma página de login além do limite, e os scanners que pedem a todo endereço novo o .env and .git/config. O banimento dura uma hora, duas no caso do SSH.
Toda aplicação pronta tem um limite na frente da página de login — vinte tentativas por minuto por endereço, invisível para uma pessoa e inútil para um bot varrendo uma lista de senhas. Sozinho, esse limite só responde 429, o que não custa nada a quem envia; com o bloqueio ligado, um endereço que insiste em colecionar 429 deixa de ser respondido.
Um banimento só cobre as portas de que a jail dele trata, então esbarrar numa jail web testando o seu próprio site nunca custa o seu SSH. Se você se trancar fora de um site, o banimento expira sozinho, ou
fail2ban-client unban --all no servidor limpa na hora.
Não é CSF, de propósito. O CSF quer ser dono do firewall inteiro, e num servidor com containers a lista de portas dele não cobre o que o Docker publica — que é exatamente o caso que as duas chains do Buddy tratam. O fail2ban escreve numa chain própria e não mexe no resto.
Na página da aplicação, Fazer backup agora arquiva o diretório da aplicação (arquivos compose + ./data) num bucket buddy-backups-* na sua própria conta de cloud — Google Cloud Storage (a service account precisa de roles/storage.admin) ou Amazon S3 (a chave precisa de s3:CreateBucket,
s3:PutObject and s3:GetObject). O Buddy cria o bucket no primeiro backup. Com os dois conectados, ele usa o da mesma cloud do servidor, para os bytes não atravessarem uma rede que você paga.
Restaurar para a aplicação, restaura o snapshot e a coloca no ar de novo, sempre lendo do bucket para onde aquele backup de fato foi. As transferências usam URLs pré-assinadas — as credenciais de armazenamento nunca chegam à VM.
O agente reporta CPU, memória e disco do servidor e métricas de container por aplicação a cada 20 segundos. Elas aparecem no painel, nas páginas de servidor e nas de aplicação.
Conta → Ativar 2FA → escaneie o QR com qualquer app autenticador e confirme com um código. A partir daí, o login pede um código de 6 dígitos.
O Buddy envia uma mensagem de boas-vindas quando você se cadastra, um link quando você pede para redefinir a senha, e um aviso quando essa senha muda. Mais nada — sem newsletters, e nenhum endereço é repassado a ninguém.
As respostas vão para buddy@devopsbuddy.io e chegam a uma pessoa. Se uma mensagem nunca aparecer, olhe primeiro na pasta de spam e depois escreva para esse endereço de onde você quiser.
A Atividade registra o que mudou e quem mudou — servidores criados e apagados, deploys, contas conectadas, entradas no sistema. Ela responde à pergunta que só se faz depois.
Só ações são registradas, nunca o que você olhou. Senhas e tokens nunca chegam lá: qualquer coisa com cara de credencial é substituída antes de o registro ser escrito, porque um log de auditoria que junta segredos caladinho é pior que nenhum — é a tabela que ninguém lembra de proteger. Os registros sobrevivem ao que descrevem, então apagar um servidor não apaga o registro de quem o apagou.
docker network create buddy once.