GitOps & Build Infrastructure
The pieces that have to exist in your cluster before a pull request can build and deploy itself — a node pool for builds, object storage for build artifacts, Argo CI for pipelines, and Argo CD for GitOps delivery. This page explains what each one is for and the order they go in.
What is GitOps?
GitOps is an operating model where a Git repository holds the desired state of your infrastructure and applications. A controller, such as Argo CD, continuously compares the live cluster with that state and corrects any drift, so every change is a reviewed commit and a rollback is a git revert.
How GitOps works in SeaGit
SeaGit applies the GitOps idea to the whole path from commit to production. The repository is the record of what should run, and each step is triggered by a Git event rather than a manual deploy:
- A push or pull request reaches SeaGit through its GitHub App.
- With Argo CI installed, the image is built inside your cluster and pushed to your registry.
- SeaGit deploys that commit to its own preview deployment with its own URL, separate from main.
- You check the preview, then use Mark as Main or promote it. Main is never overwritten by a CI run.
Argo CD is optional. Install it when you want a controller to reconcile manifests you keep in Git, such as third-party components.
Want the click-by-click version instead? Follow Set Up Argo CI/CD End to End — the same material as a walkthrough, from an empty cluster to a pull request that builds and deploys itself.
What you are building
Routes B and C run your builds as real pipelines inside your own cluster. Nothing leaves your account: your source is cloned, your image is built and pushed to your registry, and SeaGit deploys the result. To make that possible, the cluster needs four things installed once.
YOUR CLUSTER
┌─ builds node pool ─────────────────────────────┐
│ dedicated nodes where build pods run │
│ │
│ MinIO ──────── stores build artifacts/logs │
│ Argo CI ────── runs the build pipelines │
│ Argo CD ────── GitOps delivery (optional) │
└────────────────────────────────────────────────┘
▲ │
│ trigger │ build result
│ ▼
SeaGit GitHub App SeaGit deploys · preview URL
promote · rollback · PR statusInstall order matters: the node pool first (so build pods have somewhere to land), then MinIO (Argo CI will not install without artifact storage), then Argo CI, then Argo CD if you want it.
The four pieces
1. A node pool for builds
Builds are bursty and hungry: they spike CPU for a minute or two, then disappear. Running them on the same nodes as your applications means a busy build can starve a running app, and a full application pool leaves builds stuck Pending with nowhere to schedule.
Add a custom node pool on your cluster — commonly named builds — and let it scale from zero. Both Argo CI and Argo CD ask for a Workflow Node Pool at install time; pointing them at this pool keeps build load off your application nodes and lets the pool shrink back to nothing between builds.
2. MinIO — artifact storage
MinIO is an S3-compatible object store that runs inside your own Kubernetes cluster. Argo CI needs somewhere to put what a pipeline produces — build logs, caches, and artifacts passed between steps — and MinIO keeps all of it in your account rather than in a third-party service.
This is a hard prerequisite. Installing Argo CI without artifact storage is rejected with MinIO needs to get installed first! — the install does not start. The one exception: if you supply your own S3 bucket in Argo CI's Artifact Storage settings, that satisfies the requirement and MinIO is not needed.
MinIO is not available on the Free plan, and distributed mode requires a Startup plan or above. On Free, bring your own S3 bucket instead.
3. Argo CI — the build pipelines
Argo CI (Argo Workflows) is what actually builds your code. It installs a workflow engine plus a webhook endpoint into your cluster, and ships a default pipeline that clones your repository, builds your Dockerfile, pushes the image to your registry, and reports the result back to SeaGit — so a repository with no pipeline file of its own still builds correctly.
Repositories that need more — tests, linting, scanning, multiple steps — can define their own pipeline in the repository and Argo CI will run that instead.
4. Argo CD — GitOps delivery (optional)
Argo CD continuously reconciles what is running in your cluster against what is declared in Git — the GitOps workflow in its strictest form. It is optional: SeaGit deploys your applications for you either way. Add it when you want a Git repository to be the source of truth for cluster state — your own manifests, third-party components, or anything you manage outside SeaGit's application model.
It installs independently of Argo CI and has no MinIO requirement.
What Argo CI asks for
Most of the install form is references to things you connect once under Providers. Set those up first and the install itself is a two-minute job.
| Field | What it is |
|---|---|
| Github Provider | The credentials the pipeline uses to clone your repository. |
| Docker Registry | Where built images are pushed. Choose ECR to push into the AWS account behind the cluster, or connect another registry provider. |
| Webhook Password (Provider) | A token/API-key provider holding the shared secret that authenticates incoming build events, so nobody else can trigger your pipelines. |
| Seagit API Key (Provider) | A provider holding a SeaGit API key. It is injected into the Argo namespaces as a Kubernetes Secret so finished builds can report their result back to SeaGit. Without it, builds run but SeaGit never hears the outcome — the deployment stays queued. |
| Workflow Node Pool | The node pool build pods are scheduled onto. Leave it as Any Node in the cluster only if you have no dedicated pool. |
| Host Name and Webhook Host Name | Public hostnames on one of your domains — typically argoci.your-domain for the pipeline dashboard and argohook.your-domain for the endpoint that receives build events. |
| Artifact Storage | Leave unset to use the MinIO you installed, or point it at your own S3 bucket. |
💡 When you create a SeaGit API key you can tick “Store API Key as Provider credentials?” and the provider is created for you — ready to pick in this form.
Connecting it to an environment
Installing Argo CI makes a cluster capable of building. An environment then has to be told to use it — that is what turns a pull request into a build.
Open the environment, go to its Build Servers settings, and add one:
- Type: Argo Workflows — then pick the Cluster that has Argo CI installed. Only clusters with the add-on appear in the list.
- Type: Custom — for Route D, where your own CI builds and reports back. Name your system and select the webhook provider holding its credentials.
An environment can have more than one build server, and applications deployed into that environment inherit these settings. A repository can override the choice with a .seagit file if different services need different build paths.
Example: an Argo CD Application
If you install Argo CD, it manages each application as an Application resource. The manifest below is a standard Argo CD example, not a SeaGit-specific format. It tells Argo CD to keep the deploy/k8s folder of a repository in sync with a namespace, and to prune and self-heal drift:
# web-app-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: web-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/your-org/web-app
targetRevision: main
path: deploy/k8s
destination:
server: https://kubernetes.default.svc
namespace: web-app
syncPolicy:
automated:
prune: true
selfHeal: trueApply it once, then check its sync status. The command assumes Argo CD runs in the argocd namespace:
kubectl apply -f web-app-application.yaml kubectl get applications -n argocd
How do I know it worked?
After all three add-ons report applied, three things should be true:
- The Argo CI dashboard answers on the host name you chose, over HTTPS with a valid certificate.
- Your builds node pool scales up when a build runs and back down when it finishes.
- A pull request on a connected repository shows three SeaGit status checks — Dispatch, Build (CI), and Deployment (CD).
If a build never starts, the usual cause is the environment having no build server attached, or the pull request's branch not matching the branch pattern on your application instance. The setup guide's troubleshooting section lists the failure signatures and their fixes.
Frequently Asked Questions
What is GitOps?
GitOps is an operating model where a Git repository holds the desired state of your infrastructure and applications. A controller, such as Argo CD, continuously compares the live cluster with that state and corrects any drift, so every change is a reviewed commit and a rollback is a git revert.
Is GitOps the same as CI/CD?
No. CI/CD is the pipeline that builds, tests and deploys code. GitOps is the rule that Git defines what runs and a controller enforces it. SeaGit uses both: Argo CI builds the image in your cluster, and deployments are driven from Git events. Argo CD is optional and adds reconciliation for manifests kept in Git.
What is a GitOps workflow?
A GitOps workflow makes a Git repository the source of truth for what runs in your cluster: you change Git, and a controller reconciles the cluster to match rather than anyone applying changes by hand. Argo CD is the component that performs that reconciliation. On SeaGit it is optional — SeaGit deploys your applications either way — and you add it when you want your own manifests, third-party components, or anything outside SeaGit application model driven from Git.
What is the difference between Argo CI and Argo CD?
Argo CI (Argo Workflows) runs build pipelines: it clones your repository, builds the image, pushes it to your registry, and reports the result. Argo CD does continuous delivery: it reconciles running cluster state against what is declared in Git. They install independently — Argo CI requires artifact storage such as MinIO, Argo CD does not — and you can run either without the other.
Why does Argo CI need MinIO?
Argo CI needs somewhere to store what a pipeline produces — build logs, caches, and artifacts passed between steps. MinIO provides that as an S3-compatible object store running inside your own cluster, so build data stays in your account. The requirement is enforced at install time: without MinIO applied, or an S3 bucket set in Argo CI Artifact Storage settings, the install is refused with "MinIO needs to get installed first!".
Do I need a separate node pool for builds?
It is strongly recommended. Builds are bursty — they spike CPU for a minute or two, then disappear — so running them on your application nodes lets a busy build starve a running app, and a full application pool leaves build pods stuck Pending with nowhere to schedule. A custom pool, commonly named builds, isolates that load and can scale back to nothing between builds. Both Argo CI and Argo CD ask which node pool to schedule onto.
Next Steps
Set up Argo CI/CD end to end →
The full walkthrough, from empty cluster to a deploying pull request.
Build & deploy routes →
Which of the four routes this infrastructure serves.
Clusters & node pools →
Adding the node pool your builds will run on.
Providers →
The GitHub, registry, and API-key credentials Argo CI asks for.