SUDS for Hosting‑Agnostic Drupal Workflow Orchestration

Acquia discontinued the Build & Launch Tool (BLT) in September 2024. For years, BLT gave Drupal teams a shared answer to a basic operational question about how developers and CI pipelines could run the same orchestration tasks, the same way, on every project. Nearly two years later, that question still doesn't have a widely adopted answer.

The guidance that followed pointed teams toward a combination of tools, including GrumPHP for validation, Drush for CLI operations, and Acquia Cloud Actions for the rest.

Each of those is a fine tool on its own. They still do not fully replace the opinionated, project-agnostic workflow BLT provided, which tied syncing, updating, and deploying together under a single command set. In practice, most teams have filled that gap with a patchwork of custom scripts, copied and pasted, reconfigured, and often re-debugged on every new project.

SUDS, short for Sync. Update. Deploy. Suite, is our answer to that gap. It is an open-source Drush plugin, published under the Bounteous GitHub organization, and built to carry forward the workflow consistency BLT once provided. Our broader Drupal development work follows the same focus on scalable, maintainable digital platforms.

How SUDS Orchestrates Drupal Workflows

SUDS is an opinionated orchestrator for Drupal development workflows, built as Drush commands and inspired directly by BLT's core idea. Unlike BLT, it makes exactly one assumption, that you are working with a Drupal site. It isn't tied to any hosting platform.

Three workflows form the core of SUDS:

Local Development Sync (drush suds:sync)

pulls a database from a configured source environment, installs Composer dependencies, sanitizes PII, optionally syncs managed files, and applies pending updates in one command. A new developer gets a working local environment in a single step; existing developers stay current the same way.

Artifact Deployment (drush suds:deploy)

assembles a clean, production-ready build artifact via rsync, runs your configured build steps, commits, and force-pushes to a deployment repository. Hosting platforms that deploy from git get an artifact with only what production needs — no dev tooling, no test files, no local config.

Environment Update (drush suds:update)

rebuilds caches, runs database updates, and imports configuration, so a deploy is actually live once it lands.

All three workflows are driven by a single suds.yml file, committed to the repository, so the workflow definition travels with the project instead of living in someone's head or a wiki page.

Getting Started With SUDS

composer require bounteous-inc/suds

drush suds:init # creates suds.yml and prompts for a project name

drush suds:doctor # verifies the environment is correctly configured

From there, every developer and every CI pipeline runs the same commands, regardless of which project they're in.

drush suds:sync gets or refreshes a local environment

drush suds:deploy builds and pushes a production artifact

drush suds:update applies the deployment to the target environment by rebuilding caches, running DB updates, and importing configuration.

Quality Checks and Pipeline Setup

suds:scaffold:quality generates GrumPHP, PHPCS, and PHPStan configuration pre-tuned for Drupal.

suds:scaffold:ci — writes a minimal GitHub Actions, GitLab CI, or Bitbucket Pipelines configuration.

suds:doctor — validates that a project's environment, configuration, and tooling are wired up correctly, making it useful for onboarding a new team member or diagnosing a stale setup.

Scaffolded files are opinionated starting points, not black boxes. Once scaffolded, the project owns the files and can alter or extend them as needed.

Why We Are Open-Sourcing SUDS

SUDS started as an answer to a frustration on our own Drupal projects where teams were solving the same post-BLT workflow gap with project-specific scripts that had to be copied, reconfigured, and often re-debugged across projects. Once it was solid enough to depend on internally, we saw an opportunity to make it useful to other Drupal teams facing the same workflow gap. The challenge is not unique to one team or one codebase.

At Bounteous, our Drupal work has long been shaped by a practical open-source mindset, where repeated delivery patterns become opportunities to build reusable tooling that helps teams move with more consistency and less reinvention. That same approach can be seen in our work on self-documenting Composer patch management.

Many Drupal teams we know have been solving some version of this problem project by project, often with custom automation that works locally but does not always travel cleanly across teams or environments.

Open sourcing SUDS gives those teams a practical starting point instead of another one-off script, while giving the tool a broader community of users who can test it across real workflows, surface edge cases, and contribute improvements over time.

Take SUDS In Your Project

The easiest way to know if SUDS fits your workflow is to install it with composer require bounteous-inc/suds and point it at a real project. If something does not fit your workflow, or if you have a migration story from BLT worth telling, open an issue. If you would rather fix it yourself, pull requests are welcome and the contribution guide is available in the repo.

SUDS is GPLv2+ licensed, requires PHP 8.3+, Drush 13+, and Drupal 10.4+.

You can find the project on GitHub and Packagist.

GitHub

github.com/Bounteous-Inc/suds

Packagist

packagist.org/packages/bounteous-inc/suds