Buddy

How does Buddy work?

Buddy is built around pipelines made of actions. A pipeline is a sequence of steps - build, test, deploy, notify - that runs in response to a trigger (a push, a schedule, a manual click, an API call). Each step is an action: a predefined, configurable block such as "Build Docker Image", "Amazon S3", "SSH" or "Slack". There are around 158 actions across 22 categories, plus fully custom shell actions for anything that is not covered.

The model has a few defining properties:

1. Hybrid configuration. A pipeline can be assembled visually in the UI or written as YAML in a .buddy/buddy.yml file committed to the repo. The two representations describe the same pipeline, so a team can start by clicking and later move to Infrastructure as Code without rebuilding anything.
2. Reusable connections (targets). Servers, cloud buckets, databases, Kubernetes clusters and git remotes are defined once as targets and referenced by many pipelines, instead of pasting credentials into every action.
3. More than CI/CD. The same platform provisions environments (per branch, per PR, with a URL each), hosts apps on MicroVMs and static sites (Dev Cloud), registers and manages domains and DNS, opens secure tunnels into private networks, hosts git repositories, and spins up Ubuntu sandboxes with HTTP/TCP/TLS endpoints.
4. Everything is also an API. Pipelines, actions, executions, environments, targets, variables, domains, sandboxes, tunnels and artifacts are all reachable over a REST API (OAuth2, OpenAPI 3.0), the bdy CLI and a Terraform provider.

The result is that the path from a commit to a running, reachable application - build, deploy, host, route a domain, expose an environment - can live entirely inside one platform rather than being stitched together from separate services.

Why does Buddy matter?

Buddy exists to collapse the tool sprawl that surrounds modern delivery.

• One platform instead of a toolchain. A typical delivery setup glues a CI runner to a registry, a hosting provider, a DNS provider, a tunneling tool and a secrets manager. Buddy folds those into co-equal pillars, so the pipeline that builds your app is the same place that hosts it, points a domain at it and exposes a preview environment.
• Fast to configure. The visual builder lowers the barrier for teams that do not want to learn a CI DSL first, while the YAML representation keeps the door open for full Infrastructure as Code. The hybrid model means neither audience is locked out.
• Hosting and networking are first-class. Because Dev Cloud (MicroVM hosting), domains/DNS and tunnels are built in, "deploy" can mean "the app is live on a URL" without a second vendor.
• Enterprise and compliance ready. SOC 2 compliance, a self-hosted Docker-based Enterprise edition, SSO (SAML/OIDC/LDAP), secrets encryption and RBAC make it viable for regulated and on-premises environments.

The trade-off of an all-in-one platform is breadth versus best-of-breed depth: a team that has already standardised heavily on, say, a dedicated artifact platform or a specific hosting provider may not need every pillar. The value of Buddy is highest for teams that would otherwise assemble and maintain that toolchain themselves.

Buddy vs Jenkins vs GitHub Actions

These three are easy to line up against each other because all run pipelines, but they answer different questions.

• Jenkins - "a self-managed, infinitely extensible automation server." Maximum flexibility through plugins, but you operate the server, secure it and wire up hosting, DNS and deployment yourself. Hosting and networking are entirely out of scope.
• GitHub Actions - "CI/CD that lives next to your GitHub repo." Excellent when your world is GitHub-native; deployment targets, hosting and domains are someone else's product, reached via marketplace actions.
• Buddy - "build, deploy, host and route on one platform." CI/CD is one of about nine pillars; the differentiator is that the target, the environment, the domain and the host are part of the same product, configurable by UI or YAML.

A team can absolutely run delivery without Buddy by composing point tools. What Buddy offers is that the composition - pipeline plus target plus environment plus domain plus host - is already a single, coherent system rather than an integration project. Buddy publishes side-by-side comparisons for the Jenkins, GitLab CI, CircleCI and Travis CI migration paths.

What can you build with Buddy?

Buddy spans the full delivery surface, not just the build step:

• CI/CD pipelines - build, test and deploy with matrices, caching (Docker/filesystem/build), OIDC and secrets.
• Remote deployments - push to thousands of targets across multi-cloud, VPS, bare-metal and CDN, agent or agentless, with rollback and RBAC.
• Environments - provision per branch, per PR, or for dev/demo, each with its own URL.
• Dev Cloud - host apps on MicroVMs and static sites straight from a pipeline, with atomic deploys and autoscaling.
• Domains and DNS - register or transfer domains, manage Anycast DNS across three clouds, SSL, DMARC and DNSSEC.
• Tunnels and sandboxes - secure access into private networks, and isolated Ubuntu staging VMs with HTTP/TCP/TLS endpoints.
• Accelerated GitHub runners - faster, cheaper x86/ARM/M2 runners for existing GitHub Actions workflows.

Explore the full actions catalog (158 actions across 22 categories) or the REST API and bdy CLI for programmatic control.

Example

This Buddy pipeline builds a Node.js app on every push to main, transfers the build artifacts to a server, and notifies Slack only when the run succeeds. The server connection is declared once as a reusable target at the pipeline level, and the transfer action points at it by name. The same pipeline can be edited visually in the UI - the YAML below is just its Infrastructure as Code representation.

# .buddy/buddy.yml - build, transfer to a server, notify
- pipeline: "Deploy production"
  refs:
    - "refs/heads/main"
  # Reusable connection: defined once, referenced by name in actions below
  targets:
    - target: "production_server"
      type: "FTP"
      secure: true
      name: "Production server"
      host: "example.com"
      auth:
        username: "deploy-user"
        password: "$BUDDY_FTP_PASSWORD"
      path: "/var/www/app"
  actions:
    - action: "Build & minify"
      type: "BUILD"
      shell: "BASH"
      docker_image_name: "library/node"
      docker_image_tag: "24"
      commands: |-
        npm ci
        npm run build

    - action: "Transfer files"
      type: "TRANSFER"
      input_type: "BUILD_ARTIFACTS"
      local_path: "/"
      deployment_excludes:
        - "node_modules/"
        - ".DS_Store"
      targets:
        - "production_server"

    - action: "Notify Slack"
      type: "SLACK"
      integration: "your-slack-integration"
      channel: "#deploys"
      content: "Deployed $BUDDY_PROJECT_NAME @ $BUDDY_EXECUTION_REVISION"
      trigger_time: "ON_SUCCESS"

If the build fails, the transfer never runs and Slack is not notified. If everything passes, the build artifacts are pushed to the target and the team is told - build, deployment and notification on one platform, described in one file. See the YAML reference and targets docs for the full schema.