Overview

Run standard Kubernetes workloads on Kupe Cloud and deliver them through managed Argo CD.

Each tenant gets its own Argo CD project, and each managed cluster is registered as a tenant-scoped destination. That gives teams a consistent delivery path across environments without introducing a custom application platform API.

Delivery model

Kupe Cloud uses a GitOps-first delivery model.

That means:

• Git is the source of truth for application configuration
• Argo CD pulls from Git and reconciles into your cluster
• drift is visible and can be self-healed
• promotion happens by changing Git, not by pushing directly into the cluster

The normal flow looks like this:

1. Define your manifests, Helm chart, or Kustomize overlay in Git.
2. Create an Argo Application that points at that source.
3. Target your tenant project and managed cluster destination.
4. Let Argo sync the workload into the cluster.
5. Validate health, routing, logs, and metrics.
6. Promote changes across environments through Git.

Core building blocks

Component	What it does
Git repository	Stores the desired state for your workload
Argo CD Application	Connects a Git source to a target cluster and namespace
Managed cluster destination	The cluster Argo deploys into, registered under a tenant-prefixed name
Kubernetes resources	The actual workloads, services, routes, secrets, and policies you run

What Kupe manages

Kupe provides the shared delivery platform around your workloads:

• Managed Argo CD control plane
• Tenant project creation and scoping
• Cluster destination registration for managed clusters
• Platform integrations for routing, certificates, logs, metrics, and secret sync

What your team manages

Your team still owns the workload definition and operating practices:

• application manifests and chart values
• namespace design
• service and route definitions
• resource requests and limits
• health probes
• promotion, rollback, and release process

What a good application setup includes

Before a workload is considered production-ready, it should usually have:

• Health probes so Kubernetes can manage startup, readiness, and recovery
• Resource requests and limits for predictable scheduling and capacity visibility
• A Service for internal traffic and an HTTPRoute for external traffic where needed
• Observability hooks such as metrics scrape annotations and structured logs
• Everything in Git so Argo can reconcile it cleanly

Common workload types

Resource	Typical use
Deployment	Stateless APIs, web services, and workers
StatefulSet	Stateful services that need stable identity or storage
Job	One-off tasks such as migrations or data processing
CronJob	Scheduled tasks such as cleanup, reports, or maintenance

Sync policy choices

Argo CD supports different sync strategies depending on how strictly you want Git to control the cluster.

Policy	Behavior	Use when
Manual sync	Changes wait for explicit approval	Higher-risk environments or stricter change control
Auto sync	Changes apply automatically when Git changes	Fast-moving development or staging environments
Auto sync + prune	Resources removed from Git are deleted from the cluster	Teams ready for strict reconciliation
Auto sync + self-heal	Manual drift in the cluster is corrected automatically	Teams that want Git to remain authoritative

Good starting points

• Deploy Applications — the practical deployment flow
• Create Argo CD Applications — connect repos and define applications
• GitOps Workflows — promotion, rollback, and drift management
• Networking Overview — expose workloads with HTTPRoute
• Observability Overview — validate health after deployment