How to Manage Workspaces with Rudder CLI Beta

This guide explains how to use import metadata and Rudder CLI to move between development and production workspaces and to streamline deployment.

Overview

workspace_id inside import metadata records where you imported from. When you later run apply against another workspace (for example production), Rudder CLI can create fresh resources there instead of binding to the original import.

You can build and test in a development workspace, then promote the same project to production. The same workflow covers Data Catalog, Tracking Plans, SQL Models, Event Stream Sources, Destinations, Connections, and Transformations.

Streamline import and production deployment

For production environments, you can streamline the import and deployment process by integrating Rudder CLI with your CI/CD pipeline. This approach allows you to import resources once and then have your automated pipeline handle subsequent deployments.

Workflow

1. Import: Run import workspace and generate YAML from the workspace
2. Organize: Place files where your repository expects them
3. Commit: Push the YAML to version control
4. Deploy: Run rudder-cli apply from the pipeline

CI/CD authentication and permissions

Configure your pipeline with a workspace-level Service Access Token with the same resource permissions you use for local import and apply. Limit the token to the resource types the pipeline touches.

For token types, legacy RBAC, and Personal Access Token caveats, see Prerequisites in the import guide.

Benefits

• Automated deployments: The pipeline applies approved YAML without manual CLI steps
• Version control: Every change has a Git history
• Consistent environments: The same definitions land in each stage you target
• Rollback: You revert through Git when you need to undo a release

See GitHub Actions for a full CI/CD example.