CI/CD Options
How SeaGit turns a code change into a running deployment — and the four options you can choose from, based on how much you want SeaGit to handle versus how much you want to keep in your own hands.
From Code Change to Live Deployment
Every deployment follows the same simple journey, no matter which option you choose:
- 1. Code change — a developer pushes a commit or opens / updates a pull request.
- 2. Build starts — your application is packaged into a deployable release.
- 3. Build completes — the release is published to your image registry and reported as success or failure.
- 4. Deployment — SeaGit rolls the new release out to the right environment and gives it a live URL.
The four options below differ only in who builds your release in steps 2 and 3. SeaGit always handles the deployment the same way — so previews, promotion, rollbacks, and status reporting work identically whichever option you pick.
Choosing Your Option
Fully Automatic (default, easiest)
Connect your repository, point to your image registry, and you're done. SeaGit detects every change, builds your release, and deploys it — no pipeline configuration required.
Best for: teams who want the shortest path from code change to running app.
Managed Pipelines
SeaGit runs the build for you inside your own Kubernetes cluster, with faster repeat builds and support for custom steps such as tests and quality checks — defined with a simple file in your repository.
Best for: teams that want builds inside their own cluster, faster build times, or richer pipelines.
Connect Your Own Build System
Already run your own build system in your cluster? Connect it to SeaGit directly. Your system builds the release, and SeaGit takes over from there to deploy and manage it.
Best for: teams with an established build setup they want to keep running.
Bring Your Own CI/CD
Keep the CI/CD tool you already use. When your pipeline finishes building, it lets SeaGit know — and SeaGit handles the deployment. A lightweight, one-step integration.
Best for: teams with existing CI/CD investments who want SeaGit purely for deployment management.
Side-by-Side Comparison
| Capability | Automatic | Managed Pipelines | Your Build System | Bring Your Own |
|---|---|---|---|---|
| Setup effort | Minimal | Low | Moderate | Varies |
| Builds run in your cluster | — | Yes | Yes | Your choice |
| Custom steps (tests, checks, etc.) | Limited | Yes | Yes (you control it) | Yes (you control it) |
| Faster repeat builds | Best-effort | Yes | You configure | You configure |
| Managed by SeaGit | Fully | Mostly | Deployment only | Deployment only |
| Use your own image registry | Yes | Yes | Yes | Yes |
| Previews, promotion & rollback | SeaGit | SeaGit | SeaGit | SeaGit |
What Triggers a Build
Whichever option you choose, SeaGit only starts a build for changes that produce something deployable:
✓ Builds run on:
- A pull request opened, reopened, or updated with new commits
- A pull request merged into its target branch
- A push to any branch
✗ Builds are skipped for:
- Label, assignment, or other metadata-only changes on a pull request
- A pull request closed without merging
- Release tag pushes
- Branch deletions
These rules follow the conventions teams already expect from modern development workflows, so behavior is predictable from day one.
Secure by Default for Outside Contributors
By default, SeaGit only builds pull requests from contributors on your trusted list. Requests from outside that list are declined before any build runs — so untrusted code never runs with access to your build credentials.
- Your own organization is trusted automatically — your team's changes just work.
- Want to accept contributions from a trusted partner? Add them to your trusted list in account settings.
- Changes from branches within your own repository are always accepted.
This mirrors the safe defaults used across the industry, where code from outside contributors is never trusted with your secrets automatically.
Status You Can See
For every build, SeaGit reports the outcome right on your pull request or commit, and records progress in the deployment timeline in your dashboard:
- Pending — build queued or in progress
- Success — release built and deployment started
- Failure — build error; deployment not started
Once a deployment succeeds, SeaGit also posts a summary back to the pull request with a direct link to the live environment, plus a separate deployment status so reviewers can tell at a glance that the change is live.
Preview Environments for Every Change
All four options work the same way with SeaGit's deployment model: every pull request or branch change lands in its own preview environment with its own URL, fully isolated from your live production deployment. Validate it, then promote it to production with a single action. See the Deployments guide for how previews, promotion, and rollback fit together.
Next Steps
Set up your first application →
Connect a repository and pick the option that fits your team.
Understand deployments →
How previews, production, and rollback fit together.
Variables & secrets →
Provide registry credentials and runtime configuration.
Troubleshooting →
Build failed? Deployment stuck? Common fixes.