---
title: "DevOps & infrastructure"
description: "Pragmatic infrastructure, CI/CD, observability, and on-call setup, sized for e-commerce, built to reduce production incidents."
language: "en"
canonical: "https://zapolu.com/services/devops/"
---

# DevOps & infrastructure

We design and operate the infrastructure that runs e-commerce
stores, without introducing a Kubernetes cluster that requires a
dedicated senior SRE to operate.

## When this fits

- A shop running on a single VPS that fails during every sale or campaign launch
- Deploys that take 40 minutes, fail silently, or depend on one engineer who knows the script
- No way to establish why last Thursday's checkout was slow, because there are no logs and no metrics
- Compliance requirements (PCI, GDPR audit trail) that now demand documented answers
- A founder or CTO who is the de-facto on-call engineer, Black Friday nights included

## What we do

- **Cloud and edge infrastructure.** Cloudflare, AWS, GCP, Hetzner, or
  bare metal; we pick the stack that fits the workload.
- **CI/CD pipelines** on GitHub Actions or GitLab CI, with reproducible
  builds, reversible deploys, and secrets that aren't in the repo.
- **Observability:** logs, metrics, and traces via Grafana,
  OpenTelemetry, Sentry, or Cloudflare Logpush. You should be able to
  answer "what happened at 14:32 last Tuesday" in under a minute.
- **Performance and cost.** Edge caching, image CDN, autoscaling tuned
  for campaign spikes, and a cost review that often pays for the
  engagement.
- **Incident response:** runbooks, alerting that doesn't raise false
  alarms, and a post-mortem culture that turns a night-time incident
  into a fix shipped the following week.
- **Security baseline.** Secrets management, dependency scanning, image
  signing, network policies, and the routine patching that keeps known
  exploits out of your shop.

We default to the simplest setup that will do the job.

## Incidents we've handled

A sample from production systems we've operated over the years:

- Memory dashboards stayed flat while the application leaked, because
  the metrics agent was watching the process manager instead of the
  app it spawned. Diagnosed with process-tree forensics and a read of
  the agent's source; fixed with a small init wrapper that also made
  shutdowns clean.
- Recurring "maintenance mode" outages that were really the cache
  layer running out of transient memory, made worse by an
  auto-updating "stable" image tag that changed the deployed software
  without notice. Pinned versions and an overhauled VCL brought the
  hit rate from 4% back to a healthy level.
- CI agents were being OOM-killed mid-job, which silently froze the
  shop's indexer state machine and stopped stock updates. We
  reproduced the failure deliberately on staging, then rebuilt the
  scheduled-job layer with per-group isolation and self-healing
  resets.
- An entire country's frontend cache could not be invalidated because
  of a one-word namespace typo in the purge-host list. Fixed live
  with manual cache bans, then permanently in configuration.
- A client environment was deleted by mistake, with no logical
  backups. We restored it from hypervisor snapshots through a
  forced InnoDB recovery across a major MySQL version jump.

The underlying practice: alerts on business invariants, such as "every
order reaches the ERP within 15 minutes", not just on error rates.
Several of the incidents above were caught by exactly that kind of
probe before any customer noticed.

## How an engagement usually starts

Much of this work arrives inside another engagement: an audit that
traces the bottleneck to the hosting, or a build that needs a deploy
pipeline before anything can ship. For standalone infrastructure work,
we start with a short review of what runs where, what it costs, and
what breaks first under load, and put the recommended changes in
writing with a fixed price. Ongoing operation runs as a monthly
retainer with named hours, on the terms described on
[How we work](/how-we-work/).