Build custom Octopus Deploy dashboards using llms.txt and Claude Code
Octopus Deploy’s built-in dashboard tells you what is deployed where. It does not tell you which tenants are two releases behind, which approvals are blocking a specific team, or how far a release has progressed across every environment. For that, you need the REST API.
Egor Pavlikhin from Octopus Deploy walked through how to point a coding agent at Octopus’s llms.txt file and build those custom views without reading through Swagger docs manually.
What llms.txt does for the agent
Octopus serves a plain Markdown file at /llms.txt on every instance. At the time of writing it is about 400 KB and covers five sections: authentication, space selection, endpoints, types, and step properties.
A typical endpoint entry looks like this:
POST /deployments - Create a Deployment | Body: CreateDeploymentCommand → DeploymentResourceThe matching type entry then lists every field in CreateDeploymentCommand: SpaceId, ReleaseId, EnvironmentId, TenantId, and so on. Together, one endpoint line plus one type line is enough for an agent to construct a valid API request without guessing at field names.
The Steps section adds another layer. To build a script step through the API, for example, the agent needs to know the ActionType value is Octopus.Script and the script body lives in Octopus.Action.Script.ScriptBody. That is documented in the file, derived from Octopus’s existing Swagger docs.
Part 1: Seeding test data
The author started with a near-empty Octopus space and asked Claude Code to create realistic test data. The agent fetched llms.txt, built a small Python helper to call the API without exposing the key in logs, and created a fictional company called Harborline with 5 teams running a retail platform. Each retailer became a separate tenant.
A few things llms.txt made possible directly:
- Space URL prefixes. The agent correctly applied
/api/Spaces-1/...scoping without being told. - Deployment process authoring. Step properties like
Octopus.Action.TargetRolesandOctopus.Action.Manual.ResponsibleTeamIdswere in the file and used correctly. - Backdating releases.
CreateReleaseCommandhas an optionalAssembledfield. The agent used it to spread 31 releases across August and September so the dashboards would have real history to display.
When the file was not enough, the agent fell back to making API requests and reading the validation errors to correct its approach.
Part 2: Three custom dashboards
All three dashboards use a lightweight Python proxy sitting between the browser and Octopus. The proxy serves the static HTML and forwards requests under /api/ to Octopus, appending the API key header server-side. This avoids embedding the key in page source and resolves CORS issues in one move.
Tenant rollout board
A matrix with tenants as rows grouped by tag set and projects as columns grouped by team. Each cell shows the release running in a selected environment and how many releases behind the newest version it is. The board calculates lag within the tenant’s own channel, so a tenant on the latest hotfix is not flagged as behind the mainline. Summary tiles surface pending approvals and missing variables at a glance.
Team health board
One card per team. Each card opens with deployments waiting for approval and tasks that failed in the last 24 hours, with direct links back into the Octopus UI. Below that, a table shows each project’s releases across environments. A banner at the top of the page shows active or upcoming deployment freezes. The agent sorted cards by an attention score: 3 points per failure, 2 per pending approval.
Release flow diagram
A Sankey diagram where ribbons connect releases to environments and then to tenant groups. Ribbon width represents tenant count. You can color ribbons by release version to follow a build across the diagram, or by deployment state to highlight failures and pending approvals.
Try it yourself
You need a publicly accessible Octopus instance, an agent API key, and a coding agent that can fetch URLs and run scripts. Open https://your-octopus-server/llms.txt to confirm your version serves the file. Start with a read-only task, like listing every tenant more than one release behind in Production, and verify the result against the portal before writing anything.
Keep the API key server-side. If you build dashboards, create a service account and put a proxy between the browser and Octopus, never paste the key into the page source.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
