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 store running on a single VPS that fails during every sale or campaign launch
• Deploys that are slow, 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 of what you are actually paying for.
• Incident response: runbooks, alerting that doesn’t raise false alarms, and post-mortems that are written down and turned into fixes.
• Security baseline. Secrets management, dependency scanning, image signing, network policies, and the routine patching that keeps known exploits out of your store.

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

Example incidents

A sample from the ten years of e-commerce engineering behind the practice, anonymized:

• 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 store’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. A probe on the invariant catches this class of failure while the error rate still looks normal.

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.