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.