Features

Everything DevOps Buddy does today — and what's next.

Deploy

• Git deploys with Nixpacks — point at a repository on Bitbucket, GitHub, GitLab or your own server, public or private (any branch); the agent clones and builds it on your VM. PHP with composer, Node.js, Python, Go, Ruby, Rust, Java and more are detected automatically — no Dockerfile required.
• docker-compose deploys — paste any compose file. Multi-service apps, databases, queues, workers: if it runs in Docker, it deploys. Buddy injects ingress labels and networks at deploy time without touching your file.
• Staging clones — one click duplicates an app (code, env, domain config) under a -staging subdomain so you can test before touching production.
• Push to deploy — turn it on and Buddy gives you a webhook URL and a secret for your repository. Every push to the branch the app tracks deploys it; pushes to other branches are ignored. GitHub and GitLab pushes are checked against a signature, so only your forge can trigger a deploy.
• Ready-made apps — WordPress, Drupal, Joomla, Nextcloud and Magento deploy on either kind of server, each with its database and HTTPS already wired up. Buddy runs the installer too, so you land on a working site with an admin account rather than a setup wizard, and redeploying is safe: the install stops as soon as it sees the app is already there.
• Deploy, restart, stop, logs — full lifecycle from the dashboard, executed by the agent in seconds.

Networking & TLS

• Automatic HTTPS — Traefik terminates TLS on every VM with Let's Encrypt certificates, issued and renewed automatically.
• Managed DNS — connect a Cloudflare API token and Buddy upserts the A records for your app domains, pointed at the right VM.
• Many apps per VM — every app joins a shared ingress network; Traefik routes by hostname, so one cheap VM can serve many sites.

Provisioning

• Amazon Web Services, DigitalOcean, Google Cloud and Vultr — add an API token (or a GCP service-account key, or an AWS access key), pick region, size and Ubuntu LTS release, and Buddy creates the VM for you. The image list is read from your own account, so retired images never break a deploy. On AWS that means an EC2 instance with a 30 GB gp3 root disk and a security group opening only SSH and the two web ports. Azure is on the roadmap.
• Brute-force blocking — every login page sits behind a rate limit, and a switch on the Firewall page bans the addresses that keep tripping it, keep failing SSH, or keep scanning for files you do not have. Bans are scoped to the ports involved, so they can never cost you SSH.
• Backups to your own bucket — Google Cloud Storage or Amazon S3, whichever you have connected. Buddy signs a URL that expires; the server uploads straight to it and never holds a cloud key.
• Managed databases — Cloud SQL through Google's API, and Amazon RDS through one of your own servers, because AWS offers no API that can create a database or a login inside an instance.
• Two kinds of server — container servers run everything in Docker behind Traefik; classic servers are clean Ubuntu boxes where Buddy installs nginx, PHP-FPM and your choice of MariaDB or Oracle MySQL 8 on demand, for people who want a plain VPS they can SSH into.
• Use a server you already have — one curl | bash installs the agent on any Debian/Ubuntu server you already run, wherever it is.
• Outbound-only agent — a single ~5 MB Go binary that polls over HTTPS. No SSH keys to share, no open management ports, per-server tokens you can revoke.
• Automatic security updates — every VM Buddy creates installs security patches on its own, restricted to the security pocket and without rebooting itself.

Running the machine

• Password protection per site — put a username and password in front of a whole site in one click. Staging clones get one automatically: a copy of a live site is otherwise a second, unannounced copy of it on the public internet. Let's Encrypt is let through, so certificates keep renewing.
• Activity log — who created that server, who deployed, who connected an account, with the address they did it from. Credentials are stripped before an entry is written, and entries outlive the things they refer to.
• Sites hardened by default — every classic-server site gets security headers on every response, PHP refused inside upload directories, and 403 for the files scanners ask for (.env, .git, database dumps, .bak). WordPress additionally blocks xmlrpc.php and rate-limits wp-login.php to 20 attempts a minute per address; Nextcloud keeps its users' files outside the web root. Nothing to switch on, and the configuration is rewritten on every deploy so it cannot drift.
• Firewall — allow a port from everywhere or from one network, on one page across all your servers. Applied with iptables in two chains, so it covers containers too — Docker publishes ports around the usual one. SSH, loopback and ping are never blocked.
• Cron jobs — scheduled commands per server, with the schedule, the user and the command spelled out. Buddy owns one file and rewrites it whole; your own crontab is never touched.
• Workers — long-running background processes (a Laravel queue, a consumer) run by systemd: restarted when they exit, started again after a reboot, and stopped with SIGTERM so they finish the job in hand. Several processes per worker if you need them.
• Saved SSH keys and startup scripts — keep your public keys and a script of your own, and pick them when you create a server. The script runs once as root after Buddy has finished setting the machine up, with its output in the activity log — not from cloud-init, where a mistake leaves a server that never appears and a reason nobody can reach.
• SSH logins — give each person their own key-only account on a server instead of sharing root, with optional passwordless sudo. Removing someone takes their account and home directory with it and leaves everyone else alone.

Data

• MariaDB or Oracle MySQL 8 — classic servers install whichever you picked, and Buddy creates a database and a scoped user per app.
• Cloud SQL — an app can use a managed MySQL instance in your own Google Cloud project instead of the database on the VM. Buddy creates the schema, a user scoped to it and the network rule; the instance stays yours and Buddy never creates or resizes one.
• Backups to your cloud — app data is archived to a bucket in your own project (GCS today). Transfers use short-lived pre-signed URLs, so storage credentials never reach the VM.
• 1-click restore — pick any snapshot; the agent stops the app, restores the data and brings it back up.
• See what is really there — the Databases page reads the schemas, their size and table count, and the logins that exist on each server, next to your Cloud SQL instances and the apps using them.

Observability

• Server metrics — CPU, memory and disk per VM, refreshed every 20 seconds by the agent heartbeat.
• Per-app metrics — container CPU/memory aggregated per app, visible in the app list and detail pages.
• Command history — every deploy/restart/backup with stdout, stderr and exit codes kept for auditing.
• Optional Zabbix integration — auto-register every VM as a Zabbix host with your template and host group.

Security

• Two-factor authentication — TOTP with any authenticator app, plus one-time recovery codes for the day the phone is gone.
• Encrypted credentials — cloud tokens and keys are encrypted at rest; the control plane decrypts them only to execute the operations you trigger.
• Repository tokens stay out of your deploy history — a Bitbucket or GitHub token is never written next to the app or into the job queue. The clone URL is assembled when your server asks for the work, and credentials are stripped from build logs before they are stored.
• Isolation — every app is its own compose project with its own containers; nothing shares a runtime.

On the roadmap

• Streaming logs · zero-downtime deploys · teams & role-based access · audit log · AWS & Azure provisioning · S3-compatible backup targets · more one-click apps (Ghost, n8n, Plausible) · usage-based billing (per server + per app, hourly).

Start free Read the docs