Automate Docker Deployments from CI/CD
git push → CI builds → BridgePort ships
The healthiest CI/CD split keeps builds where they belong — in CI, reproducible and versioned — and hands everything after the registry push to something that understands your servers. Doing that handoff with an SSH key in a CI secret and a bash script means your pipeline has root on production and no idea whether the deploy actually worked.
With BridgePort the handoff is a signed webhook. CI builds and pushes the image, then calls one endpoint; BridgePort pulls, deploys to the right servers, gates each step on health checks, rolls back automatically on failure, and reports the result — to your team and back to your tooling.
How it works
CI builds and pushes
GitHub Actions, GitLab CI, or any pipeline builds the image and pushes it to your registry — BridgePort works with the registries you already use.
One webhook call
The pipeline calls an incoming webhook, authenticated by HMAC signature (GitHub-style X-Hub-Signature-256 supported). Deploy a single service, or every service running that image.
Health-gated rollout
The deploy runs with the service’s strategy, or through a deployment plan that orders dependencies and checks health between steps.
Rollback and report
A failed health gate rolls the plan back automatically. Outgoing webhooks and notifications report success or failure to Slack, PagerDuty, or your own systems.
What you get
HMAC-signed webhooks
Incoming deploy triggers are authenticated by signature — no SSH keys or admin credentials in CI secrets.
Webhooks guide →Deploy-all-for-image
One webhook can update every service running an image across the fleet — staging and production stay in step.
Incoming webhooks →Plans with auto-rollback
Dependency-ordered, health-gated multi-service releases that undo themselves when a check fails.
Deployment plans →Service accounts
Machine identities with scoped, role-capped API tokens — automation credentials that survive team turnover.
Service accounts →Terraform provider
Manage servers, services, secrets, and config as code; runtime operations stay imperative and auditable.
Terraform provider →Full API, SDK & CLI
Everything the UI does is a stable REST API — with a Go SDK, a CLI, and an MCP server for AI agents.
API reference →Frequently asked questions
Does BridgePort build my images?
No — deliberately. CI owns the build so it stays reproducible and versioned; BridgePort owns everything after the registry push: pulling, deploying, health-checking, and rolling back.
How does CI authenticate to BridgePort?
Incoming webhooks are verified by HMAC signature (X-Webhook-Signature, or GitHub-compatible X-Hub-Signature-256). For richer automation, service accounts issue scoped API tokens with a role cap.
Are there ready-made CI examples?
Yes — the webhooks guide includes copy-paste examples for GitHub Actions, GitLab CI/CD, and a generic curl script.
Can I manage BridgePort itself as code?
Yes. The official Terraform provider manages configuration — servers, services, secrets, config files, registries — while deploys and restarts remain imperative operations through the UI, API, CLI, or webhooks.