Skip to content
Infrastructure

Infrastructure that's straightforward to operate

Servers, clusters, code delivery, monitoring and backups. We build systems sized to the task and describe them so that support doesn't depend on a single person.

A typical project architecture

The layers a small product's infrastructure usually consists of. Select a layer to see what's in it.

Edge

Domains, TLS, CDN and protection against basic attacks. Cloudflare and Traefik in front of your services.

  • DNS
  • TLS
  • CDN
  • WAF
  • Traefik
  • Rate limiting

What we set up

  • Servers

    Baseline configuration, access, updates, firewall and environment separation.

  • Kubernetes and K3s

    A cluster of the right size: K3s for smaller projects, full Kubernetes where it's needed.

  • CI/CD

    Build and deploy pipelines in GitLab CI or GitHub Actions with pre-release checks.

  • GitOps

    Argo CD keeps the cluster in sync with the repository: changes are visible in history and rollback is predictable.

  • Monitoring

    Prometheus, Grafana and Loki with dashboards and alerts tailored to your services.

  • Backups

    A schedule, off-server storage, encryption and regular restore verification.

  • Security

    Access management, secrets kept out of the repo, dependency updates, network isolation.

  • Scaling

    Horizontal scaling of services and workers by metrics or queue depth.

  • Migration

    Moving between providers or into a cluster, with a plan and minimal downtime.

  • Cost optimisation

    Usage analysis and selection of instances, storage and plans that match real consumption.

Whose infrastructure we work on

The model is chosen at the start and can change as the project evolves.

On the client's infrastructure

We configure your servers and services, describe the setup as code, prepare the documentation and hand the finished solution to your team.

Best for

Teams that already have their own cloud accounts or hardware and want to keep full control.

  • All resources and credentials stay with you
  • Infrastructure as code plus documentation
  • Knowledge transfer to your team
  • Optional ongoing support on request

Project migration

The usual sequence when you need to change provider or consolidate services into a cluster.

  1. 01

    Inventory

    We record which services, data and dependencies exist today — and which of them are actually needed.

  2. 02

    Target architecture

    We describe how the system will look after the move and what changes in cost.

  3. 03

    Parallel environment

    We build the new environment alongside the current one and move data without stopping work.

  4. 04

    Verification

    We test the services, the load and restoring from backups.

  5. 05

    Cut-over

    Traffic switches during an agreed window, with a fast way back if needed.

We'll show what this looks like in your case

Tell us about your current infrastructure and we'll propose a target architecture and a transition plan.