Set Up Argo CI/CD with Ephemeral Preview Environments

What you'll end up with: an ephemeral environment per pull request

Open a pull request, and within a couple of minutes it carries three green SeaGit status checks and a comment linking to a live preview URL running that exact commit — built by a pipeline in your own cluster, pushed to your own registry, deployed to its own ephemeral environment without touching production. Each of these preview environments is a real deployment slot on its own hostname, created for that commit and discarded when you are done with it.

Measured on a minimal Python (FastAPI) service with a 3-step default pipeline: the build finished in 31 seconds, the deployment reached started 84 seconds later, and the preview URL answered HTTP 200 about 2 minutes 20 seconds after the pull request was opened. Larger images with more dependencies take proportionally longer to build; the deploy half stays roughly constant.

Prerequisites

• A cluster that is up and running, with an ingress controller.
• A domain attached to the environment, and the matching External DNS add-on on the cluster — so the hostnames you pick actually resolve. For a Route 53 domain see Deploy an App on an AWS Route 53 Domain.
• The SeaGit GitHub App installed on the repositories you want to build (Providers).
• A plan that includes MinIO — or your own S3 bucket to use instead.

Step 1 — Add a node pool for builds

On your cluster, add a custom node pool named builds. Give it room to grow and let it scale from a small minimum — build load is bursty, and a pool that scales back down costs you nothing between builds.

Adding a node pool is a change to the cluster, so allow a few minutes for it to apply before moving on.

Step 2 — Connect the providers Argo CI needs

Under Providers, make sure you have:

• A GitHub provider — used to clone your repositories.
• A registry — choose ECR to push into the AWS account behind your cluster, or connect another registry.
• A token/API-key provider for the webhook secret — this authenticates build events so only you can trigger your pipelines.
• A provider holding a SeaGit API key — how finished builds report their result back. When you create the API key, tick “Store API Key as Provider credentials?” and this provider is created for you.

Skipping the API-key provider is the classic silent failure: builds succeed, but SeaGit never hears about it and the deployment sits at queued indefinitely.

Step 3 — Install MinIO

On the cluster's add-ons, install MinIO. It gives Argo CI somewhere to keep build artifacts, caches, and logs, all inside your own cluster.

Standalone mode is enough for build artifacts. Distributed mode is available on Startup plans and above. If you would rather use your own S3 bucket, skip this step and fill in Argo CI's Artifact Storage settings in the next step instead.

Wait for MinIO to reach applied before continuing — Argo CI checks for it at install time, not later.

Step 4 — Install Argo CI

Install the Argo CI add-on on the same cluster and fill in the form:

• Github Provider, Docker Registry, Webhook Password (Provider) and Seagit API Key (Provider) — the providers from Step 2.
• Workflow Node Pool — select builds, the pool from Step 1.
• Host Name — where the pipeline dashboard is served, e.g. argoci.your-domain.
• Webhook Host Name — the endpoint that receives build events, e.g. argohook.your-domain.

The install takes a few minutes. When it reports applied, open the dashboard host name in a browser — it should answer over HTTPS with a valid certificate.

Step 5 — Install Argo CD (optional)

If you want a Git repository to be the source of truth for cluster state, install Argo CD as well. Point its Node Pool at builds too, and give it a host name such as argocd.your-domain. It has no MinIO requirement and does not affect the build path — SeaGit deploys your applications either way.

Step 6 — Point an environment at the build server

A cluster with Argo CI installed is capable of building. The environment decides whether it actually does.

Open your environment → Build Servers → add one:

• Type: Argo Workflows
• Cluster: the cluster you just set up — only clusters with Argo CI installed appear here

If the dropdown is empty, Argo CI has not finished installing, or it was installed on a different cluster than the one this environment uses.

Step 7 — Create the application and instance

Create an application with Source Code (Git) as its source, and select your repository. If your repository was connected recently and does not appear, refresh the repository list.

Two fields decide whether your pull requests will build:

Branch or Pattern

This is what routes a pull request to this instance. Enter a specific branch (main) to build only that branch, or a glob pattern (ci-*, feature/*, release/**) to match a family of branches.

Create New Blank Repository for this instance in AWS ECR?

Tick this when you are pushing to ECR and the repository doesn't exist yet. SeaGit creates it in every AWS account behind the target environment. A build cannot create its own registry repository — if it is missing, the push fails with NAME_UNKNOWN: The repository with name ‘…’ does not exist.

For applications built from source, the repository is named after your Git repository, not the instance — so several instances of the same service share one registry repository and are distinguished by image tag. That is usually what you want: one repository per service, one tag per commit.

Note the trade-off the form warns about: with this option on, no deployment is created automatically at instance creation — the first image has to exist before anything can be deployed. Your first pull request provides it.

Step 8 — Open a pull request

Push a branch whose name matches the pattern from Step 7 and open a pull request. Here is the sequence you should see:

pull request opened
   │
   ├─▶ Seagit Dispatch Status          ✓ routed to 1 instance
   │      a preview slot is created for this commit
   │
   ├─▶ Seagit Build Status (CI)        ⏳ → ✓ build success
   │      pipeline clones, builds and pushes  your-registry/your-repo:<commit>
   │      the check links to the pipeline run
   │
   └─▶ Seagit Deployment Status (CD)   ⏳ → ✓ deployment succeeded
          image is rolled out, DNS and TLS are set up
          comment posted with the live preview URL

You also get two comments on the pull request — a Build Summary and a Deployment Summary — each linking to the instance, the environment, and the deployment in your dashboard.

Open the preview URL. It runs that commit, on its own hostname, over HTTPS, fully isolated from your production deployment. Push another commit to the same branch and the same slot is rebuilt and redeployed. When you are happy with it, promote it — see Deployments.

Troubleshooting

These are the failures that actually come up, with the signature that identifies each one.

Frequently Asked Questions

Next Steps