Infrastructure Overview

# Two-cluster model

TrueFullstaq provisions two separate Kubernetes clusters for every customer:

The two clusters are deliberately separated so that the tools you depend on (your registry, your GitOps controller, your secrets backend) keep running independently of whatever you deploy on production, and so that a problem in your workloads can never take down the platform that operates them.

Throughout this documentation we use <CUSTOMER_ID> to mean your 5-digit customer ID (for example 01234). Every service you reach has a hostname built from it.

# Your customer ID and hostnames

All of your services live under <CUSTOMER_ID>.truefullstaq.cloud. Using 01234 as an example:

# The dashboard (CIK)

Your starting point is the Customer Interface (CIK) dashboard at https://dash.<CUSTOMER_ID>.truefullstaq.cloud. From there you can:

• See all services provisioned for you, each with a direct link.
• Download the kubeconfig for your production cluster(s).

See Using kubectl for the kubeconfig workflow.

# Service cluster

The service cluster hosts the tooling that supports your production workloads:

• ArgoCD + Argo Workflows: GitOps continuous delivery. ArgoCD syncs manifests from your Git repositories to the production cluster. Argo Workflows runs CI/CD jobs (such as build pipelines) when you need them. See CI/CD with ArgoCD.
• Harbor: Your private container registry, with built-in CVE scanning. See Container Registry.
• OpenBao: Your secrets backend (an open-source Vault). Secrets live here, never in Git. See Secrets Management.

# Production cluster

This is where your applications run:

• You deploy here through ArgoCD (running on the service cluster) using the app-of-apps pattern; see CI/CD with ArgoCD.
• The External Secrets Operator runs here and pulls secrets from OpenBao on the service cluster, materialising them as native Kubernetes Secrets. See External Secrets Operator.
• Networking is handled by Cilium (it is the CNI and also the Gateway API implementation). Traffic between workloads can be locked down with network policies; see Network Policies.
• Each production cluster has a name like cid<CUSTOMER_ID>-cl02 and a public Kubernetes API endpoint on port 6443.

# How you access everything

You do not manage long-lived static credentials for cluster access; kubectl logs you in through SSO on demand. See Access Control for the full picture.