Hanzo
ServicesPlatform

Deployment Overview

Choose an orchestrator and deploy applications from Git or a container registry.

Hanzo Platform supports three orchestration backends. Every backend uses the same container abstraction — a unified resource that maps to Kubernetes Deployments, Docker Swarm services, or Compose stacks depending on the cluster type.

Orchestrators

BackendBest ForHA SupportVolumes
KubernetesProduction workloads, autoscaling, CronJobsYesPVC with storage classes
Docker SwarmSimpler clusters, overlay networkingYes (multi-node)Named volumes
Docker ComposeSingle-node dev/staging environmentsNoBind mounts, named volumes

Container Types

The platform models every workload as a container with one of three types:

  • Deployment — Long-running services with configurable replicas, rolling updates, and horizontal pod autoscaling.
  • StatefulSet — Ordered, stable workloads with persistent volumes (databases, caches).
  • CronJob — Scheduled tasks with cron expressions, concurrency policies, and job history limits.

Source Types

Containers pull their image from one of two sources:

Connect GitHub, GitLab, or Bitbucket. On every push (or manual trigger), the platform runs a Tekton pipeline that builds a container image with Kaniko and deploys it automatically.

repo → webhook → Tekton pipeline → Kaniko build → deploy

Pull a pre-built image from any supported registry — GHCR, Docker Hub, ECR, ACR, GCR, GAR, Quay, or a private registry. Specify the image name and tag directly.

registry → pull image → deploy

Deployment Hierarchy

Every container lives inside this hierarchy:

Organization
  └── Project
        └── Environment (dev, staging, production)
              └── Container (deployment / statefulset / cronjob)

Environments can have protection levels (none, restricted, locked) and optionally require deployment approvals before changes land.

Next Steps

How is this guide?

Last updated on

On this page