Skip to content
Kupe Cloud Kupe Cloud Kupe Cloud Docs

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

Section titled “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

Section titled “Core building blocks”
ComponentWhat it does
Git repositoryStores the desired state for your workload
Argo CD ApplicationConnects a Git source to a target cluster and namespace
Managed cluster destinationThe cluster Argo deploys into, registered under a tenant-prefixed name
Kubernetes resourcesThe actual workloads, services, routes, secrets, and policies you run

What Kupe manages

Section titled “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

Section titled “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

Section titled “What a good application setup includes”

Before a workload is considered production-ready, it needs health probes, resource requests and limits, a Service (and an HTTPRoute if it takes external traffic), and enough metrics or logs to tell whether it’s actually working. See Deploy Applications for the full checklist and a working example.

Common workload types

Section titled “Common workload types”
ResourceTypical use
DeploymentStateless APIs, web services, and workers
StatefulSetStateful services that need stable identity or storage
JobOne-off tasks such as migrations or data processing
CronJobScheduled tasks such as cleanup, reports, or maintenance

Sync policy choices

Section titled “Sync policy choices”

Argo CD supports several sync strategies, from fully manual to auto-sync with self-heal, depending on how strictly you want Git to control the cluster. See GitOps Workflows for the full comparison and when to use each one.

Good starting points

Section titled “Good starting points”