Quiet HarborLAB

Infrastructure lab · remote team based in the EU

Calm infrastructure for small teams.

We migrate, monitor, back up and harden the systems your business runs on — so your engineers can stop firefighting and your nights stay quiet.

Talk to an engineer How we work

Night report

Tue · 03:00–07:00 CET
  • 46 checks greenall night
  • Backups replicated off-site03:12
  • Restore drill passed03:40 · 6 min
  • Certificates validrenewal in 23 d
  • Pages to on-call0

A quiet night. Nothing needed you.

We work with

  • SaaS products
  • Agencies
  • Clinics & labs
  • Online shops
  • Non-profits

Services

The unglamorous work that keeps a business running.

Most of our clients have five to forty people and no full-time operations engineer. We become that engineer — for a project, or for as long as you need us.

  1. i.

    Migrations

    Move off a single overloaded server, a legacy host or a tangle of hand-built machines onto something documented and reproducible. Cut-overs are rehearsed, have a rollback path and usually happen outside your business hours.

    Typically includes

    • Inventory and risk map
    • Infrastructure as code
    • Rehearsed cut-over plan
  2. ii.

    Monitoring & alerting

    Alerts that mean something. We watch what your customers would notice, route pages to the right person and tune out the noise — so when the phone does ring, it matters.

    Typically includes

    • Uptime, resource and certificate checks
    • On-call routing and escalation
    • Weekly health summary
  3. iii.

    Backups & disaster recovery

    A backup is only real once you have restored it. We set up versioned, off-site copies with sanity checks, and run restore drills on a schedule — not just on the day you need them.

    Typically includes

    • 3-2-1 copies across providers
    • Automated restore drills
    • Written recovery runbook
  4. iv.

    Data pipelines

    Reliable movement of data between your apps, warehouse and reports. Scheduled, observable and easy to re-run when a source misbehaves — instead of a script on someone’s laptop.

    Typically includes

    • Scheduled, idempotent jobs
    • Failure alerts with context
    • Lineage you can explain
  5. v.

    Security hardening

    Sensible defaults, applied consistently: patching, least-privilege access, secrets out of repositories, SSH and firewall reviews, encrypted traffic everywhere. No theatre, just fewer open doors.

    Typically includes

    • Access and secrets review
    • Patch and update cadence
    • Hardening checklist per host

Approach

Boring on purpose.

Small teams don’t need more moving parts. They need the few that matter to be well understood, written down and watched.

  • 01Fewer moving parts

    We choose proven, well-documented tools over clever ones. Every component has to earn its place, and we usually remove more than we add.

  • 02Written down

    Every system we touch gets a runbook: how it is built, how to restart it, how to restore it. The docs live in your repository, not in our heads.

  • 03Measured, not promised

    We agree on targets — availability, recovery time, response to alerts — and report against them every month, including the months we miss.

  • 04Yours to keep

    Accounts, keys and configuration stay in your name. If we ever part ways, the handover is a meeting, not a project.

  1. Weeks 1–2

    Assess

    Inventory, risk map and a written plan with a fixed price. You keep the report whether or not we continue.

  2. Weeks 3–8

    Stabilise

    Backups you have seen restored, monitoring that pages the right person, and the riskiest gaps closed first.

  3. Ongoing

    Operate

    A monthly retainer: patching, reviews, optional on-call and a short monthly report you will actually read.

Selected work

Quiet results, mostly.

Client names stay private. The problems will probably sound familiar.

  • Consumer health app · team of 4

    One disk away from losing every photo

    The database was dumped nightly, but user uploads lived in a single copy, the off-site copy ran weekly, and nobody would have noticed a failed backup.

    • Versioned snapshots of uploads; a suspiciously small snapshot never replaces a good one
    • Daily off-site replication plus a third copy at another provider
    • A watchdog that reports stale backups — and confirms weekly that it is alive
    • Monthly automated restore drill into a scratch database
    BeforeUp to 7 days of data at risk
    AfterUnder 24 hours, tested monthly

  • B2B SaaS · engineering team of 12

    Alerts the team trusts again

    Every network blip woke someone up, so people muted the channel. Hosting renewals and full disks were tracked in one person’s calendar.

    • Lightweight agents reporting CPU, memory, disk and services
    • “Down” only after three failed checks; recovery messages include downtime
    • Disk warning once at 90%, cleared below 85%
    • Renewal reminders 14 and 3 days ahead, to a shared channel
    BeforeDozens of pings a week, mostly noise
    AfterA handful, each one actionable

  • Product studio · two production servers

    Releases that refuse to ship a red build

    Deploys were a dozen manual steps run from a laptop. Twice, migrations ran before the new code arrived; once, stale CSS stayed live for an hour.

    • One release command: tests first, then backup, code, migrations
    • Static assets verified by content hash, so nothing stale ships
    • Smoke test against production after every restart
    • One-command rollback to the previous release and dump
    BeforeA checklist in someone’s head
    AfterOne command, same order every time

Contact

Tell us what keeps you up at night.

A short description is enough: what you run, what worries you and how soon. An engineer reads every message.

  1. i.
    A reply within one business day (CET), by whichever channel you prefer.
  2. ii.
    A 30-minute call with an engineer — not a sales pitch.
  3. iii.
    A written proposal for a fixed-price assessment.

We only use these details to reply. Privacy notice