Deployment Overview
Bruin can run anywhere the CLI can run. The right deployment option depends on how much infrastructure you want to operate, where your credentials live, and whether you need a managed scheduler, CI/CD runner, serverless job, container platform, or existing orchestrator.
For a managed setup with scheduling, monitoring, lineage, runs, backfills, and secure connection management, start with Bruin Cloud. If you prefer to own the runtime, use one of the self-managed options below.
ManagedBruin CloudRun scheduled pipelines from your Git repo without maintaining servers. Bruin Cloud handles orchestration, logs, lineage, backfills, notifications, and encrypted connections.CI/CD runnerGitHub ActionsUse GitHub-hosted or self-hosted runners to validate, test, and run pipelines on pushes, schedules, or manual triggers.CI/CD runnerGitLab CI/CDRun Bruin from GitLab pipelines with variables for secrets, scheduled pipelines, manual jobs, and deployment environments.Virtual machineUbuntu VM with CronInstall the Bruin CLI on a VM and schedule runs with cron. This is simple, explicit, and works well when you already manage servers.AWS serverlessAWS LambdaPackage Bruin in a Lambda container image for short scheduled or event-driven runs with EventBridge and Secrets Manager.AWS containersAWS ECSRun Bruin as ECS Fargate tasks for containerized workloads that need more runtime, memory, or operational control than Lambda.GCP serverlessGoogle Cloud Run JobsRun Bruin in Cloud Run Jobs with Artifact Registry, Secret Manager, Cloud Scheduler, and Cloud Logging.OrchestratorApache AirflowUse Airflow DAGs to call Bruin from BashOperator or KubernetesPodOperator when Airflow already owns your scheduling layer.
Choosing an Option
| Option | Best for | Tradeoff |
|---|---|---|
| Bruin Cloud | Managed scheduling, monitoring, lineage, backfills, and secrets | Requires using the hosted Bruin Cloud control plane |
| GitHub Actions | GitHub-native scheduled or manual production runs | Runner timeouts and concurrency depend on your GitHub plan and runner setup |
| GitLab CI/CD | GitLab-native scheduled or manual production runs | Runtime behavior depends on GitLab runners and CI/CD variables |
| Ubuntu VM with Cron | Simple self-managed deployments on EC2, Compute Engine, DigitalOcean, or another VM | You maintain the server, cron, logs, updates, and credentials |
| AWS Lambda | Short event-driven or scheduled AWS workloads | Lambda timeout and package constraints limit longer pipelines |
| AWS ECS | Longer AWS container tasks with more control over CPU, memory, and networking | Requires ECS, ECR, IAM, scheduling, and logging setup |
| Google Cloud Run Jobs | Serverless GCP batch jobs with Cloud Scheduler | Requires container build, Artifact Registry, IAM, and GCP job configuration |
| Apache Airflow | Teams that already operate Airflow and want Bruin inside existing DAGs | You maintain Airflow and the worker or Kubernetes runtime |
CI/CD Validation
If you only want to validate and unit-test pipelines in pull requests, use the CI/CD integration guides instead of the deployment guides: