Skip to content

Work from the terminal

Everything you do on Cloud Platform without leaving the terminal, built on acli. Start with the quickstart, then pick the everyday job you need. Automation that has to go below acli, to the REST API it wraps, starts at call the Cloud Platform API.

Acquia development touches several CLIs with adjacent-sounding jobs. The most common confusion: acli manages the Cloud Platform but does not manage Pipelines: Pipelines has its own, separate client.

Tool What it manages What it explicitly does not Start here
acli Cloud Platform: applications, environments, logs, database/file pulls, artifact deploys, SSH keys, Cloud IDEs, and 450+ Cloud Platform API endpoints via acli api:* Pipelines (use the Pipelines CLI; acli does not integrate with Pipelines); Drupal itself (acli does not manage or integrate with Drupal directly; it can only invoke drush remotely) CLI quickstart · reference
Pipelines CLI (pipelines) Pipelines jobs: configure credentials, start jobs, associate a repository with an application (pipelines start, pipelines list-applications, pipelines set-application-id) Everything else on the Cloud Platform; it is a separate tool from acli, installed and authenticated separately Pipelines quickstart · build definition file on docs.acquia.com
glab / gh Repo, merge-request, and CI operations against Code Studio (glab auth login --hostname=code.acquia.com) or GitHub (gh) Cloud Platform resources (environments, databases, logs: that’s acli); the Code Studio ↔ Cloud Platform wiring itself, which acli codestudio:wizard sets up CI/CD section
drush Drupal-specific operations on an installed site: cache, configuration, users, one-off maintenance. Installed per-project as a Composer dependency (./vendor/bin/drush, adding it with composer require drush/drush if missing), never a global tool Hosting and platform concerns (environments, deploys, backups). Skip the local install entirely by running it on an environment with acli remote:drush, or see drush.org Run Drush remotely
acms Drupal Starter Kit scaffolding inside a Drupal project: ./vendor/bin/acms acms:install, or split acms:build + site:install Hosting, deploys, or anything outside project scaffolding Drupal Starter Kits docs
@drupal-canvas/cli Drupal Canvas component operations: pull and push components against a site (npm install @drupal-canvas/cli -g), authenticated by an API client with the canvas:asset_library and canvas:js_component scopes Page content, hosting, and everything outside Canvas components Canvas CLI reference

The common boundary cases:

  • “Can acli drive a Pipelines build?” No, and acli pipelines … fails with Command "pipelines" is not defined. because acli has no such command. Install the separate pipelines client (curl -o pipelines https://cloud.acquia.com/pipeline-client/download, chmod a+x pipelines, move it into your PATH), configure it with pipelines configure, and authenticate it with its own Cloud Platform API token. Its job definitions live in acquia-pipelines.yaml (Creating and managing your build definition file on docs.acquia.com). (The one crossover: acli codestudio:pipelines-migrate converts an acquia-pipelines.yaml to a Code Studio .gitlab-ci.yml for teams moving to Code Studio; it is not a way to run Pipelines.)
  • “Deploy a frontend” vs. “scaffold a Canvas component”: deploying goes through your own CI/CD or acli push:artifact; Canvas components go through @drupal-canvas/cli.
  • When two tools seem to overlap, the split is almost always platform vs. what runs on it: acli for the platform, drush/acms/@drupal-canvas/cli for the application, glab/gh/Pipelines CLI for the automation around it.

Was this page helpful?