GitOps Deployment Pipeline: Self-Hosted ArgoCD on Kubernetes

Most GitOps tutorials assume a managed cloud Kubernetes cluster with built-in load balancers, IAM-based container registry access, and ready-made secret management. In a real self-hosted GitOps pipeline setup, you get none of that for free.

This guide covers everything, including deploying a bare-metal Kubernetes cluster with ArgoCD, MetalLB, NGINX Ingress, app-of-apps GitOps, encrypted secrets, and secure WireGuard connectivity. All tuned for a production-ready self-hosted GitOps pipeline setup.

A self-hosted GitOps pipeline setup gives you full control over your servers, your budget, and where your data lives. Instead of relying on a cloud provider’s control plane, you run Kubernetes clusters on dedicated machines you own or rent from a provider you trust.

On bare metal, you store all infrastructure, add-ons, and application configs in Git, and ArgoCD keeps your cluster in sync with that repository. This continuous sync is the core idea behind any self-hosted GitOps pipeline setup.

If you need reliable hardware for Kubernetes and GitOps, you can run this self-hosted GitOps pipeline setup on high-performance dedicated servers built for self-managed DevOps workflows.

Before you start, make sure to have the prerequisites ready for a self-hosted GitOps pipeline setup:

• One or more dedicated servers running Ubuntu 22.04 or newer.
• Kubernetes cluster, kubeadm or k3s, up and running, with kubectl configured.
• Static IPs and a routable LAN segment for MetalLB.
• Git repository, GitHub, GitLab, Gitea, etc., for your GitOps manifests.

Note: For GPU workloads inside the same self-hosted GitOps pipeline setup, you can consider dedicated GPU servers optimized for Kubernetes and AI/ML hosting.

If your cluster isn’t ready yet, you can follow the steps below to set up Kubernetes on bare-metal for a reliable self-hosted GitOps pipeline setup.

First, make sure the node has the right kernel networking settings and swap disabled so kubeadm’s preflight checks pass:

Then enable bridge netfilter and IP forwarding, which Kubernetes needs to route pod traffic:

Install Kubernetes components:

Then, use the command below to initialize the Kubernetes control plane and set the IP range for pod networking in the cluster:

Configure kubectl for your user:

You must install a CNI plugin such as Flannel by applying the kube-flannel.yml manifest, which sets up pod networking across all nodes in your cluster:

Finally, you must run the command below on each worker node so it can connect to the control plane and become part of the Kubernetes cluster:

Once nodes are ready, you have a solid base for your self-hosted GitOps pipeline setup.

MetalLB is what makes LoadBalancer services work on bare-metal, which is a critical component of a self-hosted GitOps pipeline setup.

You can install the native manifests with:

Then, configure the IP pool and L2 advertisement. Pick a free IP range from your LAN for this self-hosted GitOps pipeline setup:

Now, any LoadBalancer service in your self-hosted GitOps pipeline setup will receive a real IP from this pool.

For a deeper MetalLB bare-metal load balancing setup, check the full MetalLB guide for bare-metal Kubernetes.

NGINX Ingress is the component that routes external HTTP/HTTPS traffic into services running inside your cluster. In a self-hosted GitOps pipeline setup on bare metal, you don’t get a cloud ingress or load balancer by default, so you can install NGINX Ingress yourself and expose it via a LoadBalancer service backed by MetalLB.

Check the service:

You should see an EXTERNAL-IP assigned by MetalLB, which becomes the main entrypoint for HTTP/HTTPS traffic.

ArgoCD is the GitOps engine that keeps your cluster in sync with what’s defined in Git. In this step, you’ll install the latest stable ArgoCD release on your Kubernetes cluster so your self-hosted GitOps pipeline setup can continuously apply and reconcile manifests from your Git repository.

Once ArgoCD is running, every change you push to Git can be safely rolled out to your bare-metal cluster with full visibility and automated rollback.

Create namespace and apply stable install manifest:

Wait for deployments/pods to be available:

This gives you a current ArgoCD release suitable for a robust self-hosted GitOps pipeline setup. For HA, you can use ha/install.yaml in the same repository.

By default, argocd-server is ClusterIP. For initial configuration, use port-forwarding:

Open https://localhost:8080 in your browser. Get the admin password:

Username is admin. Log in, and you’re inside the control plane of your self-hosted GitOps pipeline setup.

For more detailed information about ArgoCD installation, check the official ArgoCD Docs.

For long-term operations, you must expose ArgoCD via NGINX Ingress rather than NodePort.

Here is an example argocd-ingress.yaml file:

Apply it with:

Point argocd.example.com to the MetalLB IP of ingress-nginx. Now your self-hosted GitOps pipeline setup serves ArgoCD securely over HTTPS.

For fast operations in a self-hosted GitOps pipeline setup, you can install the ArgoCD CLI from the latest release:

Use argocd login with your ingress or port-forward endpoint to manage applications:

The app-of-apps pattern is a way to structure your Git repository so one ArgoCD Application can manage many other Applications. This makes your self-hosted GitOps pipeline setup easier to set up, easier to grow, and much simpler to keep consistent across environments.

Suggested layout includes:

This structure makes Git the single place where you define everything in your self-hosted GitOps pipeline setup, such as your core infrastructure, extra add-ons, and all application workloads.

Root app-of-apps Application:

This is the entry point for your GitOps setup. You define it in clusters/prod/root-app.yaml inside your Git repo, and it tells ArgoCD to manage everything under clusters/prod/ as a group of child applications. When you sync this root app, ArgoCD automatically creates and updates all the other apps and infrastructure pieces in your self-hosted GitOps pipeline setup.

In a self-hosted GitOps pipeline setup, image pulls often hit a self-hosted registry without IAM integration. You must declare registry credentials explicitly.

Create the secret:

Reference it in your workload manifest stored in Git:

ArgoCD syncs this, and your pods can pull private images.

Because your self-hosted GitOps pipeline setup doesn’t necessarily include a managed secret store, SOPS lets you safely keep secrets in Git.

1. Install SOPS locally and pick a key backend, age, or GPG.
2. Write Kubernetes Secret manifests with plaintext values.
3. Run sops -e secret.yaml > secret.enc.yaml and commit the encrypted file.
4. Deploy a SOPS-aware controller, such as ksops, sops-operator, or a Helm plugin, in your cluster.

When ArgoCD syncs, it applies the encrypted secret manifests, the SOPS controller decrypts them, and the workloads get their secrets, all while your self-hosted GitOps pipeline setup stays fully defined in Git and easy to review.

On bare-metal Kubernetes, you don’t get cloud storage classes or managed disks. To run databases and other stateful apps in a self-hosted GitOps pipeline setup, you must define your own StorageClasses and PersistentVolumes so the cluster knows where and how to create data volumes.

For single-node or simple lab setups:

Save this YAML as infra/storageclass/local-path-sc.yaml in your Git repo, and let ArgoCD deploy it through an infra-storage-app Application. Then any PVC that uses storageClassName: local-path will get local disk, so your stateful apps are fully supported in your self-hosted GitOps pipeline setup.

For clusters with multiple nodes, use shared storage like NFS or Ceph/Rook, and manage its configuration in Git as part of your self-hosted GitOps pipeline setup.

If your cluster is on a private network, your self-hosted GitOps pipeline setup still needs a secure way to reach the Git server. Headscale, a self-hosted Tailscale control server, lets you do that using access rules and an encrypted WireGuard network.

Typical approach:

• Deploy Headscale and join Kubernetes nodes and the Git server/VM as clients.
• Use Headscale ACLs to restrict which IPs can reach Git.
• Write Kubernetes NetworkPolicy objects to allow egress from argocd namespace to Headscale IP ranges and block other outbound access.

If you want a full setup of deploying Headscale as your self-hosted mesh VPN control plane, check this guide on self-hosting Headscale on Ubuntu, including TLS, reverse proxy, and client setup.

Now you must wire ArgoCD to the Git repository that defines your self-hosted GitOps pipeline setup.

Register HTTPS repository:

Register SSH repository:

Create root app from CLI:

Sync it:

Use ArgoCD’s automatic sync and self-heal features with health checks so your self-hosted GitOps pipeline setup can recover quickly from bad deployments.

In Application specs for critical workloads:

ArgoCD keeps checking whether your resources are healthy, and if a new change breaks things, it automatically goes back to the last working version. That way, your self-hosted GitOps pipeline setup can stay reliable.

Building a modern self-hosted GitOps pipeline setup on bare-metal or dedicated servers means solving things that cloud Kubernetes usually does for you. Such as load balancing without a cloud LB, storage classes without cloud disks, private registry access without IAM, and secure Git access without a managed service mesh.

By using ArgoCD, MetalLB, NGINX Ingress, SOPS, and Headscale/WireGuard together, you get a Git-driven, health-checked, fully self-managed GitOps pipeline setup that’s ready for production.

We hope you enjoy this guide.