Integrations let you define and re-apply access data to third-party services in Buddy's pipelines. For example, adding an AWS integration will allow you to upload assets to S3 buckets, deploy ElasticBeanstalk apps, invalidate Cloudfront cache, or run commands in the AWS CLI.

Defining integrations

Whenever you add an action that requires connecting to a third-party service, Buddy will ask you to create an integration. Depending on the type of the integration, you may need to fill a form with the access data (e.g. access and secret keys), or authenticate Buddy in the external service with OAuth (e.g. when connecting to GitHub).

Adding AWS integration

Multiple integrations for one service

You can have multiple integrations of one type in your workspace. For example, you can use several AWS integrations and deploy to different accounts within the same project. There are two ways to add extra integrations.

  1. From the account selection dropdown of the action using the integration:

Adding a new integration from an action

  1. By clicking the +Add a new integration button in the Integrations tab.

Adding a new integration from the Integrations tab


When adding an integration you can define its scope, i.e. who is permitted to define new actions with the access data it contains. By default, every integration is added with the PRIVATE scope, which restricts these permissions to the integration's owner.

The scope describes who can use the integration to define new actions and edit actions that use an existing integration

The scope does not describe who can trigger the actions that use the integration. For example, if you define an S3 deployment with a private scope, all users with permissions to run the pipeline will be able to upload files to the defined S3 bucket. However, only the user who has added the integration will be able to edit its details (e.g. change the deployment bucket in the S3 action).

Types of scopes

There are four types of integration scopes. Each scope defines who can add and edit actions using the integration:

  1. Private – restricted to the owner of the integration.
  2. Everyone – restricted to the members of the workspace in which the integration was defined. The scope can be further limited to a specific project (recommended for YAML configuration).
  3. Administrators – restricted to the admins of the workspace in which the integration was defined. The scope can be further limited to a specific project.
  4. Administrators + Group – restricted to admins and a selected group of users in the workspace in which the integration was defined. The scope can be further limited to a specific project (for example, back-end developers in a back-end project).

You can further restrict who can define, edit, and trigger pipelines using custom permissions.

Managing integrations

All integrations can be managed in the Integrations tab on the left sidebar ($DOMAIN/workspace/integrations). There you can add and remove integrations and edit their details: name, access data, and scope.

Integration management screen

You can remove an integration at any time. However, IT IS NOT possible to remove an integration used by an action in the pipeline. If you try to delete such integration, you will be notified where exactly it is used. Once you remove the action or assign it to a different integration, you will be able to safely delete the parent integration.

Integrations in YAML

If you manage your pipelines with YAML, make sure to provide the ID of the integration to the actions that are using it. Here's an example:

- action: "Upload files to AWS S3"
type: "AMAZON_S3"
input_type: "BUILD_ARTIFACTS"
bucket_name: "buddy-tests-files"
acl: "PRIVATE"
integration_hash: "5e391f5aae784b7208de0d0a"

A good idea is to first define all pipelines in the UI and then export them to YAML, or use the YAML helper to generate configuration code for individual actions.

ID hash

You can find the ID on the integration's tile in the Integrations tab:

ID hash of an AWS integration