BasicsPipelinesActions & ServicesEnvironmentsIntegrationsTargetsDomainsSandboxesSelf-HostedAgents & TunnelsYAMLBuddy GitFAQAPI

Advanced settings

The Settings tab also will reveal a couple of advanced features that will let you fine-tune your pipeline.

CPU

The CPU option allows you to select the processor architecture for the pipeline, depending on your application’s requirements.

Available options:

  • x86 - The default architecture is Intel/AMD, compatible with most applications
  • ARM64 - The ARM architecture, used for example in mobile devices and ARM containers

Image loading...CPU resource limits

Resources

This option lets you optimize the efficiency of your processes by assigning the resources on the basis of the tasks the pipeline performs:

  • Nano: 2GB / 2vCPU
  • Small: 3GB / 2vCPU
  • Medium: 4GB / 2vCPU
  • Large: 6GB / 2vCPU default
  • XLarge: 8GB / 4vCPU
  • X2Large: 16GB / 4vCPU

Priority

Priority determines how soon a queued pipeline will be triggered. For instance, if there are 4 pipelines in the queue, and you assign High priority to the last one, it will move up the line and be executed once the ongoing execution is completed:

Image loading...Setting priority in pipeline

Tip
The option is useful, e.g. when you have a backup project and a production project running simultaneously. In such cases, it is preferable for the backup project to complete before initiating the deployment to production.

Docker Build Cache scope

The Docker Build Cache optimizes Docker image build times by storing layers between pipeline runs.

Pipeline

The cache is limited to a single pipeline, providing the fastest performance because all operations are local. Use this scope to optimize isolated builds that do not need to share layers with other builds.

Project/Workspace

The cache is shared across all pipelines within the same project or workspace. This option may be slower when building layers, since they must be uploaded to an external cache. Use this scope if multiple pipelines in the same project can benefit from sharing common layers.

Image loading...Docker build cache configuration

Force deploy from scratch

Most of the deployment actions are based on changesets, which means only the files from the latest revision are deployed. Checking 'Force deploy from scratch' will force Buddy to deploy all files from the repository on every execution. If the option is selected, the changeset trigger conditions added in the pipeline won't be taken into account.

Clear cache before execution

The cache stores a clone of the repository and dependencies required by your build, which massively reduces build times. In some cases, however, you may need to fetch the dependencies on every build execution. To do that, select the option 'Erase filesystem, Docker layers & cached container paths on run'. It will force Buddy to download the packages every time the pipeline is run. If the option is selected, the changeset trigger conditions added in the pipeline won't be taken into account.

Skip queued runs for same Git reference

If a user triggers a pipeline that's already in progress, the execution will be queued and won't start until the first one is over. If there are more executions queued (for example 5) and you check 'New run for same Git reference terminates runs in progress', Buddy will only run the newest execution (5th) and skip the rest (2-4).

Image loading...Runtime configuration

Terminate runs in progress for same Git reference

If a user triggers a pipeline that's already in progress, the ongoing execution will be terminated and replaced with the new one.

Execute pipeline runs concurrently

Selecting the option lets you trigger multiple executions of a single pipeline simultaneously. This feature is useful if you want to test every single commit or test multiple branches at the same time.

Hint
The number of concurrent executions/filesystem slots depends on the number of runners available in your plan.

Default description

The default description option lets you define a message that is automatically applied to every pipeline run. You can override this with a custom message when running pipeline manually.

Image loading...Default description setting

Git Changeset Base

The Git Changeset Base option lets you define a branch or commit that serves as the reference point for calculating changes in the pipeline.

Available settings:

  • Last commit
  • Commit matching ref
  • PR base branch

Image loading...Git changeset base configuration

Filesystem Change Detection

Filesystem Change Detection allows you to monitor file changes and automatically trigger pipelines when specified changes are detected in the repository.

Available settings:

  • Date modified
  • File contents

Image loading...Filesystem change detection

Fetch all refs

When the pipeline is run, Buddy fetches only one Git reference to the pipeline filesystem (branch, tag or pull request). Selecting the 'Fetch all refs' option will force Buddy to fetch all Git references.

Image loading...Get/Fetch configuration

Shallow Clone depth

The clone depth specifies how many commits should be cloned to the filesystem on the pipeline execution. Creating a shallow clone is useful if your .git/ directory occupies too much space.

Image loading...Shallow clone depth settings

Quick Link

The Quick Link puts a label on your pipeline that lets you promptly access the associated website, e.g. to review changes after a deployment.

Image loading...Setting quick link

Pause pipeline on repeated failures

This option automatically pauses a pipeline after a defined number of consecutive failed runs. By default, pipelines are paused after 100 consecutive failures.

Image loading...Pause pipeline on repeated failures

Status

The Status option controls a pipeline’s visibility and activity, both on the project dashboard and across the entire workspace.

Available options:

  • Ignore pipeline status on project's dashboard - hides the pipeline status on the project's dashboard
  • Turn off this pipeline - disables the pipeline, preventing it from being run

Image loading...Pipeline status settings

Trigger condition

Usually, your application is first built and then deployed to the server. However, not every change in the repository requires a build. In such cases, The Run if tab is the place to go to define certain conditions that will trigger the build.

Image loading...Setting trigger conditions

Definition location

The Definition Location option allows you to store the pipeline configuration directly in a Git repository. This enables version control for pipeline definitions, improving transparency and management of deployments.

Image loading...Create a new pipeline with an option to store the configuration in a Git repository

If a pipeline has already been created, its definition location can be modified in the settings. Simply select the Definition location option from the context menu and adjust the configuration.

Image loading...Change definition location in an existing pipeline via the settings menu

In the edit panel, you can enable the option to store the pipeline definition in a Git repository. Once saved, the pipeline will use the versioned configuration stored in the repository, making management and auditing easier.

Image loading...Modify the pipeline definition location to store the configuration in a Git repository

When enabling the Definition Location, you need to specify:

  • Project – the repository where the pipeline configuration is stored.
  • Branch – the branch containing the configuration file.
  • YAML Path – the exact location of the .yml file defining the pipeline.

Additional modules managed using YAML definition:

  • Variables - Environment variables available to the pipeline
  • Permissions - Pipeline access permissions

Image loading...Configure pipeline definition location with project, branch, and YAML path

If the YAML filename contains .fixed (e.g., Frontend.fixed.yml), Buddy will apply the configuration from the initial branch across all branches listed in the codescope. The "initial branch" refers to the branch where the definition was first introduced.

Hint
When storing YAML files in the /.buddy/ directory, you must use the .fixed.yaml or .fixed.yml extension. For more details, see Autodiscovery YAML.

Storing configuration in a Git repository

When stored in a repo, you choose between:

  • Fixed branch: Pipeline always uses the YAML from a specific branch (like main), regardless of where code is pushed.
  • Dynamic branch: Buddy picks up the YAML from the same branch or PR/tag being pushed, based on its ref.

Definition Variables in YAML

Created variables are also saved in the pipeline configuration YAML:

yaml
variables:
- key: my_var
  value: '!encrypted f+ZkJjNjprzRy5sXz2SUxA==.cxBjMsZkmVHiqR4A3zpXJg=='
  type: VAR
  encrypted: true
  settable: ENABLED

Definition Permissions in YAML

Permissions set in the pipeline are also saved in the YAML pipeline configuration:

yaml
permissions:
  others: DEFAULT
  users:
    john.doe@example.com: READ_WRITE
    jane.smith@example.com: READ_WRITE

Visibility & permissions

The Permissions tab in the pipeline settings allows you to restrict pipeline's visibility and scope of operations to individual users and groups.

Image loading...Permission settings

The permissions can be restricted to the following built-in roles:

  • None (Deny) – the user cannot see the pipeline in the project at all
  • Project role – the permission defined in the role with which the user was assigned to the project (default)
  • View-only – the user can browse the pipeline but cannot run or modify its settings
  • Run-only – the user can run the pipeline, but cannot modify its settings
  • Manage – the user can run and modify the pipeline, just like with the Developer role

Last modified on Oct 21, 2025

Previous pageAnalyticsNext pageFilesystem cache