# Work from the terminal

Everything you do on Cloud Platform without leaving the terminal, built on [acli](/start-here/glossary/#acli). Start with the [quickstart](/cloud-platform/cli/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](/cloud-platform/cli/platform-api/).

## Which CLI do I use?

Acquia development touches several CLIs with adjacent-sounding jobs. The most common confusion: `acli` manages the Cloud Platform but **does not manage [Pipelines](/start-here/glossary/#pipelines)**: Pipelines has its own, separate client.

| Tool | What it manages | What it explicitly does not | Start here |
| --- | --- | --- | --- |
| `acli` | Cloud Platform: [applications](/start-here/glossary/#application-cloud-platform), [environments](/start-here/glossary/#environment), logs, database/file pulls, artifact deploys, SSH keys, [Cloud IDEs](/start-here/glossary/#cloud-ide), 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](/cloud-platform/cli/quickstart/) · [reference](/cloud-platform/reference/acli/) |
| Pipelines CLI (`pipelines`) | [Pipelines](/start-here/glossary/#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](/cloud-platform/ci-cd/quickstart/) · [build definition file](https://docs.acquia.com/acquia-cloud-platform/creating-and-managing-your-build-definition-file) on docs.acquia.com |
| [`glab`](https://gitlab.com/gitlab-org/cli) / [`gh`](https://cli.github.com/) | Repo, merge-request, and CI operations against [Code Studio](/start-here/glossary/#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`](/cloud-platform/reference/acli/#codestudiowizard) sets up | [CI/CD section](/cloud-platform/ci-cd/) |
| `drush` | Drupal-specific operations on an installed site: cache, configuration, users, one-off maintenance. Installed per-project as a [Composer](/start-here/glossary/#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`](/cloud-platform/reference/acli/#remotedrush), or see [drush.org](https://www.drush.org/) | [Run Drush remotely](/cloud-platform/cli/everyday-workflows/#run-drush-remotely-or-open-a-shell) |
| `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](https://docs.acquia.com/drupal-starter-kits) |
| `@drupal-canvas/cli` | [Drupal Canvas](/start-here/glossary/#drupal-canvas) [component](/start-here/glossary/#component) operations: pull and push components against a site (`npm install @drupal-canvas/cli -g`), authenticated by an [API client](/start-here/glossary/#api-client) with the `canvas:asset_library` and `canvas:js_component` [scopes](/start-here/glossary/#scope) | Page content, hosting, and everything outside Canvas components | [Canvas CLI reference](/source-cms/reference/canvas-cli/) |

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](https://docs.acquia.com/acquia-cloud-platform/creating-and-managing-your-build-definition-file) on docs.acquia.com). (The one crossover: [`acli codestudio:pipelines-migrate`](/cloud-platform/reference/acli/#codestudiopipelines-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](/source-cms/deploy/external-ci/) or [`acli push:artifact`](/cloud-platform/reference/acli/#pushartifact); 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.

- [Quickstart](/cloud-platform/cli/quickstart/): Install the acli Phar, authenticate with a Cloud Platform API token, and run your first real command. All in under 10 minutes.
- [Everyday workflows](/cloud-platform/cli/everyday-workflows/): The daily acli jobs on one page: orient on the right application and environment, then tail logs, pull databases, run Drush remotely, deploy artifacts, create temporary environments, and script it all safely.
- [Acquia Skills for coding agents](/cloud-platform/cli/acquia-skills/): Install Acquia Skills with npx skills add acquia/acquia-skills and run Cloud Platform operations from an agentic CLI in natural language, including BYOAI in Cloud IDE.
- [Call the Cloud Platform API](/cloud-platform/cli/platform-api/): Generate a Cloud Platform API token, exchange it for a short-lived OAuth 2.0 access token, and make one authenticated call. All in under 10 minutes.