Skip to main content
Self-hosted agents are the recommended approach for production use. Your agents run in your infrastructure with your database credentials—Basecut never touches your data or credentials. Agents continuously poll for snapshot jobs, execute extractions, and upload results to your configured storage (S3/GCS). All processing happens in your environment.

Why Self-Hosted?

Security & Compliance:
  • Your database credentials never leave your environment
  • Data processing happens entirely in your VPC/cloud
  • Meet strict compliance requirements (SOC2, HIPAA, GDPR)
  • Zero-trust architecture
Performance & Control:
  • Choose your own compute resources (CPU, memory)
  • Deploy in the same region as your database
  • Scale agents based on your workload
  • No network latency to external services
Cost Efficiency:
  • Pay only for your infrastructure (EC2, GCS, etc.)
  • No per-job fees or processing charges
  • Predictable costs at scale

When to Use Self-Hosted Agents

  • Production workloads - Recommended default for all production snapshots
  • Private databases - Behind VPN/VPC without public access
  • Compliance requirements - Data cannot leave your infrastructure
  • High volume - Processing dozens or hundreds of snapshots

Railway (Fastest)

Deploy a Basecut agent to Railway in one click: Deploy on Railway After deployment, set at least:
  • BASECUT_API_KEY
  • BASECUT_DATABASE_URL
Use this option when you want managed agent hosting without setting up Docker, Kubernetes, or ECS manually.

Docker Deployment

Basic Docker Run

Run a single agent container:
Environment variables: Agent settings like poll interval and agent ID are configured via CLI flags: --poll-interval, --heartbeat-interval, --agent-id, --run-once.

Docker Compose

For production deployments with multiple agents and monitoring:
Start the agent pool:

Kubernetes Deployment

Deploy agents in a Kubernetes cluster with autoscaling:
Deploy:

AWS ECS Deployment

Run agents on ECS Fargate with IAM roles for S3 access:
IAM policy for TaskRole (S3 access):
Deploy via CLI:

Agent Configuration

Network Access

Agents need outbound access to:
  1. Basecut API (api.basecut.dev:443)
    • Poll for jobs
    • Report job status
    • Upload job logs
  2. Your database (e.g., prod-db.internal:5432)
    • Execute extraction queries
    • Read schema metadata
  3. Cloud storage (S3/GCS)
    • Upload snapshot artifacts
Firewall rules:
  • Outbound HTTPS (443) to api.basecut.dev
  • Outbound PostgreSQL (5432) to your database
  • Outbound HTTPS (443) to s3.amazonaws.com or storage.googleapis.com

Database Credentials

Best practice: Use read-only database user
Pass credentials via:
  • Environment variable: BASECUT_DATABASE_URL=postgres://basecut_agent:password@host:5432/db
  • AWS Secrets Manager / Kubernetes Secrets

Monitoring and Logging

Monitor agents via container logs and your platform health checks.

Troubleshooting

Agent Not Picking Up Jobs

Check agent logs:
Common issues:
  • Invalid BASECUT_API_KEY (should start with bc_live_ or bc_test_)
  • Network access blocked to api.basecut.dev
  • Agent registered to wrong organization
Verify connectivity:

Database Connection Failures

Test database access from agent:
Common issues:
  • Firewall blocking database port
  • Database requires SSL (?sslmode=require)
  • Read-only user lacks schema permissions

S3/GCS Upload Failures

Verify cloud credentials:
Common issues:
  • IAM role/service account lacks PutObject permission
  • Bucket doesn’t exist or is in wrong region
  • Missing or invalid S3 region on the agent (output.region or AWS_REGION)
  • Network egress blocked to cloud storage API
Tip for S3-compatible endpoints (Cloudflare R2, MinIO):
  • Use output.provider: s3 with output.endpoint
  • Set output.region explicitly (Cloudflare R2: region: auto)

Cost Optimization

Right-Size Agent Resources

Autoscaling

Scale agents based on job queue depth:
  • Kubernetes HPA: Scale on CPU/memory utilization
  • ECS Service Autoscaling: Scale on CloudWatch metric JobQueueDepth (custom metric)
  • Target: 1 agent per 5-10 jobs in queue

Spot Instances

Agents are fault-tolerant—jobs resume if an agent dies:
  • ECS: Use Fargate Spot for 70% cost savings
  • Kubernetes: Use spot node pools
  • EC2: Use Spot Instances with interruption handling

Next Steps

Execution Modes

Understand agent vs local execution

Troubleshooting

Debug common agent issues

CI/CD Integration

Use agents in GitHub Actions

Environment Variables

Complete agent configuration reference