Do we need Kubernetes, or is Docker enough?

Docker is enough when one or two services run on a managed platform that already restarts them. Kubernetes earns its place when you have several services, environments, and a need for controlled rollouts. We will say so if a cluster would be overhead.

Which Kubernetes do you target?

Amazon EKS, a managed cluster you already run, or a local cluster for development. The manifests stay portable. Cloud-specific pieces — load balancers, storage classes, IAM — stay in a thin overlay.

How do you handle secrets?

Not in the image. Runtime config and secrets come from the platform’s secret store or sealed values in Git. Images are built from locked dependencies.

What does a healthy workload include?

A non-root process where possible, CPU and memory requests, liveness and readiness probes, and a rollout that can pause or undo. Logs go to the platform you already watch.

How do you size clusters?

From real request and job profiles — CPU/memory requests, HPA where useful, and non-prod that is intentionally smaller. We avoid copying production node counts into staging by default.

Do you handle image registries and scanning?

Images land in ECR or Harbor with vulnerability scans in CI. Digests are promoted; rebuilds for each environment are avoided.

How do you handle secrets in Kubernetes?

External secrets or sealed/managed secret stores — never layers in the image. Access is RBAC-scoped and audited.

When is Docker Compose enough?

Local parity and simple single-host deploys. When you need multi-service scheduling, self-healing, and progressive delivery, we move to Kubernetes.

CONTAINERIZED DELIVERY

Docker & K8s

From laptop to cluster.

Zupitrix packages services as Docker images and runs them on Kubernetes when you need several environments, rollouts, and a cluster your team can operate. Health checks, config, and resource limits are part of the workload — not a note in a README.

Start Project

ImageBuilt once in CI

PodProbes and limits

ReleaseRolling update

GitOpsDesired state in Git

ObsMetrics + dashboards

Manifest

Images and Kubernetes workloads that run the same way in CI, staging, and production.

One image, promoted

CI builds the image. Staging and production run that digest. We do not rebuild with different flags per environment. We document the approach, name owners, and attach acceptance checks so “One image, promoted” is reviewable in demos and durable after handoff.

Config outside the image

Environment-specific values and secrets are injected at runtime. The Dockerfile stays boring. We document the approach, name owners, and attach acceptance checks so “Config outside the image” is reviewable in demos and durable after handoff.

Probes that match the app

Readiness means the process can serve traffic. Liveness means it should be restarted. They are not the same check copied twice. We document the approach, name owners, and attach acceptance checks so “Probes that match the app” is reviewable in demos and durable after handoff.

Rollouts with a way back

Deployments can pause and undo. Database migrations are called out when they are not backward compatible. We document the approach, name owners, and attach acceptance checks so “Rollouts with a way back” is reviewable in demos and durable after handoff.

Cargo

What we containerize

Docker images

Small, reproducible images for Node, Python, and web apps, built in CI. We document the approach, name owners, and attach acceptance checks so “Docker images” is reviewable in demos and durable after handoff.

Kubernetes workloads

Deployments, services, ingress, and resource settings for the environments you run. We document the approach, name owners, and attach acceptance checks so “Kubernetes workloads” is reviewable in demos and durable after handoff.

Local parity

A compose or local cluster path so engineers can run the same process shape before it hits the cluster. We document the approach, name owners, and attach acceptance checks so “Local parity” is reviewable in demos and durable after handoff.

Conveyor

01
Process
What the app needs: ports, files, env, and a health URL. Exit criteria and owners are written down before the next step starts.
02
Image
Dockerfile and a CI build that publishes a digest. Exit criteria and owners are written down before the next step starts.
03
Workload
Manifests with probes, limits, and config. Exit criteria and owners are written down before the next step starts.
04
Promote
The same image moves from staging to production. Exit criteria and owners are written down before the next step starts.
05
Harden
Validate budgets, failure modes, observability, and rollback before traffic. Exit criteria and owners are written down before the next step starts.
06
Handoff
Runbooks, access, and training so the client team can operate without us. Exit criteria and owners are written down before the next step starts.

Images

Docker
Kubernetes
Helm
GitHub Actions
EKS
NGINX Ingress
Prometheus
Grafana

Ports

Kubernetes Orchestration
Cluster platform work beyond a single app. Share the journeys and constraints and we will map whether this engagement is the right fit.
CI/CD Pipelines
The pipeline that builds and promotes the image. Share the journeys and constraints and we will map whether this engagement is the right fit.
Infrastructure as Code
Cluster and cloud resources described in code. Share the journeys and constraints and we will map whether this engagement is the right fit.

Outcomes

What we optimize for

Product and engineering goals we keep visible from the first slice through handoff — so velocity never quietly trades away quality.

1 imageBuilt in CI

ProbesReady ≠ live

PromoteSame digest forward

GitOpsDesired state in Git

QuotasNo noisy neighbors

ScannedImages in CI

At a glance

Delivery facts

Typical timelines, coverage, and operating constraints we set expectations against before the build surface expands.

Topic	Value	Note
Containerize	≤1 week	Typical service. Tracked against Docker & Kubernetes delivery milestones.
K8s decision	When multi-service	Or strict ops needs. Tracked against Docker & Kubernetes delivery milestones.
Image rule	Build once	Promote digest. Tracked against Docker & Kubernetes delivery milestones.
Probes	Split	Ready ≠ live. Tracked against Docker & Kubernetes delivery milestones.
Delivery	GitOps/CI	No laptop apply. Tracked against Docker & Kubernetes delivery milestones.
Scan	CI gate	Critical blocked. Tracked against Docker & Kubernetes delivery milestones.

Ecosystem

Technologies that sit beside it

Real stack partners we wire into delivery with clear roles — not decorative logos on a slide.

Docker

Images — integrated deliberately into delivery with Docker.

Kubernetes

Orchestration — integrated deliberately into delivery with Kubernetes.

Helm

Packaging — integrated deliberately into delivery with Helm.

NGINX

Ingress — integrated deliberately into delivery with NGINX.

Prometheus

Metrics — integrated deliberately into delivery with Prometheus.

Grafana

Dashboards — integrated deliberately into delivery with Grafana.

GitHub Actions

Build & promote — integrated deliberately into delivery with GitHub Actions.

Argo CD

GitOps — integrated deliberately into delivery with Argo CD.

AWS EKS

Managed K8s — integrated deliberately into delivery with AWS EKS.

Redis

App dependency — integrated deliberately into delivery with Redis.

PostgreSQL

Stateful data — integrated deliberately into delivery with PostgreSQL.

Terraform

Cluster IaC — integrated deliberately into delivery with Terraform.

Integrations

Systems we commonly connect

CMS, identity, commerce, analytics, and edge services joined with typed contracts, webhooks, and ownership — not ad-hoc glue.

GitHub Actions

Build images — integrated deliberately into delivery with GitHub Actions.

AWS ECR

Registry — integrated deliberately into delivery with AWS ECR.

cert-manager

TLS — integrated deliberately into delivery with cert-manager.

NGINX Ingress

Ingress — integrated deliberately into delivery with NGINX Ingress.

Sentry

App errors — integrated deliberately into delivery with Sentry.

Terraform

Cluster — integrated deliberately into delivery with Terraform.

Architecture

Layers we design explicitly

Boundaries, ops knobs, and rollback policy for each layer — so one team can change without rewriting everything.

Build

CI builds, scans, pushes digest.

Dockerfile
Trivy
Registry

Package

Helm/Kustomize values per env.

Helm
Kustomize
Secrets

Deliver

GitOps or pipeline apply.

Argo CD
Actions
Promote

Run

Deployments, jobs, probes, HPA.

Pods
Services
HPA

Observe

Metrics, logs, alerts.

Prom
Grafana
Logs

Capabilities

What we actually deliver

Concrete workstreams with owners, acceptance checks, and a path for your engineers to extend after handoff.

Reproducible images

Built once in CI; digests promoted — not rebuilt per env.

Health that matches the app

Readiness and liveness are different checks on purpose.

Config outside the image

Secrets and env injected at runtime.

Resource governance

CPU/memory requests so noisy neighbors do not win.

Ingress & TLS

Traffic entry with certificates and routing rules.

Observability hooks

Metrics and logs to the platform you already watch.

GitOps workflows

Desired state in Git with PR review.

Namespace tenancy

Teams isolated with quotas and network policies.

Job & cron patterns

Finite workloads with backoff and history limits.

Patterns

Approaches we reach for

Reference implementations and conventions in the repo — so reviews reject one-off variants that bypass the agreed shape.

Build once, promote often

Environment differences are config, not rebuilds.

Reference implementation of “Build once, promote often” lives in the repo, not only slides.

Readiness vs liveness

Wrong probes cause thrash — we separate them.

Reference implementation of “Readiness vs liveness” lives in the repo, not only slides.

Requests before limits

Scheduler needs honest requests.

Reference implementation of “Requests before limits” lives in the repo, not only slides.

Secrets as references

Not layers in the image.

Reference implementation of “Secrets as references” lives in the repo, not only slides.

Git as control plane

Cluster state is reviewable.

Reference implementation of “Git as control plane” lives in the repo, not only slides.

Namespace budgets

Quotas keep multi-team clusters fair.

Reference implementation of “Namespace budgets” lives in the repo, not only slides.

Industries

Domains we apply this in

Same technical playbook, different module depth — regulation, uptime, and partner APIs baked in early.