Cloud architecture
Right-sized designs on AWS, GCP or a European provider, with cost modelled before you commit rather than discovered on the first invoice.
Cloud infrastructure & DevOps
Environments that can be rebuilt from the repository, a pipeline that runs the tests before anything reaches production, and alerts that fire on the things that matter. A release should be the least interesting part of your week.
01 — Position
If a server cannot be recreated from code, it is a liability
The dangerous machine is not the one that fails. It is the one nobody has restarted in three years, configured by hand by someone who has left, holding state that exists nowhere else.
Our first move on any infrastructure engagement is to make the current setup reproducible — described in code, versioned, and rebuildable into a fresh environment. Only then is it safe to improve anything.
We also resist over-engineering. Most businesses do not need a service mesh. They need a documented deployment, a database with tested backups, and an alert that reaches a human.
The baseline we establish first
- Every environment described in code and rebuildable
- Staging that genuinely matches production
- Backups that have been restored, not merely scheduled
- One documented path from a commit to production
- A rollback that is a command, not an improvisation
- Alerts routed to a person who can act on them
02 — What we build
Scope of the practice
Infrastructure as code
Terraform modules in your repository, reviewed like application code, with a plan you read before anything is applied.
CI/CD pipelines
Build, test, scan, deploy — with the pipeline itself in the repository and a failing test genuinely blocking a merge.
Monitoring & alerting
Dashboards for the metrics that predict trouble, alerts tuned to avoid fatigue, and an on-call path agreed in writing.
Migrations
Moving a system off an ageing server, in stages, each with a rollback path — rather than one weekend everyone remembers for the wrong reasons.
Backup & recovery
A restore procedure that has actually been executed, with a measured recovery time you can put in front of a board.
03 — Delivered
What ends up in your hands
- Infrastructure code in your repository, in your cloud account
- A deployment pipeline with automated rollback
- Environment parity between staging and production
- Dashboards and alerts connected to your own channels
- A tested restore, with the measured time written down
- A cost breakdown per environment and per service
Typical stack
- Providers
- AWS, Google Cloud, Hetzner, or your existing account
- Provisioning
- Terraform, with state stored and locked properly
- Runtime
- Containers on ECS, Cloud Run or Kubernetes when the scale earns it
- Pipelines
- GitHub Actions, GitLab CI
- Observability
- Prometheus, Grafana, OpenTelemetry, or a managed equivalent
- Secrets
- Cloud secret manager or Vault, scoped per environment
- Terraform
- Docker
- Kubernetes
- GitHub Actions
- Grafana
- AWS
04 — Questions
About infrastructure work
Do we have to move to Kubernetes?
Almost certainly not. Kubernetes solves problems that appear at a certain scale and organisational shape; below that it adds operational burden you will pay for every week. We recommend it when the workload justifies it and say so plainly when it does not.
Can the infrastructure stay in the EU?
Yes, and for clients with GDPR obligations we default to it. We will name the regions, the provider and any sub-processor before anything is provisioned. See our Privacy Policy for how we handle data location generally.
Our current setup is undocumented. Where do you start?
With an audit: what is running, where, on what, with which credentials, and what would happen if each piece disappeared. That document alone is often the most valuable deliverable of the first month — and it is yours whether or not you continue with us.
What would break if that server died tonight?
If the answer takes more than a sentence, an infrastructure audit is the cheapest thing you can buy this quarter.
HALDIR LTD · HE 459882 · Nicosia, Cyprus