$ BLR//CODE
Services OverviewProduct engineeringCloud & DevOpsNetwork architectureInfrastructure securityAI deploymentData & AISoftware cost reviewDedicated teams

Home / Services / Cloud & DevOps

SVC/OPS — Cloud & DevOps

Infrastructure you can rebuild from a repository.

The test of an infrastructure setup is simple: if the environment vanished tonight, could you recreate it tomorrow from what is in version control? Most organisations discover the answer at the worst possible moment.

CAP/ — Capabilities

What we run.

OPS/ARCH

Cloud architecture

AWS, OCI and GCP designs sized for what you actually run, with the cost implications stated before you commit to them.

OPS/IAC

Infrastructure as code

Terraform or OpenTofu, with state handled properly and a plan you can read in review. No resources created by hand in a console.

OPS/CI

CI/CD pipelines

Build, scan, deploy, notify. Gated on things worth gating on, and silent when everything is fine.

OPS/OBS

Observability

Metrics, logs and uptime checks, with alerts tuned so that a notification means somebody needs to act.

OPS/CNT

Containers & orchestration

Docker Compose where that is enough — and it usually is — Kubernetes when the scale genuinely warrants the complexity.

OPS/COST

Cost review

Finding the idle instances, the oversized databases, and the egress charges nobody attributed to anything.

REF/ — Reference design

A deploy pipeline with a gate that means something.

This is the pipeline running behind this site. Note the direction of the arrows into the server: the private network initiates the deploy, and nothing inbound is required — which is what lets the source of truth stay off the public internet entirely.

PRIVATE NETWORK — NOT REACHABLE FROM THE INTERNET Commit push to main Checkout CI runner Build / pull container images Scan CRITICAL = stop Deploy over SSH ON FAILURE Alert a human SUCCESS IS SILENT Public server 22 / 80 / 443 ONLY THE PRIVATE SIDE INITIATES. THE PUBLIC SERVER NEVER CONNECTS INWARD — SO COMPROMISING IT YIELDS NO PATH BACK TO THE SOURCE OF TRUTH.
Fig. 2 — Push-based deploy pipeline across a network boundary

PRN/ — Principles

Opinions we'll bring.

Right-sized, not resume-sized
Most workloads that get put on Kubernetes did not need to be. A Compose file on two hosts is operable by the team you actually have. We will tell you when the complexity is justified, and we will tell you when it is not.
Silence means success
A pipeline that messages you on every successful deploy trains you to ignore its messages. Notifications fire on failure only, so an alert always warrants attention.
Gates you won't disable
Vulnerability scanning blocks on critical findings that have a fix available, and reports the rest. A gate that fails on everything gets bypassed within a fortnight, and then you have a scanner and no benefit.
Secrets are not in the repository
Configuration in version control, secrets injected at deploy time from somewhere with access control and an audit trail. This sounds obvious and is the single most common finding when we look at an existing setup.
Backups that have been restored
An untested backup is a hope. Restore testing is part of the handover, and the result is written down with a date on it.

RD/ — Related reading

A deploy pipeline that refuses to ship known-vulnerable images

Scanning is easy. Making it a gate that survives contact with a deadline is the real problem.

Read →

Your cloud firewall rules probably don't do what you think

Two firewall layers, and a container runtime writing rules around one of them.

Read →

A hardened public VPS with a push-based deploy pipeline

The infrastructure serving this site, described in full.

Read →

CTA/ — Infrastructure work

Want a second opinion on your setup?

An architecture review is often the cheapest useful thing we do — a couple of days, a written findings list, and no obligation to do the remediation with us.

Start a conversation →