Skip to content
OpsHero
Book a consultation
Careers

You get the whole estate. Then you get another.

Cloud and Kubernetes engineers here inherit entire production estates — regulated finance, high-traffic consumer media, legacy modernisation — and run them end to end. The agent work sits on top of systems already carrying real traffic, which is the part most places cannot offer.

What is already true
  • Engagements run in years rather than sprints — two of the four below are still going
  • Four sectors, four countries, and a different cloud account each time
  • A distributed engineering consultancy, registered in Sofia, Bulgaria
  • Senior engineers who build it, run it, then hand it back
The work

None of these estates looks like the last one

Read the first row twice. That estate — EKS with more than thirty AWS managed services behind it, across three clouds, under financial regulation — ran for three and a half years on two senior engineers. The other three are a legacy platform in Spain, a high-traffic review site in Bulgaria and an edutech startup in the United States: different sector, different cloud, different failure mode.

  1. July 2021 – December 2024DevOps transformation for a financial institution's mobile app

    The bank set out to rebuild its consumer business around a fintech mobile app. We were brought in to run the infrastructure behind it — automating the software development life cycle, applying Well-Architected practice from AWS, Azure and Google Cloud, and holding to the regulation the sector carries. Two senior engineers.

  2. August 2022 – presentTransforming infrastructure for a mobile gadget review website

    A high-traffic review site running into three problems at once: scaling, cost, and surges it could not absorb. We looked at what it actually needed and rebuilt the infrastructure around that.

  3. September 2023 – presentStreamlining and automating the software development life cycle

    A legacy system on virtual machines, deployed by hand. The work was to turn that into an automated workflow the client could run themselves.

  4. October 2023 – June 2024Cloud-native transformation for an edutech startup

    An edutech startup building its platform without cloud-native experience in the team. They wanted the architecture right before the growth arrived, not after.

The stack

What you would actually be running

Every mark below is on one of the four engagements above. Nothing here is aspirational tooling.

Across those engagements
  • AWS
  • Azure
  • Google Cloud
  • Kubernetes
  • Google Kubernetes Engine
  • Terraform
  • Terragrunt
  • Docker
  • Argo CD
  • GitLab
  • Jenkins
  • Prometheus
  • Cloudflare
  • Snyk
  • Aqua Trivy
  • SonarQube
The surface

Not a slice of an estate. The estate.

Cluster, accounts, network, infrastructure code and the guardrails around anything agentic. One surface, not four teams with a change-advisory board in the middle of it.

The cluster

Upgrades, autoscaling, the workloads on it and the incidents it produces at three in the afternoon.

The accounts and the network

Identity, boundaries, topology and the decisions behind them, written down so somebody else can read them.

The infrastructure code

Terraform that describes what is actually running, rehearsed in the lower environments before it goes anywhere near production.

The agents and their guardrails

Evals, approval gates and spend caps, against systems that were already carrying real traffic before an agent touched them.

Engagements are scoped and they end. The repositories and the accounts go back to the client documented, and nothing you build here stays yours — which is exactly why there is a different sector on a different cloud waiting behind it. You do not keep the code. You keep everything it taught you.

Most agent work happens where nothing can break. This does not.

Anyone can point an agent at a sandbox. The interesting constraint is an estate that is already carrying production traffic, and that is the only kind here. The role has a name and a page of its own: an AI Champion is one senior OpsHero engineer, embedded in your team, whose entire remit is finding AI leverage and shipping it — and what that engineer owns is evals, approval gates, data boundaries, spend caps and an escalation path that a human owns.

That brief was written for clients, before they buy it, which makes it a more honest job description than anything written for candidates. It is also the shape of the work: agents downstream of operations that already run, rather than a greenfield lab. Read it and judge whether the guardrails are real.

Read the AI Champion brief →

From outside

The people paying for it describe the same thing

We've relied on OpsHero across several key projects for well-known financial institutions. They're proactive, fast on complex problems, and deep across cloud, Kubernetes, and DevOps. We count on them to get the job done.
Todor TashevCommercial Director · Paraflow Communications

You have probably done more of this than you think

This is not a bar you have to clear. It is the shape of the work, and most of it is ordinary for an engineer who has run production somewhere that mattered. Two or three of these being true is already worth a conversation.

Tick what is already true. Your answers stay in your browser.
0/5

Tick whichever are already true.

Nothing is sent anywhere — this stays in your browser.

Tell us what you have run

No form, no jobs board, no tracking system that emails you in six weeks. Message the company page and tell us about an estate you have run — the partners are named on the about page, and one of them will be reading it.

Tell us what you have run
Or judge the work first

Where to check what we just told you

Careers: Cloud and Kubernetes Engineers — OpsHero