DarDev standardizes on Kubernetes for products we operate ourselves and for selected client platforms because it gives us one declarative runtime—from GitLab CI image to staging namespace to guarded production promote—without rewriting deployment logic every time a service count grows past three. We are not Kubernetes maximalists: when a workload is a single VPS, a cron job, or a team of two without platform skills, we recommend Docker Compose, a managed PaaS, or even bare systemd before we sell a cluster.
DarDevOps is our Kubernetes and CI/CD practice. The same patterns that run DarDevLab learning environments, our unified mailer stack on dardev-vps, and client production overlays are documented in Deployed Realities articles—not slideware. This guide explains why we chose the default, where it pays off, and the cases where we actively steer teams away from it.
What we actually run on Kubernetes
Internally, Kubernetes is the target runtime for multi-service products: API plus worker plus Postgres sidecar patterns, ingress with TLS, secrets rotation, and observability hooks. Our mailer stack—Twenty CRM, Listmonk, Stalwart MTA, sync worker—uses Compose on a single VPS for cost and simplicity in production today, but the same services ship through Kubernetes overlays for staging and for clients who need namespace isolation or multi-region expansion. Subdomain boundaries (crm.dardev.net, mail.dardev.net, send.dardev.net for outbound) live in git; the cluster reconciler applies them.
- Stateless web APIs and background workers with horizontal scale
- GitLab CI deploy targets with namespace-scoped RBAC—not cluster-admin tokens
- Staging namespaces that mirror production topology before promote
- Prometheus and Grafana scraping pod metrics and deploy annotations
- Client SaaS where uptime, rollback, and audit trails justify ops overhead
How DarDevLab and internal platform services map to clusters is covered in Internal platform: how DarDevOps runs DarDevLab. The delivery path from commit to production—Authorize, Develop, Deploy, Observe—is the subject of Building a Kubernetes-native product pipeline.
Why Kubernetes fits our client work
Consulting engagements that grow into platforms—fintech APIs, B2B SaaS, data pipelines with scheduled jobs—benefit when deployment, scaling, and failure recovery share one vocabulary. Kubernetes gives teams declarative manifests in git, rolling updates with kubectl rollout undo, and health probes that CI can gate on before production. For MENA teams weighing cloud control planes versus self-managed masters, we document trade-offs in Choosing managed K8s vs self-hosted in MENA rather than pretending one vendor fits every regulator and budget.
We also standardize because hiring and handoffs get easier. A platform engineer who understands Deployments, Services, Ingress, and Secrets can join a DarDev engagement or an alumni client team without learning a bespoke orchestrator. Runbooks reference the same objects whether the cluster runs on OVH, a hyperscaler region, or on-prem hardware the client already owns.
When we tell teams not to use Kubernetes
Honesty keeps trust. We decline or defer Kubernetes when the problem does not yet justify the operational tax. A marketing site on static files, a single Postgres with one app container, or a batch ETL that runs twice a day does not need a control plane, etcd backups, and CNI upgrades. In those cases Docker Compose on one or two VMs, Render, Fly.io, or a managed database plus serverless functions often ship faster and cost less until traffic or compliance forces a split.
- Team size under roughly three engineers with no dedicated platform owner
- No requirement for zero-downtime rolling deploys or autoscaling beyond vertical resize
- Regulatory mandate for air-gapped single-node installs where K8s adds complexity without isolation benefit
- Budget that cannot cover managed control plane or 24/7 on-call for self-hosted masters
- Early product stage where pivoting weekly matters more than multi-tenant hardening
We have migrated clients off over-engineered clusters back to Compose when their roadmap stalled and monthly cloud bills exceeded product revenue. That is a success: the goal is reliable software, not YAML volume. Kubernetes becomes the right default when release frequency, service count, or compliance evidence (who deployed what, when, with which image digest) crosses a threshold your team feels in incident postmortems.
How we decide before recommending a cluster
Our pre-engagement checklist is boring on purpose. We inventory services, deployment frequency, RTO/RPO expectations, and existing skills. If the answer to “what happens when this node dies?” is shrug, we fix backups and monitoring before we install kubeadm. If GitLab CI already builds images but production deploy is SSH and docker pull, we pilot namespace-scoped deploy to staging first—matching the health gates in our product pipeline guide—before production RBAC.
- Count moving parts
List every process that must stay up for customers to succeed. One process suggests Compose; five with different scale curves suggests K8s.
- Name an owner
Someone must own cluster upgrades, cert expiry, and on-call runbooks. Without that role, managed K8s or PaaS is safer than self-hosted.
- Prove staging fidelity
Staging must share ingress, TLS, and data store major version with prod. Otherwise you are not testing Kubernetes—you are testing hope.
- Measure promote time
Track commit-to-production lead time and rollback count. Justify the cluster when manual deploys cause measurable outages or audit gaps.
DarDev dogfoods these decisions on our own stacks before prescribing them. When Kubernetes wins, we document manifests, CI jobs, and observability in client repos—not a PDF that rots. When it loses, we say so in the proposal.
What we will not claim
- That every DarDev product runs on K8s in production today—some intentionally stay on Compose
- That Kubernetes reduces headcount on day one—it shifts work from SSH to platform engineering
- That managed clusters eliminate ops—they eliminate control-plane toil, not application SLOs
- Custom uptime percentages or customer counts we cannot verify publicly
Platform overview and engagement scoping: dardev.net/products. Browse related DarDevOps guides on news.dardev.net and subscribe for product updates—we route contact forms to Twenty CRM, not a black-hole inbox.
Does DarDev run everything on Kubernetes today?
No. Multi-service products and client platforms target Kubernetes—especially staging and regulated prod—but some internal stacks deliberately stay on Docker Compose on a VPS when cost and complexity favor simplicity. We document both.
When is Docker Compose enough?
When you have one or two containers, a single host, infrequent deploys, and no autoscaling requirement. Compose plus proper backups and monitoring beats a neglected cluster.
Managed Kubernetes or self-hosted in MENA?
Depends on data residency, budget, and who wakes up at 3 a.m. for etcd. We compare options in our managed vs self-hosted MENA guide—there is no universal winner.
How does this relate to GitLab CI?
Kubernetes is the runtime; GitLab CI is how images get built and promoted. Namespace-scoped deploy tokens and health gates connect the two—see the Kubernetes-native product pipeline article for the full flow.
Can DarDev help us decide?
Yes. DarDevOps engagements start with workload inventory and honest fit assessment. We recommend clusters only when the checklist above says the ops tax is worth paying.
