Skip to main content

Cloud Deployment Guide

Work in Progress

This deployment feature is currently only available in the feature/deploy branch.

GitHub Repository: https://github.com/supervaize/supervaizer/tree/feature/deploy

This documentation covers features that are under active development and may change before the next stable release.

The supervaizer deploy command provides fully automated deployment of Supervaizer agents to cloud platforms with zero-downtime updates, health verification, and automatic rollback capabilities.

Overview

info

The deployment CLI supports three major cloud platforms:

  • GCP Cloud Run - Serverless container platform
  • AWS App Runner - Fully managed container service
  • DigitalOcean App Platform - Container-based app hosting

The supervaizer deploy command automates the entire deployment process:

Test Locally - Validate your agent with Docker before cloud deployment

Plan - Preview changes and validate configuration

Deploy - Build, push, and deploy with health verification

Monitor - Check deployment status and health

Cleanup - Remove deployments when needed

Prerequisites

Cloud Provider Setup

Before using the deployment CLI, ensure you have:

Install and Authenticate

# Install Google Cloud CLI
curl https://sdk.cloud.google.com | bash
exec -l $SHELL

# Authenticate
gcloud auth login
gcloud auth application-default login

# Set project
gcloud config set project YOUR_PROJECT_ID

# Enable required APIs
gcloud services enable run.googleapis.com
gcloud services enable secretmanager.googleapis.com
gcloud services enable artifactregistry.googleapis.com

Required Permissions

Your account needs these IAM roles:

  • Cloud Run Admin
  • Secret Manager Admin
  • Artifact Registry Writer
  • Service Account User

Local Requirements

# Docker must be installed and running
docker --version
docker ps

# Git repository (for image tagging)
git status

Commands

Plan Deployment

Preview what will be deployed and validate your configuration:

# Plan deployment to GCP Cloud Run
supervaizer deploy plan --platform cloud-run --name my-agent --env prod

# Plan with custom options
supervaizer deploy plan \
--platform aws-app-runner \
--name email-agent \
--env staging \
--region us-east-1 \
--project-id my-aws-account

Output Example:

📋 Deployment Plan: email-agent-staging

Platform: AWS App Runner
Region: us-east-1
Environment: staging

Actions:
✅ CREATE: ECR repository (email-agent-staging)
✅ CREATE: Secrets Manager secrets (SUPERVAIZER_API_KEY, SV_RSA_PRIVATE_KEY)
✅ CREATE: App Runner service (email-agent-staging)
✅ UPDATE: Environment variables (SUPERVAIZER_PUBLIC_URL)

Estimated Cost: $0.05/hour

Deploy Application

Deploy your Supervaizer agent to the cloud:

# Deploy to GCP Cloud Run
supervaizer deploy up --platform cloud-run --name my-agent

# Deploy with all options
supervaizer deploy up \
--platform do-app-platform \
--name email-agent \
--env prod \
--region fra \
--port 8000 \
--generate-api-key \
--generate-rsa \
--yes

Deployment Process:

  1. Build - Create Docker image from your code
  2. Push - Upload image to cloud registry
  3. Secrets - Create/update API keys and RSA keys
  4. Deploy - Create or update the service
  5. Configure - Set SUPERVAIZER_PUBLIC_URL
  6. Verify - Health check until service is ready
  7. Output - Display service URL and endpoints

Success Output:

🚀 Deployment Complete!

Service URL: https://email-agent-prod-xyz123.run.app
Admin Interface: https://email-agent-prod-xyz123.run.app/admin/
API Documentation: https://email-agent-prod-xyz123.run.app/docs

Health Status: ✅ Healthy
Revision: email-agent-prod-xyz123-001
Image: gcr.io/my-project/email-agent:abc123def

Check Status

Monitor your deployment status and health:

# Check status
supervaizer deploy status --platform cloud-run --name my-agent --env prod

# Verbose status with logs
supervaizer deploy status --platform aws-app-runner --name email-agent --verbose

Status Output:

📊 Deployment Status: email-agent-prod

Service URL: https://email-agent-prod-xyz123.run.app
Health Status: ✅ Healthy
Last Check: 2025-01-15 10:30:45 UTC

Configuration:
Environment: prod
Port: 8000
Image: gcr.io/my-project/email-agent:abc123def
Revision: email-agent-prod-xyz123-001

Resources:
CPU: 1 vCPU
Memory: 512 MiB
Instances: 1-10 (auto-scaling)

Remove Deployment

Clean up your deployment and associated resources:

# Remove deployment
supervaizer deploy down --platform cloud-run --name my-agent --env prod

# Remove with confirmation
supervaizer deploy down --platform aws-app-runner --name email-agent --yes

Cleanup Process:

  1. Stop - Scale down service to zero instances
  2. Delete - Remove the service
  3. Secrets - Delete tool-managed secrets
  4. Confirm - Verify cleanup completion
warning

The down command only removes tool-managed resources. Images in registries are preserved by default.

Test Locally

Test your Supervaizer agent locally using Docker before deploying to the cloud:

# Test locally with default settings
supervaizer deploy local --name my-agent

# Test with custom options
supervaizer deploy local \
--name email-agent \
--env dev \
--port 8000 \
--generate-api-key \
--generate-rsa \
--timeout 60 \
--verbose

Local Testing Process:

  1. Docker Check - Verify Docker is running and accessible
  2. Generate Files - Create Dockerfile, docker-compose.yml, and .dockerignore
  3. Generate Secrets - Create API key and RSA private key for testing
  4. Build Image - Build the service image with local-test tag
  5. Start Services - Launch Docker Compose with generated secrets
  6. Health Check - Poll health endpoint until service is ready
  7. Verify Endpoints - Test health, API docs, and admin interface
  8. Display Info - Show service URL, API key, and access information

Success Output:

🧪 Local Testing Complete!

Service URL: http://localhost:8000
Admin Interface: http://localhost:8000/admin/
API Documentation: http://localhost:8000/docs

Health Status: ✅ Healthy
API Key: sv_test_********************
RSA Key: Generated and configured

To stop the service:
docker-compose -f .deployment/docker-compose.yml down

Local Testing Options:

OptionDescriptionDefault
--nameService base nameCurrent directory name
--envEnvironment (dev, staging, prod)dev
--portApplication port8000
--generate-api-keyCreate secure API key for testingfalse
--generate-rsaGenerate RSA private key for testingfalse
--timeoutSeconds to wait for service startup30
--verboseShow Docker Compose outputfalse
--docker-files-onlyOnly generate Docker files without running themfalse
--source-dirSource directory pathsrc
--controller-fileController file namesupervaizer_control.py

Docker Files Only Mode:

Use --docker-files-only to generate Docker configuration files without starting the services:

# Generate Docker files only
supervaizer deploy local --docker-files-only --name my-agent

# Generate files with custom configuration
supervaizer deploy local \
--docker-files-only \
--name email-agent \
--port 8080 \
--generate-api-key \
--generate-rsa

This mode is useful for:

  • CI/CD pipelines - Generate files for external Docker execution
  • Custom Docker setups - Use generated files with your own Docker workflow
  • File inspection - Review generated Dockerfile and docker-compose.yml before running
  • Manual testing - Run Docker commands manually with generated configuration

Generated Files:

  • .deployment/Dockerfile - Container image definition
  • .deployment/docker-compose.yml - Service orchestration
  • .deployment/.dockerignore - Docker build exclusions
  • .deployment/secrets/ - Generated API keys and RSA keys

Custom Source Directory and Controller File:

Use --source-dir and --controller-file to customize your project structure:

# Default usage (backward compatible)
supervaizer deploy local

# Custom source directory
supervaizer deploy local --source-dir .

# Custom controller file
supervaizer deploy local --controller-file my_controller.py

# Both custom parameters
supervaizer deploy local --source-dir lib --controller-file custom_controller.py

# Combined with docker-files-only
supervaizer deploy local \
--docker-files-only \
--source-dir . \
--controller-file my_controller.py

Use Cases:

  • Non-standard project layouts - When your source code is not in a src/ directory
  • Multiple controllers - When you have different controller files for different environments
  • Monorepo setups - When working with multiple services in a single repository
  • Legacy projects - When adapting existing projects with different directory structures

Local Environment Variables:

The local testing automatically sets these environment variables:

  • SUPERVAIZER_ENVIRONMENT=dev
  • SUPERVAIZER_HOST=0.0.0.0
  • SUPERVAIZER_PORT={port}
  • SUPERVAIZER_API_KEY={generated-test-key}
  • SV_RSA_PRIVATE_KEY={generated-rsa-key}
  • SV_LOG_LEVEL=INFO

Health Check Endpoints:

Local testing verifies these endpoints:

  • Basic Health: GET http://localhost:{port}/.well-known/health
  • API Health: GET http://localhost:{port}/agents/health (with API key header)
  • API Documentation: GET http://localhost:{port}/docs

Cleanup:

# Stop local services
docker-compose -f .deployment/docker-compose.yml down

# Remove local images
docker rmi $(docker images -q "*local-test*")

# Clean up generated files
rm -rf .deployment/
tip

Use local testing to validate your agent configuration before deploying to cloud platforms. It's faster and doesn't require cloud provider authentication.

Configuration Options

Common Options

OptionDescriptionDefault
--platformCloud platform (cloud-run, aws-app-runner, do-app-platform)required
--nameService base nameCurrent directory name
--envEnvironment (dev, staging, prod)dev
--regionProvider regionPlatform default
--project-idGCP project / AWS account / DO projectFrom CLI config
--portApplication port8000
--imageCustom image tagAuto-generated from git SHA
--generate-api-keyCreate secure API key if missingfalse
--generate-rsaGenerate RSA private key secretfalse
--yesNon-interactive modefalse
--no-rollbackKeep failed revision on errorfalse
--timeoutDeploy + verify timeout (seconds)300
--verboseShow underlying CLI outputfalse

Platform-Specific Options

# GCP-specific options
supervaizer deploy up \
--platform cloud-run \
--project-id my-gcp-project \
--region europe-west1 \
--use-cloud-build \
--min-instances 1 \
--max-instances 10

GCP Options:

  • --use-cloud-build - Use Cloud Build instead of local Docker

  • --min-instances - Minimum running instances (0-1000)

  • --max-instances - Maximum running instances (1-1000)

Environment Variables

The deployment CLI automatically sets these environment variables:

Standard Variables

VariableValueDescription
SUPERVAIZER_ENVIRONMENT--env valueEnvironment name
SUPERVAIZER_HOST0.0.0.0Bind to all interfaces
SUPERVAIZER_PORT--port valueApplication port
SV_LOG_LEVELINFOLogging level
SUPERVAIZER_PUBLIC_URLService URLAuto-set after deployment

Secret Variables

VariableSourceDescription
SUPERVAIZER_API_KEYGenerated/Secret ManagerAPI key for admin interface
SV_RSA_PRIVATE_KEYGenerated/Secret ManagerRSA key for encryption

Custom Variables

You can add custom environment variables using a .deployment/config.yaml file:

# .deployment/config.yaml
environment:
CUSTOM_VAR: "custom-value"
DATABASE_URL: "postgresql://..."

secrets:
- name: "MY_SECRET"
value: "secret-value"
description: "My custom secret"

Generated Files

The deployment CLI creates files under .deployment/ directory:

.deployment/
├── Dockerfile # Generated Docker image
├── .dockerignore # Docker ignore rules
├── docker-compose.yml # Local testing
├── do-app-spec.yaml # DigitalOcean app spec
├── cloudbuild.yaml # GCP Cloud Build config
├── config.yaml # Custom configuration
├── state.json # Deployment state
├── DEPLOY_AUTOMATION.md # Usage documentation
└── logs/ # Deployment logs
info

The entire .deployment/ directory is automatically added to .gitignore to prevent accidental commits of deployment artifacts and secrets.

Health Verification

The deployment CLI verifies service health using the /.well-known/health endpoint:

# Health check endpoint
GET https://your-service-url/.well-known/health

# Expected response
{
"status": "healthy",
"timestamp": "2025-01-15T10:30:45Z",
"version": "0.9.8",
"uptime": 3600
}

Health Check Process

  1. Deploy - Service is created/updated
  2. Wait - Allow service to start (30-60 seconds)
  3. Poll - Check health endpoint every 5 seconds
  4. Verify - Confirm 200 response with healthy status
  5. Rollback - If health check fails (unless --no-rollback)

Troubleshooting

Common Issues

Authentication Errors

# GCP: Re-authenticate
gcloud auth login
gcloud auth application-default login

# AWS: Check credentials
aws sts get-caller-identity

# DigitalOcean: Re-authenticate
doctl auth init

Permission Errors

Ensure your account has the required permissions for your chosen platform. See Prerequisites for detailed permission requirements.

Docker Build Failures

# Check Docker is running
docker ps

# Test Docker build locally
docker build -t test-image .

# Check Dockerfile syntax
cat .deployment/Dockerfile

Health Check Timeouts

# Check service logs
supervaizer deploy status --platform cloud-run --name my-agent --verbose

# Test health endpoint manually
curl https://your-service-url/.well-known/health

# Increase timeout
supervaizer deploy up --timeout 600

Rollback Issues

# Disable automatic rollback
supervaizer deploy up --no-rollback

# Manual rollback to previous revision
supervaizer deploy up --image previous-image-tag

Debug Mode

Enable verbose logging for detailed troubleshooting:

# Verbose deployment
supervaizer deploy up --platform cloud-run --name my-agent --verbose

# Check deployment logs
cat .deployment/logs/deploy-*.log

# Check state file
cat .deployment/state.json

Best Practices

Security

  1. API Keys - Always use --generate-api-key for production
  2. Secrets - Never commit secrets to version control
  3. Permissions - Use least-privilege IAM roles
  4. Networking - Configure VPC and firewall rules as needed

Performance

  1. Image Size - Optimize Docker images for faster deployment
  2. Dependencies - Use .dockerignore to exclude unnecessary files
  3. Scaling - Configure appropriate min/max instances
  4. Health Checks - Ensure health endpoints respond quickly

Reliability

  1. Rollbacks - Test rollback procedures in staging
  2. Monitoring - Set up cloud provider monitoring
  3. Logging - Configure centralized logging
  4. Backups - Regular state and configuration backups

What's Next?

  • Monitor your deployment using the Admin Interface
  • Integrate with CI/CD pipelines for automated deployments
  • Scale your service based on traffic patterns
  • Explore advanced features like blue-green deployments

Need Help?