cloudwarrior CloudWarrior, home

EN is the active language PL · Polish version of this page

Cloud platform

Clusters that hold. Releases that repeat.

Platform work from the shape of the cluster to the pipeline that puts code in front of users, with the rollback path exercised rather than assumed.

Start a conversation Request the 48-hour audit

What the work covers

  1. Cloud platform and Kubernetes

    Production clusters, release pipelines, and the discipline around them: rollbacks, observability, cost control. Cluster topology is sized against the load the product actually sees rather than a reference diagram. Namespaces, quotas, and network boundaries are set once and described in code, so the next change is a review instead of an excavation.

    Production Kubernetes cluster topology A client request enters through a load balancer and an nginx ingress that terminates TLS, then a ClusterIP service resolves it to pods across two node zones, while the control plane reconciles separately and PostgreSQL with its replica and object storage sit outside the cluster boundary. control plane reconciles desired state kube-apiserver scheduler controller-manager etcd kubelet clients load balancer ingress-nginx service https · dns l4 · public ip tls · host rules endpointslice node pool node · zone a node · zone b pod · api pod · api pod · api pod · web spread · pdb · hpa request path cluster boundary postgresql postgresql object storage primary · single writer read replica · async wal archive · backups reads · writes state lives outside wal archive Production Kubernetes cluster topology A client request enters through a load balancer and an nginx ingress that terminates TLS, then a ClusterIP service resolves it to pods across two node zones, while the control plane reconciles separately and PostgreSQL with its replica and object storage sit outside the cluster boundary. control plane api · scheduler · etcd request path clients ingress-nginx service pods https · dns tls · host rules clusterip node pool · pdb cluster boundary postgresql object storage primary · read replica wal archive · backups archives

  2. CI/CD and infrastructure as code

    Environments described in code and releases that stop being events. Repeatable delivery instead of remembered steps. Every environment is reproducible from the repository, every change arrives through a pipeline that can be read, and every deploy has a rollback that has been run at least once before it was needed.

    Delivery pipeline from commit to production A commit runs through build, a blocking test gate, image build with vulnerability scanning, a signed digest in the registry, and a canary rollout, and when the health gate fails the highlighted return edge redeploys the previous digest instead of leaving the release in place. commit build test image registry rollout healthy? production main branch reproducible unit · e2e distroless digest pin helm upgrade tag · sha sbom integration trivy scan signed canary prometheus · alerts healthy fail · halt cve · halt rollback · previous digest unhealthy Delivery pipeline from commit to production A commit runs through build, a blocking test gate, image build with vulnerability scanning, a signed digest in the registry, and a canary rollout, and when the health gate fails the highlighted return edge redeploys the previous digest instead of leaving the release in place. commit build · test image · registry rollout production main branch fails closed signed digest canary · health alerting rollback

  3. Cost and reliability

    A read of where the cloud bill actually goes, where the platform is fragile, and what to fix in which order. Capacity is sized against measured load, and the invoice is broken down by service and by cause before anything is switched off.

Who this is for

Product teams running on cloud without a platform team of their own, and teams where every deploy still depends on the person who knows the sequence.

Work starts wherever the pressure already is: a cluster nobody can reason about, a deploy nobody wants to run on a Friday, or an invoice that has outgrown the traffic behind it.

Stack in use

Infrastructure as code

  • Terraform
  • Pulumi
  • Ansible

Delivery

  • GitHub Actions
  • GitLab CI
  • Azure DevOps

Containers

  • Kubernetes
  • AKS
  • EKS
  • GKE
  • Docker
  • Helm

Observability

  • Grafana
  • Prometheus
  • Loki
  • Alertmanager

Cloud

  • AWS
  • Azure
  • Google Cloud
  • DigitalOcean

Security

  • Vault
  • Trivy
  • Falco
  • OPA

Where this goes next

Free 48-hour infrastructure audit

The form takes three answers. What comes back within 48 hours is a written read of the platform: where the spend concentrates, what fails first, and the order to fix it in. No call is required to receive it.

What comes back

  • Where the cloud spend concentrates, by service and by cause.
  • The failure modes that would bite first under load or on call.
  • A remediation order: what to fix now, what can wait, what to leave alone.
  • A straight no when the fit is wrong, with a name from the wider network instead.
Turnaround
Within 48 hours
Format
Written findings
Charge
None
Next step
Only if asked for

Request the audit

Where the findings land.

Used to place the platform in context.

Cost, reliability, release speed, on-call load. Two sentences is enough.

Answers are used to reply to this request and nothing else. No list, no sequence. Privacy.

Scripts are off, so this form cannot hand the request on. The same three answers work as plain mail: address, company, and what is going wrong right now. Write to pat@cloudwarrior.io.

Or write straight to pat@cloudwarrior.io.

Contact

Bench open · Remote across the EU