Software delivery shouldn’t depend on late-night kubectl commands, manual edits, or tribal knowledge. You commit code, a robot does the rest. That’s the promise of GitOps—your cluster simply reflects what’s declared in Git, while automated pipelines handle the “how.” In this article, we’ll build a practical GitOps pipeline that pairs Sealos (a cloud operating system built on Kubernetes) with GitHub Actions and Argo CD to put your deployments on autopilot.

You’ll learn what GitOps is, why it matters, how the pieces fit together, and how to implement a real-world setup with multi-environment promotion, image scanning, and optional self-hosted GitHub runners on your Sealos cluster.

---

GitOps is an operational model where Git is the single source of truth for both application code and the desired state of your infrastructure and applications. Instead of running imperative commands to change environments, you declaratively define the desired state in Git and let a controller (e.g., Argo CD) reconcile your cluster to match that state.

Key ideas:

• Declarative definitions: Everything from Deployments to Ingress is expressed in code (YAML, Helm charts, Kustomize overlays).
• Pull-based reconciliation: A controller continuously watches Git and converges your cluster toward the specified state.
• Versioned, auditable changes: Every change is a Git commit or pull request, providing traceability and rollbacks.

Think of GitOps as an “autopilot” for your Kubernetes clusters—consistent, auditable, and repeatable.

---

• Sealos: Sealos is a cloud operating system built around Kubernetes. It simplifies running and managing clusters, multi-tenancy, and platform services on top of Kubernetes. You can run it yourself or use Sealos-hosted options to quickly provision a cluster and manage apps.
• GitHub Actions: A powerful CI platform that integrates tightly with GitHub, supports reusable workflows, and scales from hobby to enterprise use cases.

Together with Argo CD (for continuous delivery), this stack gives you:

• End-to-end automation: Build, test, package, and deliver via GitHub Actions, then deploy via Argo CD.
• Clear separation of concerns: App repo for code, config repo for environment manifests.
• Repeatability and security: PR-based changes, signed container images (optional), and policy enforcement.

---

We’ll implement a two-repo GitOps setup with Argo CD reconciling your Sealos cluster:

• App repository (e.g., my-org/demo-app)

  • Source code
  • Dockerfile
  • CI workflow to build/test and push images to a registry (e.g., GHCR)
  • A job to update the config repository with the new image tag

• Config repository (e.g., my-org/demo-config)

  • Kustomize or Helm definitions
  • Environments: dev, staging, prod (as folders)
  • Argo CD Application manifests referencing these folders

• Sealos cluster

  • Kubernetes cluster where your apps run
  • Argo CD installed; Auto-sync enabled
  • Optional: Ingress, secrets management (Sealed Secrets/External Secrets), policy, observability

Flow:

1. Developer merges code to main in the app repo.
2. GitHub Actions builds a container image, pushes it to GHCR, and creates a PR to bump the image tag in the config repo (for dev).
3. Argo CD sees the updated config repo and synchronizes the Sealos cluster.
4. Promotion from dev → staging → prod is performed via PRs in the config repo.

---

• A running Sealos-based Kubernetes cluster and access to its kubeconfig.
• kubectl installed locally and configured for your cluster.
• GitHub repositories:
  • One for the application code
  • One for Kubernetes manifests/config
• Container registry access (GHCR is convenient with GitHub Actions).
• Basic familiarity with Kubernetes and GitHub Actions.

Note: If you’re using a hosted Sealos platform, you can create a Kubernetes cluster and download the kubeconfig through the Sealos console. If self-hosting Sealos, follow the official documentation to provision the cluster, then verify access with:

---

For illustration, we’ll use a minimal Node.js service.

Example: Node.js App

server.js:

package.json:

Dockerfile:

Build locally to test:

---

Structure your config repo like this:

Base manifests

base/deployment.yaml:

base/service.yaml:

base/kustomization.yaml:

Environment overlays

environments/dev/kustomization.yaml:

environments/staging/kustomization.yaml:

environments/prod/kustomization.yaml:

Note: Argo CD will apply these overlays per environment. Our CI will update the image tags for each environment via PRs.

---

Install Argo CD on your Sealos Kubernetes cluster:

Wait until all pods are ready:

To access the Argo CD UI (for initial setup), you can port-forward:

Default admin password (on initial install) can be obtained from:

For production, configure a proper Ingress and SSO/OIDC. Ensure network access is secured.

---

Create Argo CD Applications that point to your config repo’s environment folders. Example for dev:

argocd/app-dev.yaml:

Apply it:

Repeat for staging and prod (change name, namespace, and path accordingly).

---

In your app repository, add a workflow to build, test, and push images to GHCR, then propose a change in the config repo to bump the image tag for the dev environment.

.github/workflows/ci.yml:

Notes:

• The workflow uses the GitHub-provided GITHUB_TOKEN for pushing to GHCR. Ensure packages: write permission is enabled.
• To create PRs in the config repo, you typically need a token with repo write permissions. Use CONFIG_REPO_TOKEN as a repository secret in the app repo (preferably from a GitHub App or a fine-scoped PAT).
• This creates a PR for dev. For staging/prod, promotion should be manual via PRs in the config repo to keep control.

---

Once the PR in the config repo is merged, Argo CD will:

• Detect the tag bump in environments/dev/kustomization.yaml.
• Apply changes to your Sealos cluster in the demo-dev namespace.
• Keep reconciling and self-healing as needed.

You can watch status in the Argo CD UI or via:

---

Depending on your Sealos cluster setup, you can expose the service via an Ingress, a LoadBalancer, or port-forwarding.

Example Ingress (if you have an Ingress controller):

Add this to environments/dev as another Kustomize resource and configure DNS accordingly.

---

To promote to staging:

• Create a PR in the config repo that bumps environments/staging/kustomization.yaml image tag to the tested dev image tag.
• Merge the PR → Argo CD deploys to staging.

Similarly for production:

• Controlled via PRs to environments/prod, such as bumping the tag from stable to the new version.

This PR-based promotion ensures:

• Human review gates between environments.
• Full auditability and rollback via Git history.

---

1) Self-Hosted GitHub Actions Runners on Sealos

For faster builds or private networking, run self-hosted runners in your Sealos cluster using the actions-runner-controller.

High-level steps:

• Install actions-runner-controller with Helm.
• Create a RunnerDeployment pointing at your GitHub repo/org.
• Label and scale as needed.

Example RunnerDeployment:

Then, change runs-on in your workflows to match the runner labels. Ensure appropriate GitHub credentials are configured per controller’s docs.

2) Image Scanning and Policy

• Scan images during CI using Trivy:

• Enforce policies with Kyverno:
  • Require signed images (with cosign).
  • Block images with critical vulnerabilities.
  • Enforce label standards.

3) Secret Management

Avoid storing plaintext secrets in Git:

• Sealed Secrets: Encrypt secrets in Git; decrypt in cluster.
• External Secrets Operator: Sync secrets from a secret manager (e.g., AWS Secrets Manager, Vault).

Example Sealed Secret workflow:

• Encrypt a Kubernetes Secret into a SealedSecret.
• Commit SealedSecret YAML to the config repo.
• Argo CD applies it; controller decrypts at runtime.

4) Progressive Delivery (Canary, Blue/Green)

Use Argo Rollouts for advanced deployment strategies:

• Canary: Gradually shift traffic while monitoring metrics.
• Blue/Green: Swap traffic between stable and new versions instantly with rollback.

Example Rollout partial spec:

5) Observability

Instrument your cluster:

• Prometheus + Grafana for metrics.
• Loki for logs.
• Tempo/Jaeger for traces.

Use dashboards to observe rollout health and resource consumption on Sealos.

---

• Least privilege for CI:
  • Use a GitHub App or a minimal-scoped PAT for CONFIG_REPO_TOKEN.
  • If possible, use fine-grained PATs with repo and pull request scopes.
• Container registry:
  • Prefer OIDC/BYO credentials or the built-in GITHUB_TOKEN for GHCR.
  • Consider image signing with cosign and enforce verification via Kyverno or admission controllers.
• Cluster access:
  • Argo CD pulls from Git and requires no CI connectivity into the cluster—keep clusters private.
• Branch protection:
  • Protect main branches in both repos; require PR reviews and status checks.

---

• Argo CD application stuck OutOfSync:

  • Check the Application events: kubectl -n argocd describe app demo-dev
  • Ensure the path and targetRevision in Application specs are correct.
  • Verify that Argo CD has permission to create the target namespace.

• Image never updates:

  • Confirm the config repo PR merged and the new tag is in environments/dev/kustomization.yaml.
  • Verify Argo CD auto-sync is enabled.
  • Check the container image exists in the registry and is accessible by your cluster (pull secrets if needed).

• GitHub Action fails to create PR:

  • Ensure CONFIG_REPO_TOKEN has write permissions to the config repo.
  • Check branch protection rules and required checks.

• Kubernetes resources not created:

  • Ensure Kustomize overlays resolve correctly. Run locally:

  • Validate manifests with kubectl:

---

1. You push a change to server.js.
2. GitHub Actions builds a new image and pushes to GHCR.
3. The workflow opens a PR in the config repo to bump the dev tag to the new image.
4. You or an automated policy merges the PR.
5. Argo CD reconciles the Sealos cluster and updates dev.
6. After verification, you create a PR to bump staging, then production tags—keeping a clear audit trail of what went where and when.

No kubectl apply. No snowflake clusters. Everything is declarative, observable, and repeatable.

---

• Microservices at scale: Each service gets its own app repo and a shared config monorepo, or both split per team. Argo CD manages hundreds of Applications with app-of-apps patterns.
• Regulated environments: PR-based changes with signed commits, policies, and audit logs meet compliance requirements.
• Multi-tenant platforms: Sealos helps run isolated namespaces or tenants while keeping a unified GitOps control plane.
• Education and onboarding: New engineers learn by opening PRs rather than memorizing bespoke CLI incantations.

---

GitOps turns operations into code and code into reliable delivery. By combining Sealos for Kubernetes-based cloud infrastructure, GitHub Actions for CI, and Argo CD for CD, you get a pipeline that:

• Automates deployments end to end
• Enforces consistency with Git as the source of truth
• Simplifies promotion across environments with PRs
• Improves security, auditability, and rollback

Start small—one service, one environment—then scale to multi-service, multi-environment delivery. With your GitOps autopilot engaged, you’ll spend less time firefighting and more time delivering value.