Skip to main content

Automate Expanso Cloud with the CLI

Use the Cloud console to design and inspect pipelines, then use the workspace API and expanso-cli to make deployment steps repeatable. A job definition can carry pipeline logic and deployment settings in a file that your team reviews and retains in version control.

Connect to the right workspace​

Open API Access from the workspace overview to obtain the endpoint and profile instructions. Create an API key under Keys. Use the generated instructions for your workspace rather than substituting the Cloud console URL as an API endpoint.

A bootstrap token registers nodes; an API key authenticates automation. See Access and API keys for their different scopes and lifecycles. Keep credentials in your automation system's secret store rather than in the job file or repository.

The Deploy to Cloud guide walks through profile setup, node verification, job validation, and deployment. The CLI reference and workspace API reference document individual operations.

Build a repeatable release​

  1. Retain the complete job definition, including node selection and rollout settings, alongside the pipeline configuration.
  2. Test transformations with representative, approved samples. Validate the pipeline and job formats with the tools described in Testing and debugging.
  3. Review the change in your existing source-control workflow.
  4. Select the intended workspace profile and deploy the job.
  5. Check deployment progress and execution health. Successful submission means the job was accepted; it does not prove that a matching node executed it.
  6. Compare versions and use the documented rollout or rollback controls when you need to change course.

Cloud's deployment view gives operators the corresponding progress and control surface for a release initiated through automation.

Organize staging and production​

Separate workspaces can represent development, staging, and production. Reuse pipeline logic while making each environment's source endpoints, destination endpoints, secret references, labels, and deployment policy explicit.

Treat this as a delivery workflow owned by your team. Copying or deploying a job into another workspace does not automatically create external credentials, source data, destination tables, or host resources there. Confirm that the selected nodes can resolve every referenced dependency before releasing.

Plan data migration separately​

Rolling deployment controls how a new pipeline version reaches nodes. Historical backfill also requires decisions about the source range, destination writes, deduplication, and completion criteria. Configure those through the selected components and verify the resulting data at the destination.

Deployment progress reports release progress across nodes. It is not a count of historical records copied or reconciled. Likewise, restoring a previous pipeline version restores its configuration; it does not undo records already written.

For a worked data movement example, see Data migration. For retry and delivery behavior, consult the specific input, buffer, and output component references.

LLM text version of the operations documentation