03 / 06
Discipline
Platform & DevOps
Everything between the code working on a laptop and the system running, unattended, where your business needs it to run. Containers, deployment pipelines, environments, background job processing, caching, event streaming, monitoring, and the recovery plan that exists before it is needed.
If your software currently reaches production because a person follows a document, or because a person remembers, this is the discipline that fixes it.
Approach
Positions we hold
How we approach it.
Kubernetes or a server on a mine site, same discipline
The industry treats cloud as the real deployment target and on-premises as a concession made for awkward customers. That framing is why on-premises installs are so often a forked codebase, a manual install and a support burden that poisons the product.
One platform we run deploys as a multi-tenant cloud service and as a genuine on-premises installation from one architecture and one release cycle. At the other end of the same discipline, a documented path to one hundred thousand tenants on Kubernetes.
Deploy through a pipeline
No manual ad-hoc steps into production. A deployment is a pipeline run with a quality gate in front of it, a verified backup behind it, a rollback plan written before it starts, and a smoke check after it finishes.
One of the systems we run deploys to live production straight from GitHub Actions, which is defensible only because all of the above is true of it. Manual deployment makes every release a performance by one person, and that person eventually leaves or has a bad day.
Environments that resemble production
A QA environment that differs from production in configuration generates false confidence. We provision development, staging, and UAT to match production in the ways that matter, prepare and where necessary anonymise test data, and validate readiness with smoke tests before anyone tests against them.
Observability sized to the system
Most systems we are asked to run do not need a full observability platform, and installing one is often a way of spending money to feel serious. What they need is structured logs that can be searched, alerts on the few conditions that actually indicate a problem, and a recorded answer to how anyone would know if this stopped.
Alerts that fire constantly are worse than no alerts. A team that has learned to ignore its monitoring is worse off than one that never had any.
Recovery is a number
Ask what your recovery time is and you should get a figure somebody measured, not a statement that backups are configured. We restore into an isolated environment on a schedule, record what it took, and update the recovery plan with whatever the exercise exposed. It always exposes something.
Where we stop
We are not a managed security provider. We apply the security practices a competent engineering team should, and where an engagement needs penetration testing or a formal certification we will say so rather than approximating it.
Stack
What actually runs in production.
Docker
Kubernetes
GitHub Actions
Continuous deployment
Kafka
Redis
Azure
AWS
Fly.io
EAS
On-premises deployment
Engagements
Typical shapes this takes.
Getting a system onto a pipeline
Build, test gate, deploy, rollback, smoke check. A small number of weeks, and one of the highest-value pieces of work available to a team that has never had it.
An on-premises variant of a cloud product
Making an existing platform deployable on customer hardware without forking it. Scope depends on how much cloud-specific assumption is baked in.
Platform ownership on a retainer
Environments, pipelines, monitoring, backups, patching, and recovery, ongoing.
Deliverables
What you get.
A pipeline anyone can run
And nobody has to be brave about.
Reproducible environments
Documented, and matching production where it matters.
A rollback plan per release
Written before the deployment starts.
A tested restore time
Measured, recorded, and re-tested on a schedule.
A current runbook
How the system is deployed, monitored and recovered.
Accounts in your name
Hosting and infrastructure yours throughout, with your access.
Reading
Related reading.
The strongest seam here is shipping cloud and on-premises from one architecture, and what it costs to keep that true. Those pieces will be linked here as they are published.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·