From Terminal to Production: A Guide to Environment Management with cli.do

Managing configurations across development, staging, and production environments is a classic developer challenge. A misplaced API key or a mismatched database connection string can lead to failed deployments, frustrating bugs, and unnecessary downtime. When you're building sophisticated agentic workflows that interact with multiple services, the complexity skyrockets. This is where the principle of Business as Code becomes essential, and where the .do CLI shines.

Agentic workflows are powerful, but they need to be developed, tested, and deployed with the same rigor as any other piece of critical software. The .do CLI brings this discipline directly to your favorite developer tool: the terminal. It provides a robust framework for managing your workflow's entire lifecycle, with a special focus on making environment management simple, secure, and scriptable.

This guide will walk you through how to use the .do CLI to master your environments, ensuring your agentic workflows move from your terminal to production smoothly and reliably.

The Peril of Environment Drift

Environment drift occurs when the configurations for your development, staging, and production environments diverge over time. One environment has an old version of an API key, another points to a test database, and the third has a feature flag enabled that the others don't. This drift is a primary source of "it works on my machine" issues and can cause catastrophic failures when a workflow that passed testing in staging is deployed to production.

For agentic workflows, which might manage customer onboarding flows or complex data processing pipelines, the stakes are even higher. A workflow using a sandbox API key in production won't just fail—it could fail silently, leading to lost data or incomplete business processes. The key to preventing this is a system that treats configuration as a first-class citizen, managed with the same care as your code.

Environment Management, the .do Way

The .do CLI is engineered to solve this problem. It allows you to define distinct environments and associate specific configurations—like API keys, endpoint URLs, and other secrets—with each one. The workflow code remains the same, but the configuration it uses changes based on the environment you deploy to.

This approach provides three key benefits:

1. Consistency: Your deployment process is identical for every environment.
2. Security: Secrets and sensitive credentials are never stored in your source code. They are managed securely within the .do platform and injected at runtime.
3. Speed: You can switch contexts and deploy to any environment with a simple flag in your command.

A Practical Walkthrough

Let's see how this works in practice. Imagine we are working on the customer-onboarding-v2 workflow mentioned in our hero example. This workflow needs to interact with a CRM and a payment provider.

Step 1: Define Your Environments

First, we'll create environments for staging and production. This is a one-time setup for your project.

# Log in to your account
$ do login

# Create a staging environment
$ do env create staging

# Create a production environment
$ do env create production

Step 2: Manage Environment-Specific Variables

Now, let's add the API keys for our CRM and payment provider. Notice how we scope each variable to a specific environment using the --env flag.

# Set variables for the staging environment (using test keys)
$ do env var set CRM_API_KEY "crm_test_abc123" --env staging
$ do env var set STRIPE_API_KEY "sk_test_123xyz" --env staging

# Set variables for the production environment (using live keys)
$ do env var set CRM_API_KEY "crm_live_def456" --env production
$ do env var set STRIPE_API_KEY "sk_live_456uvw" --env production

Your sensitive keys are now securely stored and tied to the correct environment. You can list them anytime with do env var list --env staging.

Step 3: Deploy with an Environment Target

With our configuration set, deploying the workflow to a specific environment is incredibly straightforward.

# Navigate to your workflow directory
$ cd /path/to/my-agent-workflow

# Deploy to the staging environment for testing
$ do workflow deploy . --name="customer-onboarding-v2" --env staging

// Output:
// ✓ Authenticating...
// ✓ Packaging workflow files...
// ✓ Uploading package (1.2MB)...
// ✓ Deploying agent 'customer-onboarding-v2' to environment 'staging'...
// ✓ Deployment successful!
//
// API Endpoint: https://api.do/workflows/customer-onboarding-v2
// Status:       Active (staging)

Once you've tested the workflow in staging and are confident it's working correctly, deploying to production is the exact same command, with only the environment flag changed.

# Deploy the same workflow bundle to production
$ do workflow deploy . --name="customer-onboarding-v2" --env production

// Output:
// ✓ Authenticating...
// ✓ Using existing package...
// ✓ Deploying agent 'customer-onboarding-v2' to environment 'production'...
// ✓ Deployment successful!
//
// API Endpoint: https://api.do/workflows/customer-onboarding-v2
// Status:       Active (production)

Automate Everything with CI/CD

The true power of this developer tool is unlocked when you integrate it into your CI/CD pipeline. Because every action is a simple command, automating your deployment process is trivial. This ensures that every change goes through the same battle-tested, automated path to production.

Here’s a conceptual example of what a deployment job might look like in a GitHub Actions workflow:

# .github/workflows/deploy.yml
name: Deploy Agentic Workflow

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install .do CLI
        run: npm install -g @do/cli

      - name: Deploy to Staging
        run: do workflow deploy . --name="customer-onboarding-v2" --env staging
        env:
          DO_API_TOKEN: ${{ secrets.DO_API_TOKEN }}

      # Add your automated testing steps here against the staging deployment

      - name: Deploy to Production
        # This step would typically run after manual approval
        run: do workflow deploy . --name="customer-onboarding-v2" --env production
        env:
          DO_API_TOKEN: ${{ secrets.DO_API_TOKEN }}

Take Control of Your Workflows

By combining the power of agentic workflows with the discipline of modern DevOps practices, the .do CLI gives you an unprecedented level of control and confidence. You can move faster, reduce errors, and ensure your business logic performs flawlessly in any environment.

Stop wrestling with messy configuration files and manual deployment checklists. Embrace Business as Code and make your terminal the central hub for your automated services.

Ready to tame your environments? Install the .do CLI today and turn your complex processes into simple, powerful commands.