How HoneyBook uses Port to serve engineering & agents across the AI SDLC?

About HoneyBook

HoneyBook is a client-management platform that gives independent and service-based businesses one place to run the whole client relationship, capturing leads, sending proposals and contracts, scheduling work, invoicing, and collecting payments, and it is trusted by over 100,000 businesses in the US and Canada.

About Romy from HoneyBook

Romy is a DevOps engineer at HoneyBook, where she has spent over five years and owns much of the team's automation and deployment tooling. Her biggest project there was moving HoneyBook's engineers onto Port, turning deploys, rollbacks, and new-service creation into self-service flows the rest of the organization now runs on its own.

Where were developers getting stuck?

Romy came back to a familiar tension. Developers at HoneyBook needed to ship, and for routine steps like deploying to staging or pushing to production, they had to wait on her DevOps team. That made DevOps a manual gate on work that did not need their judgment, slowing developers and pulling the team off the platform work only they could do. "We're usually a blocker there," she said. After five years at HoneyBook, she set out to build a path developers could run themselves.

How do developers deploy now?

She started with deploys, the part that hurt most. HoneyBook already had a backend service that ran the deployment, wired to Temporal, but developers had no clean way to reach it or see the result. Romy put Port in front of it. A developer opens a service and sees its state, its Argo CD sync and health, and the exact commit running in production, which matters because they have no access inside the cluster. Commits that have not shipped sit right below, so the next deploy is one click. When something breaks, they read the logs Port streams back and roll back from the same screen without waiting on a fresh build.

What keeps every deployment safe?

Opening deploys to everyone only works if the rules hold, and setting those rules is where the DevOps team adds the most. Only developers can deploy. A commit cannot go out unless its end-to-end test has passed, and bypassing that needs a manager's approval. She built those rules in from the start, so opening deploys to every developer never meant giving up control over what reaches production.

How does someone spin up a new service?

From there the team moved into workflows. The one Romy is proudest of lets a developer stand up a whole new service on their own, starting with the GitHub repo. HoneyBook runs many GitHub organizations, so the workflow reads the request, places the repo in the right one, and routes it to the right approver. The step that used to need the DevOps team is now a path they designed, and it runs on its own.

‍

Using Port as the city center for agents across the SDLC

Romy is not done. HoneyBook already uses Port's MCP to let AI agents read its engineering context, and she wants them to execute actions too. 

The caution is deliberate: production has to be walled off from staging first, so an agent can act on staging without ever touching production before that boundary is proven.

Everything an agent needs to deploy safely, the DevOps team already built for developers: the context lake, and the rules (who can deploy, that a commit ships only if its test passed, that a bypass needs a manager). 

Today a developer reads that context and clicks the action. An agent would do the same through MCP, under the same rules. 

The team does not have to build a second system for agents. They can build their entire Agentic SDLC and know agents have high quality data, guardrails and permissions thus avoiding agentic chaos.