Cloud, DevOps and technical infrastructure

Infrastructure is invisible until it fails, which is why it is chronically under-invested in and why the failures are usually mundane: an expired certificate, a full disk, a backup that had not run for months, a deploy nobody could roll back. None of these are hard problems. They are the consequence of infrastructure assembled by hand and then left alone.

We build infrastructure that is defined in code, deploys the same way every time, tells you when something is wrong, and can be restored from a backup somebody has actually tried restoring.

Why this is worth doing properly

Cloud costs have become a governance problem rather than a technical one. Provisioning is easy, decommissioning requires somebody to notice, and the result is a bill that grows steadily with no corresponding growth in usage. Most organisations we assess are paying for resources nobody has looked at in a year.

Kubernetes deserves a specific caution. It is genuinely the right answer for a certain scale and shape of workload, and it is chosen far more often than that shape occurs. For a business running a handful of services, containers on a managed platform deliver the same reliability with a fraction of the operational burden, and we will say so even though the simpler recommendation is the smaller engagement.

The backup question is the one worth asking hardest. Almost every organisation has backups; a much smaller number have ever restored one. An untested backup is a belief, not a control, and the moment you discover the difference is the worst possible moment.

Where this work usually goes wrong

Servers configured by hand

A machine somebody set up over an afternoon two years ago cannot be reproduced, which means it cannot be safely upgraded or rebuilt after a failure. Infrastructure as code exists to make the server disposable.

Backups nobody has restored

Backup jobs fail silently, exclude the wrong paths, or capture a database mid-write and produce an unusable file. Scheduled restore tests are the only way to know, and they are rare.

Kubernetes for three services

The operational overhead is substantial and permanent. Unless you have the scale or the team to justify it, simpler container hosting gives the same result with far less to go wrong.

No rollback path

Deployment pipelines that can only go forward turn a bad release into an emergency. The ability to revert quickly matters more than deployment speed.

Secrets in the repository

Credentials committed to version control persist in history long after they are removed and are among the most commonly exploited exposures. They belong in a secret store with rotation.

What this covers

Cloud architecture

Designs sized to actual load and budget, with the cost model understood before commitment.

AWS deployment

Production environments with sensible networking, identity policy and cost controls.

Docker containerisation

Applications packaged so local, staging and production environments are genuinely identical.

Kubernetes deployment

Where scale or workload shape justifies it — and an honest assessment of when it does not.

Backend infrastructure

Application servers, queues, caches and databases provisioned as code.

Server setup and configuration

Hardened, patched, reproducible servers rather than hand-configured machines.

Self-hosted application deployment

Running open-source tooling on your own infrastructure for cost or data residency reasons.

n8n server deployment

Production automation hosting with persistence, queueing and monitoring.

Database deployment and management

PostgreSQL provisioning, tuning, replication and backup verification.

CI/CD pipeline setup

Automated build, test and deploy with a tested rollback path.

Cloud migration

Moving from on-premise or between providers with a staged cutover and a documented reversal plan.

API infrastructure

Gateways, rate limiting, authentication and versioning at the edge.

Application monitoring

Uptime, latency and error-rate monitoring with alerts routed to someone who will act.

Logging and observability

Structured, centralised logs with retention set deliberately and search that works during an incident.

Backup and recovery planning

Backups with defined recovery objectives, and restore tests on a schedule.

Performance optimisation

Profiling and tuning based on measurement rather than assumption.

Infrastructure documentation

Architecture diagrams, runbooks and escalation paths, written for someone who was not there.

How the work runs

1. Assess what exists

   An inventory of running resources, their cost, their patch status and whether anyone knows what they do. This regularly finds services nobody can account for and spend nobody has reviewed.

2. Define it as code

   Terraform or equivalent so environments are reproducible and changes are reviewable. This is the change that makes everything else safe.

3. Right-size deliberately

   Instances matched to measured load, with reserved capacity where usage is predictable. We will recommend the smaller architecture when it fits, including when that reduces our own scope.

4. Build the pipeline with a reverse gear

   Automated build, test and deploy, with rollback tested rather than assumed. Deployment confidence comes from being able to undo.

5. Monitor and alert usefully

   Alerts that indicate real problems and route to someone who can act. Alert fatigue is a genuine failure mode and quieter monitoring is better monitoring.

6. Test the restores

   Scheduled restore drills with the recovery time measured and recorded. A backup becomes a control at the point it has been restored, and not before.

What you receive

• Infrastructure and cost assessment
• Terraform definitions for all environments
• Containerised application deployment
• CI/CD pipeline with tested rollback
• Monitoring, alerting and centralised logging
• Backup configuration with documented recovery objectives
• Restore test results
• Architecture documentation and runbooks

You probably need this if

• Deploys happen manually and only one person can do them.
• Nobody has ever restored a backup.
• Your cloud bill rises and nobody can explain why.
• A server exists that nobody wants to touch.
• An outage is diagnosed by guessing, because there are no logs.

What we build and work with

Chosen for operability by a small team, since most of our clients do not have a dedicated platform group.

Terraform

Infrastructure as code so environments are reproducible and every change is reviewed before it lands.

Docker

Container packaging, with plain container hosting preferred over orchestration until scale genuinely requires it.

AWS, Hetzner or Cloudflare

Provider chosen on cost and data residency. Hetzner is frequently far cheaper for predictable European workloads; Cloudflare removes per-request cost for static delivery.

GitHub Actions

Build, test and deploy pipelines with environment protection and a tested rollback path.

PostgreSQL with verified backups

Managed or self-hosted, with point-in-time recovery and scheduled restore drills.

Monitoring and alerting

Uptime, latency, error rate and certificate expiry, with alerts tuned to be rare and meaningful.

Secret management

Credentials in a managed store with rotation, never in the repository or in environment files committed by accident.

What changes once this is in place

Environments that can be rebuilt

Infrastructure defined in code, so a lost server is an inconvenience rather than an archaeology project.

Backups that have been restored

Scheduled restore drills with measured recovery time, which converts a belief into a control.

Deployments you can undo

A tested rollback path, which is what makes frequent deployment safe rather than nerve-racking.

Costs that get reviewed

Tagged resources and a monthly cost review, which typically finds meaningful spend on things nobody uses.

Problems announce themselves

Monitoring tuned to alert rarely and meaningfully, rather than producing noise everyone learns to ignore.

How this differs by market

The work is the same craft everywhere. What changes is the law, the language and the buying culture — and those change enough to matter.

European Union

Where personal data is processed, the hosting region is a compliance decision — keeping it in the EU avoids the transfer-mechanism question entirely. NIS2 extends cybersecurity and incident-reporting obligations to a much wider set of sectors than its predecessor, and for in-scope organisations that changes what monitoring and incident response have to look like.

Nordics

EU or national data residency is a routine procurement requirement, especially in the public sector. Electricity costs and a cool climate have made the Nordics a genuine data-centre region, so EU-resident hosting there is often competitively priced rather than a premium.

United States and Canada

Compliance frameworks drive architecture: SOC 2 for enterprise sales, HIPAA for health data, PCI DSS for card handling. Canadian public-sector and health workloads frequently require domestic residency, and Quebec adds assessment obligations for transfers out of the province.

United Arab Emirates

Both AWS and Azure operate UAE regions, which makes in-country residency straightforward where it is required. Financial services entities regulated in DIFC or ADGM face additional outsourcing and data-location expectations that should be established before architecture is settled.

Not legal advice. Regulatory summaries on this site describe how we scope and build, and are current to our latest review. Verify the operative text with qualified counsel in the relevant jurisdiction before relying on it.

How we know it worked

Uptime, error rate and latency at the slow tail rather than the average, reported from monitoring rather than asserted. Averages conceal exactly the experience users complain about.

Recovery time objective measured in an actual restore drill, with the date of the last successful test recorded. We report the measured figure, not the target.

Monthly infrastructure cost with resources tagged by purpose, so spend can be attributed and reviewed. Where we claim a cost reduction it is a before-and-after from your own billing data.

Estimates are labelled as estimates. Any figure on this site that describes a range is a planning estimate with its assumptions stated, not a measured client outcome. We do not publish client results without the client's permission and a date.

Related services

Sectors where this is usually the lead engagement

These are the industries where this discipline is typically the first thing a client buys rather than something added later. The link goes to a page written for that sector specifically, with a paragraph on this service and on every other one.

• Financial Services & Banking — Among the fastest-growing categories of digital investment, and the one where a marketing claim can be a regulatory breach.
• SaaS & Software — Buyers who evaluate suppliers professionally, sell to people who do the same, and measure everything — which raises the bar on both sides.
• Energy & Utilities — Enormous operational data volumes, heavy regulatory reporting, and customer systems that were built for a market that no longer exists.
• Fintech & Payments — Startup growth expectations inside a supervised institution, where onboarding conversion and financial crime obligations pull in opposite directions.

It appears on all thirty sector pages, because every one of them carries a paragraph on all twenty-two services. This list names only the sectors where it tends to lead.

Where we deliver this

This service is delivered across the European Union, the Nordic countries, North America and the United Arab Emirates. The craft does not change; the law, the language and the buying culture do. Consent regimes, invoicing mandates and payment conventions differ enough between markets that a campaign or a system built for one frequently cannot be used unchanged in another.

Each country page sets out what actually differs there and what it means for scope — all 32 countries and 10 cities are listed here. A few of the markets we work in most:

• Germany
• Netherlands
• France
• Sweden
• United States
• United Arab Emirates