One small team, the Agenteer way, and four open-source Hyperping tools: a Terraform provider, a Python SDK, a Go client, and a Prometheus exporter, each pulled from the friction of the last.
Most stories that end with “and then we open-sourced four interconnected projects” begin with a grand plan. Ours began with a chore.
We run a production monitoring platform on Hyperping, the uptime-monitoring and status-page SaaS, across a fleet of 57 tenants. At that scale a dashboard stops being a convenience and turns into a liability. Every monitor, every status page, every maintenance window is a click, and clicks do not survive in version control, do not get code-reviewed, and do not reproduce. We wanted what every platform team wants when the count gets uncomfortable: our monitoring defined as code, reviewable in a pull request, applied the same way every time.
That single pressure, managing 57 tenants of status pages without click-ops, is the seed everything else grew from. What follows is a case study in agent-tier DevOps, the man-in-the-loop, full-lifecycle way of working with AI agents that Develeap calls the Agenteer™ model: an engineer owns the plan, the boundaries, and the review, while AI agents do the high-volume mechanical execution under a test suite that has to stay green to commit. That working method turned one chore into four open-source tools, a Terraform provider, a Python SDK, a Go client, and a Prometheus exporter, each one pulled out of the friction of the last. It was not a roadmap we drew on a whiteboard. It was a chain of consequences. And because “we used AI agents” is easy to assert and easy to doubt, this piece shows one of those agent runs in detail rather than just claiming it happened. The interesting part is not the architecture, disciplined as it is. It is the ratio of the team’s size to its output, and what that ratio says about where DevOps is heading.
The production system that started it all
Before any of the open-source tools existed, there was the system that needed them. Internally it is our Hyperping automation project: a monorepo that pairs an operations CLI with Terraform infrastructure-as-code to run the whole tenant fleet. It is not a side project. It manages 133 monitors, 57 status pages, and per-tenant subscriber configurations, all synced and reconciled against Hyperping’s API.
The Terraform layer runs against a Terraform Cloud workspace and drives per-tenant modules for API monitors, DNS checks, and status pages through a single for_each over the tenant list, with prevent_destroy on every resource so a bad plan can never quietly delete a customer’s monitoring. We apply with constrained parallelism to stay under Hyperping’s API rate limit.
On top of that sit the operational capabilities the dashboard could never give us as code. There is incident lifecycle management with broadcast-to-all-tenants templates and tier-targeted maintenance windows. There is a watchdog that bridges monitor failures to public status-page incidents and suppresses downstream noise when a shared upstream is the real cause. And there is the observability layer: Teams notifications, Grafana dashboards, and SLA reporting.
This project is the center of gravity for the whole story. Every one of the four open-source tools was pulled out of its friction, and every one of them is consumed right back into it. That bidirectional relationship (build it here, pull it out, depend on it again) is the pattern worth watching.
First, an open-source Terraform provider
The first answer was the obvious one: a Terraform provider. If you manage more than a handful of monitors you want them defined in code rather than navigated in a UI, and Terraform is the standard tool for that job. So the founding project of the whole family became develeap/terraform-provider-hyperping, a community provider whose own README frames its purpose plainly: manage uptime monitoring, incidents, status pages, and maintenance windows as infrastructure-as-code.
This was not a toy. The provider is built on HashiCorp’s modern Plugin Framework rather than the legacy SDK, and registers eight resources (monitors, incidents, incident updates, maintenance windows, outages, healthchecks, status pages, and status page subscribers) plus more than a dozen data sources. It is published to the Terraform Registry under develeap/hyperping, where it now sits at version 1.12.1 with thousands of downloads, and we wired up GPG release signing to match HashiCorp’s official pattern in the first week.
The engineering depth matches the surface area. It carries a serious acceptance-test suite that exercises real API behavior, and it shipped genuinely thorny features. Write-only attributes are the kind of detail that quietly raises the Terraform version floor to 1.11 for anyone who uses them. Import support spans every resource and is backed by a dedicated import-generator CLI. And there is migration tooling to pull existing configuration in from BetterStack, UptimeRobot, and Pingdom. A provider is a real software plugin with its own release engineering, registry presence, and compatibility contract. We did not just consume infrastructure-as-code tooling. We built a piece of it and published it for everyone.
The provider became our living backlog
Here is where the bidirectional relationship gets concrete. The provider’s version history reads like a transcript of our production pain points. We pinned it and then chased it through release after release, from v1.4.8 up to v1.10.0 over roughly two months, because each upgrade closed a gap we had just hit in production.
When operating real status pages made an optional field necessary, the provider made it optional and a post-apply cleanup script disappeared. When we needed monitoring-location awareness and DNS checks for tenant CNAMEs, the provider grew a monitoring-locations data source and full DNS protocol support. The most telling release removed ten API workarounds, roughly 800 lines, once the underlying behaviors were fixed properly instead of patched around. A known provider bug, where a 4xx response trips the client’s circuit breaker, is still tracked openly between the production team and the provider maintainer. This is what it looks like when the same people feel the friction, fix it at the right layer, and consume the fix immediately.
The first extraction: a Python SDK, and what an agent run actually looks like
A provider declares your desired state. It does not run your day-to-day operations. As we leaned on Hyperping, the operational surface widened, and that work landed in an internal operations CLI sitting on top of an in-tree API client. Underneath all of it was the same recurring ingredient: a hand-written client that knew how to talk to the Hyperping API, handling monitors, incidents, maintenance, outages, the models, the endpoints, the exceptions. It was the reusable core of the CLI, and it was buried inside a single project where nobody else could use it.
So we did the structurally correct thing, and this is the moment to show how, because the method is the actual subject of this article. The work started as a written plan: a 420-line extraction document committed to the repo before a single line of client code moved. The plan drew the line between the two roles explicitly. It had a “do this first, externally” list for the human (create the GitHub repository, reserve the PyPI name through a pending Trusted Publisher, set up the release environments) and a “code work, in order” list for the agent to execute against (transplant and rename the client, add the missing Status Pages surface, write the README, cut the first release). With that contract in place, the agent did the mechanical surgery in an isolated git worktree, under one non-negotiable rule the repo’s agent guide states plainly: every commit must pass make check, meaning zero lint findings, zero type errors, and a green test suite, before it is allowed to land. A human reviewed and merged each step. That is the man-in-the-loop shape of all four projects. The engineer owns the plan, the boundaries, and the review; the agent owns the high-volume, mechanically verifiable execution that a tired human does badly at 6pm.
The standalone repository became develeap/hyperping-python, published to PyPI simply as hyperping. It is a properly built SDK: synchronous and asynchronous clients, Pydantic v2 models, an httpx transport, mypy strict typing with a shipped py.typed marker, MIT licensed, supporting Python 3.11 through 3.13, published through GitHub Actions with PyPI Trusted Publishing and build provenance.
The cutover that wired it back into production ran in two deliberate phases on the same day. Phase one replaced the in-tree client implementations with thin re-export shims pointing at the published SDK. It is tempting to report that as “zero behavioral changes, all tests green,” and the commit message does say exactly that. But the honest detail is how it stayed green: the phase leaned on backward-compatible subclasses and legacy field aliases left in place on purpose, so the consuming code would not notice the swap. Phase two then rewrote the imports across the project to point straight at the package and deleted the shim directory. Even then it was not frictionless. A follow-up commit had to fix an import path the migration missed, and another cleaned stale references to the old client out of CI. The two-phase shape, safe-then-clean, is what let a change that deep land without the test suite ever going red. That is the point, not the absence of mess.
The SDK got an internal tidy of its own at its first stable release, splitting a monolithic models file into a subpackage, extracting the circuit breaker, and decomposing the request method into focused helpers. Months later the story came full circle: the operations CLI that had originally lived in the consuming project was folded into the SDK as an optional command-line interface. The tool that triggered the extraction came home to ship from the package it had spun off.
The second extraction: a shared Go client, driven by an exporter
The next need came from observability. We wanted a Prometheus exporter so Hyperping data could live in Grafana next to everything else we monitor: uptime, response times, SLA ratios, outage data, tenant health scores. Building it forced the same architectural question the Python work had already answered once, this time on the Go side.
The honest version of the timeline has a wrinkle worth telling accurately, because it is more useful than a tidy fiction. The exporter shipped first, as develeap/hyperping-exporter, carrying its own copy of the API client lifted out of the Terraform provider. That worked, but it meant the same Go client now lived in two places, inside the provider and inside the exporter. Maintaining a client, with its recorded HTTP cassettes and contract tests, twice is exactly the kind of friction we had learned to refuse.
So we consolidated, and the whole move happened within a single day. We extracted the client into a brand-new standalone module, develeap/hyperping-go, then migrated both consumers onto it. The provider’s cutover is the one worth dwelling on, and not for the line count. Its entire in-tree client, more than 110 files, came out, and the provider’s acceptance suite, hundreds of tests against real API behavior, came out the other side green. The diff happened to show over 30,000 deletions. That number is the easy one to wave away (“you deleted a vendored copy, so what”). The thing that is actually hard, and the thing the whole workflow exists for, is making a change that large without the tests going red.
From that point forward, hyperping-go is the single source of truth, the shared HTTP client consumed by both the Terraform provider and the exporter. It exposes a full REST client across every Hyperping resource plus a JSON-RPC client for Hyperping’s MCP (Model Context Protocol) server, with production-grade resilience: retry with exponential backoff and jitter, Retry-After handling, a circuit breaker, a TLS 1.2 minimum, typed API errors, and credential redaction across error paths. The library went from birth to its v0.7 series within a few months, and both consumers tracked its releases in lockstep, including a shared HTTP/2 fix that rippled through the provider and the exporter on the same day.
The exporter on top of it is no thin wrapper either. It maps Hyperping entities to more than thirty-five Prometheus metric descriptors, runs REST and MCP collection in parallel per scrape, supports multi-project fan-out, ships a hardened Helm chart, and publishes a multi-arch, distroless, cosign-signed image to Docker Hub. Pure Prometheus exposition, exactly the format the observability ecosystem already speaks.
Closing the loop
The extractions are only half the pattern. The other half is the production system pulling those tools back in and retiring its homegrown versions in the process.
When the Go exporter matured, our automation project’s metrics-serving command stopped running its old Python exporter and started dispatching to the hyperping-exporter binary, with a deprecation notice pointing engineers at the standalone repo’s releases. New metrics now get added in the exporter, not in the consuming project. We pulled the Grafana alert and recording rules, which started life in the exporter repository, back into the production project’s observability stack. The provider, the SDK, and the Go client are all tracked in production as ordinary external dependencies, bumped as they release. The friction flowed out as four published artifacts, and the artifacts flowed back in as dependencies. The center got smaller and sharper every time.
Four projects, one lineage
Four production-grade open-source projects, each born from the friction of the one before it:
terraform-provider-hyperping: the founding project, on the Terraform Registry. Click-ops did not scale to 57 tenants.hyperping-python: the SDK on PyPI, extracted from the internal tooling. Declarative state does not run incidents.hyperping-go: the shared Go client. Two Go programs should not maintain the same client twice.hyperping-exporter: the Prometheus exporter on Docker Hub that drove that consolidation.
None of these was built speculatively. Each extraction was a real act of separation of concerns: pull the reusable core out, stand it up as its own versioned, tested, published artifact, and have the original consumer depend on it.
What it actually cost us
The honest part, because four repos are not free.
- Four release pipelines, not one. A Registry publish with GPG signing, a PyPI publish with provenance, a multi-arch cosign-signed Docker image, and a Helm chart repo are four separate release surfaces to keep green. Every one is a thing that can break on a Friday.
- Version churn in lockstep. Because
hyperping-gofeeds both the provider and the exporter, a single client fix means a coordinated bump in two consumers. The HTTP/2 fix that rippled through both on the same day was the good case. We lean on grouped dependency updates so the churn does not bury us. - Documentation drift. Splitting code across repos splits the docs too. Our provider README and the public docs lagged the Registry on something as basic as the resource count. Four sources of truth for prose is harder than four sources of truth for code.
- The discipline tax is real. Extraction is not magic. There were temporary replace directives pointing at a local checkout, import-ordering churn, and a re-pin once the new module was tagged. The payoff is large, but the move itself takes care.
We would make every one of these trades again. But “we open-sourced four projects” should never be read as “for free.”
What we would tell another team
If you want to build an ecosystem like this, a few things we learned the hard way:
- Extract on the second consumer, not the first. The Go client only deserved to be a library once the exporter needed it too. Before that, it was just code in a repo. Pulling things out too early buys you maintenance overhead with no shared upside.
- Make the extraction safe before you make it clean. The shims-then-delete pattern (proxy the new package first with zero behavior change, migrate imports and delete second) meant the test suite never went red. Do the scary part in a way you can verify.
- Let the consumer drive the library’s backlog. Our provider’s best releases came straight from production pain. A library with no demanding consumer drifts toward features nobody asked for.
- Point the agents at the unglamorous work. The full-project import rewrite and the 110-file client deletion are exactly the structurally correct, mechanically verifiable changes that a tired human skips under deadline. Bounded by a written plan and a green-tests-to-commit rule, that is where agent-tier execution earns its keep.
- Write the plan down first. The Python SDK had an actual extraction document before a line moved, and it is the same document that split the work into what the human does and what the agent does. It is what kept a two-phase, same-day cutover from turning into a mess.
How a small team sustains this
The thing holding up underneath the speed is engineering maturity, not heroics. The production project alone reports test coverage around 98 percent, and it does not stop at line coverage: mutation testing checks whether the tests actually catch regressions, mypy runs in strict mode, and a five-stage CI pipeline runs linting, tests, secret scanning, dependency and IaC vulnerability scanning, and a container build. Our runbooks are not prose; they are structured YAML driven by a drill runner, and we built a dedicated incident-response drill environment to practice against. The published libraries carry the same standard: strict typing, signed releases, build provenance, security-audit commits, and semver guarantees.
💡 Moving the provider to the shared Go client deleted its entire in-tree client in a single commit, and the acceptance suite stayed green on the other side. A change that large that you can actually trust is the whole point. The line count is just the byproduct.
The reason a small team can sustain multi-repo, multi-language, production-grade open source across four registries is the method this article keeps naming: the man-in-the-loop, agent-tier workflow shown in the SDK cutover above, applied over and over. The engineer sets the architecture and the boundaries and reviews every change. AI agents execute the high-surface, mechanically verifiable work in isolated worktrees, gated by a test suite that has to stay green to commit. The agents did not invent the architecture. They made the architecture, the one with clean seams and single sources of truth, cheap enough to actually build, and then cheap enough to maintain.
The partnership payoff
There is a difference between writing open-source tools for a product and being welcomed by the people who build that product. We reached out to Hyperping, framing the work as both a contribution and a demonstration: four interconnected projects, each driven by a real need, built the right way, released publicly, and maintained as proper open source. We offered to coordinate links and to collaborate on closing API gaps.
Leo at Hyperping went through all four projects and responded the way every open-source maintainer hopes a partner will. He called it incredible work, then backed that up with real estate across Hyperping’s own properties. They published two blog posts, one walking through the Terraform provider with HCL examples and a getting-started guide, and one covering the full ecosystem and how the four tools connect. That second post states directly that we had been using Hyperping to manage monitoring across 57 tenants, and that this production usage led us to build tools extending Hyperping into the infrastructure-as-code, Python, and observability ecosystems.
They stood up a new Community section in their docs, an overview hub plus dedicated pages for the Terraform Provider, the Python SDK, the Prometheus Exporter, and the Go Client, and added a Community category to the docs sidebar. They added a section to their homepage, “Developer tools built by the community,” with Terraform, Python, Prometheus, and Go links into the docs, crediting Develeap directly. Everything links out to GitHub, the Terraform Registry, PyPI, and Docker Hub.
Leo offered to correct any inaccuracies, floated a joint announcement, and stayed open to collaborating on API gaps. He closed with thanks for building it the right way. That phrase is the whole point. The partnership paid off not because the tools were flashy, but because they met Hyperping’s developers in the workflows they already live in, and because they were maintained well enough that an ISV could comfortably point its own customers at them.
What agent-tier DevOps actually means
It is tempting to read this as a story about productivity: four repos from a small team, look how fast. That undersells it. The more important lesson is about discipline holding up under speed.
Agent-tier DevOps, in practice, is not “the agent wrote a lot of code.” It is the ability to do the unglamorous, structurally correct thing every single time the need arises, without that correctness being too expensive to bother with. When the API client deserved to be reusable, it got extracted into its own published package, not copied. When two Go programs needed the same client, the client became a shared library with one source of truth, not two drifting copies. When the exporter grew its own HTTP server, Docker image, and Kubernetes manifests, it left the Terraform provider rather than bloating it, because a provider plugin should not bundle a long-running server. Each of those decisions is what a senior engineer would tell you to do. The difference is that all of them actually got done, with tests, signing, changelogs, and registry publication, by a team small enough that, in an earlier era, it would have quietly chosen the shortcut instead.
For teams, the takeaway is that the cost of doing things properly, the extraction, the separation of concerns, the shared libraries, the real test coverage, has dropped to the point where it is the default rather than the luxury. That is what the man-in-the-loop, agent-tier way of working buys you: not code written without a human, but the discipline a human would always endorse, finally cheap enough to apply every time. For partners and ISVs like Hyperping, the takeaway is what that produces when it is pointed at a real relationship: not a one-off script, but a maintained ecosystem that brings your product into the tools your developers already use, and that you are proud enough to feature on your own homepage.
The whole chain started with 57 tenants and a dislike of clicking, and a refusal, at every step after, to take the shortcut. It ended with four open-source projects, an ISV partner crediting us across its blog, docs, and homepage, and a working demonstration that building it the right way and building it fast are no longer opposing choices.
Khaled Salhab is an agent-tier DevOps professional at Develeap. He builds and maintains the Hyperping open-source tooling, working where infrastructure-as-code, AI agents, and production reliability meet.
