Recursos

Tudo o que o DevOps Buddy faz hoje — e o que vem a seguir.

Deploy

• Deploys via Git com Nixpacks — aponte para um repositório no Bitbucket, GitHub, GitLab ou no seu próprio servidor, público ou privado (qualquer branch); o agente clona e compila na sua VM. PHP com composer, Node.js, Python, Go, Ruby, Rust, Java e outros são detectados automaticamente — sem precisar de Dockerfile.
• Deploys via docker-compose — cole qualquer arquivo compose. Aplicações com vários serviços, bancos, filas, workers: se roda em Docker, vai para o ar. O Buddy injeta os labels e as redes de ingress na hora do deploy, sem alterar o seu arquivo.
• Cópias de staging — um clique duplica uma aplicação (código, variáveis, configuração de domínio) sob um subdomínio -staging , para você testar antes de mexer em produção.
• Deploy no push — ligue e o Buddy te dá uma URL de webhook e um segredo para o seu repositório. Todo push na branch que a aplicação acompanha dispara um deploy; pushes em outras branches são ignorados. Pushes do GitHub e do GitLab são conferidos por assinatura, então só o seu servidor de código consegue disparar um deploy.
• Aplicações prontas — WordPress, Drupal, Joomla, Nextcloud e Magento vão para o ar nos dois tipos de servidor, cada um com banco de dados e HTTPS já configurados. O Buddy também roda o instalador, então você chega num site funcionando com conta de administrador em vez de um assistente de instalação — e refazer o deploy é seguro: a instalação para assim que percebe que a aplicação já existe.
• Deploy, restart, parada e logs — ciclo de vida completo pelo painel, executado pelo agente em segundos.

Rede & TLS

• HTTPS automático — o Traefik termina o TLS em cada VM com certificados Let's Encrypt, emitidos e renovados automaticamente.
• DNS gerenciado — conecte um token de API da Cloudflare e o Buddy cria ou atualiza os registros A dos domínios das suas aplicações, apontando para a VM certa.
• Várias aplicações por VM — cada aplicação entra numa rede de ingress compartilhada; o Traefik roteia por nome de host, então uma VM barata atende vários sites.

Provisionamento

• Amazon Web Services, DigitalOcean, Google Cloud e Vultr — adicione um token de API (ou uma chave de service account do GCP, ou uma access key da AWS), escolha região, tamanho e versão LTS do Ubuntu, e o Buddy cria a VM para você. A lista de imagens é lida da sua própria conta, então imagens descontinuadas nunca quebram um deploy. Na AWS isso significa uma instância EC2 com disco raiz gp3 de 30 GB e um security group abrindo apenas SSH e as duas portas web. Azure está no roadmap.
• Bloqueio de força bruta — toda página de login tem limite de tentativas, e uma chave na página de Firewall bane os endereços que insistem em tropeçar nele, em errar no SSH ou em vasculhar arquivos que você não tem. Os banimentos valem só para as portas envolvidas, então nunca custam o seu SSH.
• Backups no seu próprio bucket — Google Cloud Storage ou Amazon S3, o que você tiver conectado. O Buddy assina uma URL que expira; o servidor envia direto para ela e nunca guarda uma chave de cloud.
• Bancos de dados gerenciados — Cloud SQL pela API do Google, e Amazon RDS por meio de um servidor seu, porque a AWS não oferece API capaz de criar um banco ou um login dentro de uma instância.
• Dois tipos de servidor — servidores de container rodam tudo em Docker atrás do Traefik; servidores clássicos são máquinas Ubuntu limpas onde o Buddy instala nginx, PHP-FPM e o MariaDB ou o Oracle MySQL 8 que você escolher, para quem quer um VPS comum onde possa entrar por SSH.
• Use um servidor que você já tem — um curl | bash instala o agente em qualquer servidor Debian/Ubuntu que você já tenha, onde quer que ele esteja.
• Agente só de saída — um único binário Go de ~5 MB que consulta por HTTPS. Sem chaves SSH para compartilhar, sem portas de gerenciamento abertas, com tokens por servidor que você pode revogar.
• Atualizações de segurança automáticas — toda VM criada pelo Buddy instala as próprias correções de segurança, restritas ao repositório de segurança e sem se reiniciar sozinha.

Administrando a máquina

• Proteção por senha em cada site — coloque usuário e senha na frente de um site inteiro com um clique. Cópias de staging ganham isso automaticamente: sem essa proteção, a cópia de um site no ar é uma segunda cópia dele, não anunciada, na internet pública. O Let's Encrypt passa livre, para os certificados continuarem renovando.
• Registro de atividade — quem criou aquele servidor, quem fez o deploy, quem conectou uma conta, e de qual endereço. As credenciais são removidas antes de o registro ser escrito, e os registros sobrevivem às coisas a que se referem.
• Sites endurecidos por padrão — todo site em servidor clássico recebe cabeçalhos de segurança em toda resposta, PHP recusado dentro dos diretórios de upload e 403 para os arquivos que os scanners pedem (.env, .git, dumps de banco de dados, .bak). No WordPress, ainda são bloqueados o xmlrpc.php e há limite de tentativas em wp-login.php , 20 por minuto por endereço; o Nextcloud mantém os arquivos dos usuários fora da raiz web. Nada a ligar, e a configuração é reescrita a cada deploy, então não tem como sair do lugar.
• Firewall — libere uma porta para todo mundo ou para uma rede só, numa página só, em todos os seus servidores. Aplicado com iptables em duas chains, então cobre também os containers — o Docker publica portas contornando a chain usual. SSH, loopback e ping nunca são bloqueados.
• Tarefas agendadas — comandos agendados por servidor, com horário, usuário e comando escritos por extenso. O Buddy é dono de um arquivo só e o reescreve inteiro; a sua crontab nunca é tocada.
• Workers — processos de fundo de longa duração (uma fila do Laravel, um consumidor) executados pelo systemd: reiniciados quando terminam, ligados de novo após um reboot e parados com SIGTERM para concluírem o trabalho em andamento. Vários processos por worker, se você precisar.
• Chaves SSH salvas e scripts de inicialização — guarde suas chaves públicas e um script seu, e escolha-os na hora de criar um servidor. O script roda uma vez como root depois que o Buddy termina de preparar a máquina, com a saída no registro de atividade — e não pelo cloud-init, onde um erro deixa um servidor que nunca aparece e um motivo que ninguém alcança.
• Acessos SSH — dê a cada pessoa uma conta própria no servidor, só com chave, em vez de compartilhar o root, com sudo sem senha se quiser. Remover alguém leva junto a conta e o diretório pessoal, e não mexe com mais ninguém.

Dados

• MariaDB ou Oracle MySQL 8 — servidores clássicos instalam o que você escolheu, e o Buddy cria um banco e um usuário restrito para cada aplicação.
• Cloud SQL — uma aplicação pode usar uma instância MySQL gerenciada no seu próprio projeto do Google Cloud em vez do banco na VM. O Buddy cria o schema, um usuário restrito a ele e a regra de rede; a instância continua sua, e o Buddy nunca cria nem redimensiona uma.
• Backups na sua cloud — os dados da aplicação vão para um bucket no seu próprio projeto (hoje GCS). As transferências usam URLs pré-assinadas de vida curta, então as credenciais de armazenamento nunca chegam à VM.
• Restauração em um clique — escolha qualquer snapshot; o agente para a aplicação, restaura os dados e a coloca no ar de novo.
• Veja o que existe de verdade — a página de Bancos de dados lê os schemas, o tamanho e a quantidade de tabelas de cada um, e os logins que existem em cada servidor, ao lado das suas instâncias Cloud SQL e das aplicações que as usam.

Observabilidade

• Métricas de servidor — CPU, memória e disco por VM, atualizados a cada 20 segundos pelo sinal do agente.
• Métricas por aplicação — CPU e memória dos containers somados por aplicação, visíveis na lista e na página de detalhe.
• Histórico de comandos — cada deploy, restart e backup com stdout, stderr e código de saída guardados para auditoria.
• Integração opcional com Zabbix — registre automaticamente cada VM como host no Zabbix, com o seu template e o seu grupo de hosts.

Segurança

• Autenticação em dois fatores — TOTP com qualquer app autenticador, mais códigos de recuperação de uso único para o dia em que o celular sumir.
• Credenciais criptografadas — tokens e chaves de cloud ficam criptografados em repouso; o painel de controle só os descriptografa para executar as operações que você dispara.
• Tokens de repositório ficam fora do seu histórico de deploy — um token do Bitbucket ou do GitHub nunca é gravado junto da aplicação nem na fila de trabalhos. A URL de clone é montada quando o seu servidor pede a tarefa, e as credenciais são removidas dos logs de build antes de serem guardadas.
• Isolamento — cada aplicação é um projeto compose próprio, com containers próprios; nada compartilha runtime.

No roadmap

• Logs ao vivo · deploys sem downtime · times & acesso por papéis · registro de auditoria · provisionamento na AWS & Azure · destinos de backup compatíveis com S3 · mais aplicações de um clique (Ghost, n8n, Plausible) · cobrança por uso (por servidor + por aplicação, por hora).

Comece de graça Ler a documentação