Ordinary DevOps work

I’m Jakob. Catalift is my practice.

Build and release pipelines, infrastructure as code, cloud migrations, access and secrets, monitoring that tells you something useful, and the occasional rescue of a system that got built faster than it got understood.

Usually fractional: a couple of days a week, or a single scoped piece of work. You deal with me directly, because there’s nobody else to hand it to.

Build and release

Pipelines that run the same way every time, on a machine rather than in somebody’s terminal. Tests that gate a deploy instead of decorating it, releases that can be rolled back without ceremony, and a path to production short enough that people actually use it. If shipping currently requires a particular person being awake, that’s the thing worth fixing first.

Infrastructure you can rebuild

Environments defined in code, in a repository, and reproducible from source rather than from memory. That covers greenfield build-outs, migrations between providers or accounts, and the more common case: bringing something that already exists under management without a big-bang rewrite and without downtime.

Safe and affordable to run

The parts that only get attention after they bite. Real permission boundaries instead of wildcards, secrets that live somewhere they can be rotated, backups that have actually been restored at least once, alerting that distinguishes an outage from noise, and a bill you can read and explain.

Hand it back

The goal isn’t to become a dependency. Work ships with runbooks, a pipeline your team can read, and enough documentation that the next person to touch it isn’t starting from scratch — including when that person isn’t me. If I’ve done this right, you need me less over time.

What I usually get called about

None of these are unusual. All of them are fixable.

  • Releases that still need a person

    Deploying involves a checklist, a particular laptop, and somebody remembering step four. It works right up until the week they're on vacation.

  • State that disagrees with reality

    The state file stopped matching production the first time someone fixed an incident in the console. Now nobody is sure what a plan will do, so nobody runs one.

  • Credentials in the repository

    An access key committed to a tfvars file, a database password living in plain text, and no story at all for rotating either of them.

  • Permissions that are just *

    Every role can do everything, because narrowing one of them broke a deploy once, and the change got reverted instead of understood.

  • Nobody knows when it breaks

    You find out from a customer. The dashboards are green, or there are forty of them, and no one agrees which is the real one.

  • A bill nobody can explain

    Instances sized for a load that never arrived, NAT gateways routing nothing, and volumes still attached to machines that were deleted last year.

Start with a conversation

Tell me what you’re running and where it hurts. I’ll tell you what I’d do about it, and whether you need me at all.

Work usually starts with a fixed-scope review of your environment and a written assessment. It’s yours whether you hire me or not.