FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid Atom 1.0 feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 5, column 62: Self reference doesn't match document location [help]

  <link href="https://octopus.com/blog/feed.xml" rel="self" />
                                                              ^

line 142, column 0: style attribute contains potentially dangerous content: overflow-x (42 occurrences) [help]
```
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#00 ...
```
line 142, column 0: content should not contain data-language attribute (42 occurrences) [help]
```
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#00 ...
```

line 611, column 39: Two entries with the same value for atom:updated: 2025-10-14T00:00:00.000Z (2 occurrences) [help]

      <updated>2025-10-14T00:00:00.000Z</updated>
                                       ^

line 1293, column 0: content should not contain loading attribute (10 occurrences) [help]
```
<div class="hint">ReAct agents are described in the <a href="https://arxi ...
```
line 1293, column 0: content should not contain decoding attribute (10 occurrences) [help]
```
<div class="hint">ReAct agents are described in the <a href="https://arxi ...
```
line 1293, column 0: content should not contain fetchpriority attribute (10 occurrences) [help]
```
<div class="hint">ReAct agents are described in the <a href="https://arxi ...
```

Source: http://feeds.feedburner.com/OctopusDeploy

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Octopus blog</title>
<subtitle>Site description.</subtitle>
<link href="https://octopus.com/blog/feed.xml" rel="self" />
<link href="https://octopus.com" />
<id>https://octopus.com/blog/feed.xml</id>
<updated>2025-10-17T00:00:00.000Z</updated>
<entry>
<title>Octopus partners with Arm to enable software delivery at scale</title>
<link href="https://octopus.com/blog/arm-partnership" />
<id>https://octopus.com/blog/arm-partnership</id>
<published>2025-10-17T00:00:00.000Z</published>
<updated>2025-10-17T00:00:00.000Z</updated>
<summary>Our partnership with Arm brings centralized, secure, and repeatable software delivery to Arm-powered systems.</summary>
<author>
<name>Madalina Iosif, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Octopus sets the standard for Continuous Delivery (CD) at scale, helping thousands of customers orchestrate deployments across various environments, regardless of whether the target hosts are on-prem, hybrid, or multi-cloud. It supports complex application deployments of any flavour, from heritage monoliths to containerized microservices.
With the rise of AI, technology is becoming increasingly prevalent in business and daily life, requiring computing platforms to keep pace with rapid innovation and the high volume of data being processed.
This is where Arm steps in to provide the industry’s most efficient and highest-performing compute platform. More than 325 billion Arm-based devices have been shipped to date. Arm powers innovation acceleration across sectors such as high-tech, automotive, healthcare, telco, and much more, with a focus on cloud computing and IoT.
We partnered with Arm to make software deployments on Arm-powered infrastructure secure, repeatable, and scalable.
<h2 id="why-is-a-robust-cd-solution-necessary-when-deploying-at-scale">Why is a robust CD solution necessary when deploying at scale?</h2>
Deploying one application to one host is an easy task. However, managing this at scale is challenging without an enterprise-grade solution.
Risks such as human error or DIY scripts with minimal security can lead to major incidents, especially in highly regulated or critical industries like automotive or healthcare. Plus, they have a high impact on the speed of deployment, leaving companies lagging behind their peers in terms of innovation.
A centralized CD solution with built-in security and the capability to deploy to thousands of targets using a repeatable process ensures efficiency, quick rollback in case of an incident, and proper governance and compliance. These are all imperative to ensuring technology is not only being built, but also used.
<h2 id="the-octopus-deploy-and-arm-partnership">The Octopus Deploy and Arm partnership</h2>
Octopus has been supporting deployments to Arm through the Tentacle agent since 2021. If you are curious about how this works, check out <a href="https://octopus.com/blog/tentacle-on-arm">our blog post on the topic</a>.
With the evolution during the past years of both Octopus and Arm, the partnership brings benefits for our joint customers in two main areas:
<h3 id="continuous-delivery-at-scale-from-x86-to-arm-servers-to-reduce-infrastructure-cost">Continuous Delivery at scale from x86 to Arm servers, to reduce infrastructure cost</h3>
Octopus can target both x86 and Arm-based servers, supporting the same deployment process regardless of the target host. This way, organizations can migrate or extend workloads from x86 to Arm cloud instances (AWS Graviton, Azure Arm VMs, or Axion-based Google Cloud instances) to optimize cost while keeping a single pipeline. Deployments are fully automated, repeatable, and can scale to thousands of targets.
For example, Octopus Deploy can deploy the same application to x86 EC2 instances and AWS Graviton. You reduce your compute costs and improve performance while the transition is seamless to your users.
<h3 id="compliant--secure-cd-for-kubernetes-edge-deployments-to-reduce-risk">Compliant & secure CD for Kubernetes edge deployments, to reduce risk</h3>
Running Octopus Kubernetes Agent natively on Arm-based Kubernetes clusters at the edge creates a secure connection and eliminates the need for an inbound connection. As for any other deployments with Octopus, you can use encrypted communication, role-based access control, and auditable approvals to ensure compliance.
Moreover, using Runbooks in Octopus, you can automate maintenance tasks such as patching, certificate rotation, and secure updates across distributed Arm-powered Kubernetes clusters at the edge.
A practical example is a retail chain that uses Octopus to securely roll out point-of-sale software updates to thousands of Arm-powered edge devices across stores, with a single deployment process and full auditability for compliance teams.
<h2 id="curious-to-learn-more">Curious to learn more?</h2>
If you’re an Arm customer and would like to test Octopus for your Continuous Delivery, you can <a href="https://octopus.com/start">sign up for a free Octopus trial</a> or <a href="https://octopus.com/lp/schedule-a-demo">request a demo</a>.
You can also see how Octopus supports deployments to Arm devices by visiting us at GitHub Universe in San Francisco, October 28–29, 2025.
Happy deployments!]]></content>
</entry>
<entry>
<title>Using Platform Hub to increase Supply Chain Security</title>
<link href="https://octopus.com/blog/supply-chain-security-with-platform-hub" />
<id>https://octopus.com/blog/supply-chain-security-with-platform-hub</id>
<published>2025-10-15T00:00:00.000Z</published>
<updated>2025-10-15T00:00:00.000Z</updated>
<summary>Learn how Platform Hub can help supply chain security in Octopus Deploy.</summary>
<author>
<name>Bob Walker, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Imagine this scenario: An application is built on Monday afternoon. That version is deployed to a test environment on Tuesday morning for verification. Testing is successful, and the production deployment occurs on Wednesday morning. But no one knew that early Tuesday morning a third-party package issued an update that closes a critical <a href="https://www.cve.org/">CVE</a>. Ideally, a process exists to inform application teams about the vulnerability before testing starts on Tuesday and include it as part of the production deployment on Wednesday.
With Platform Hub, solving that problem at scale is much easier than ever before. In this post, I will walk you through the steps to increase supply chain security in Octopus Deploy using the <a href="https://octopus.com/docs/platform-hub/process-templates">Process Templates</a> and <a href="https://octopus.com/docs/platform-hub/Policies">Policies</a> included in Platform Hub.
<h2 id="nomenclature">Nomenclature</h2>
If you read <a href="https://octopus.com/blog/supply-chain-security-with-github-and-octopus-deploy">my previous post on supply chain security</a>, you are familiar with SBOMs, Provenance, and Attestations. For those who haven’t read that post, I’ve included the definitions below to make it easier to follow along.
<ul>
<li>SBOM - Software Bill of Materials - a list of all the third-party libraries (and their third-party libraries) used to create the build artifact (container, .zip files, jar files, etc.).</li>
<li>Provenance - the record of who created the software change, how it was modified and built, and what inputs went into it. It shows how the build artifact was built.</li>
<li>Attestation - A cryptographically verifiable statement that asserts something about an artifact, specifically its Provenance. It is similar to the notary seal on a document. Doesn’t show the whole process, but certifies its validity.</li>
</ul>
SBOMs, Provenance, and Attestations are intertwined. Think of it like a cake.
<ul>
<li>SBOMs are the ingredient list.</li>
<li>Provenance is the recipe and kitchen log (who cooked it, when, and with which tools).</li>
<li>Attestation is a signed certificate that proves the ingredient list, recipe, and cooking process are trustworthy.</li>
</ul>
<h2 id="responsibilities-differences-between-build-servers-and-octopus-deploy">Responsibilities differences between build servers and Octopus Deploy</h2>
This post focuses on using Process Templates and Policies within Octopus Deploy. But they will rely on artifacts created by the build server. For example, the build server will create the SBOM, while Octopus Deploy will scan the SBOM for package references with known vulnerabilities. Below is a table showing the differences in responsibility between build servers and Octopus Deploy.
<div class="table-wrap">
<table><thead><tr><th>Build Server </th><th>Octopus Deploy </th></tr></thead><tbody><tr><td>Generating SBOMs </td><td>Attaching the SBOM to the release or forwarding it onto a third-party tool like <a href="https://ortelius.io/">Ortelius</a></td></tr><tr><td>Scanning source code referenced third-party packages for known vulnerabilities </td><td>Scanning for known vulnerabilities within package versions listed in the SBOM </td></tr><tr><td>Generating Attestations </td><td>Verifying attestations </td></tr><tr><td>Scanning recently built containers for known vulnerabilities </td><td>Scanning containers about to be deployed for known vulnerabilities </td></tr><tr><td>Create build information file for Octopus Deploy to consume </td><td>Use the build information file to update third-party issue trackers like JIRA </td></tr></tbody></table></div>
<h2 id="tooling-used">Tooling Used</h2>
For my build server, I’m using GitHub Actions because it includes built-in Attestation generation. I’ll use <a href="https://trivy.dev/">Trivy</a> for vulnerability scanning and SBOM generation.
<ul>
<li>SBOM generation - GitHub Actions will use Trivy to create an SBOM in the <code>spdx-json</code> format via the <a href="https://github.com/aquasecurity/trivy-action">provided step by AquaSecurity/trivy-action</a> step.</li>
<li>SBOM scanning - Octopus Deploy will use Trivy to scan the SBOM for known fixed vulnerabilities.</li>
<li>Attestation generation - GitHub Actions will use the built in step <a href="https://github.com/actions/attest-build-provenance">actions/attest-build-provenance</a> to create the attestation.</li>
<li>Attestation verification - Octopus Deploy will use the command <code>gh attestation verify</code> provided by <a href="https://cli.github.com/">GitHub CLI</a> to verify the attestation.</li>
<li>Container scanning Post-build - GitHub Actions will use Trivy to scan the container for known fixed vulnerabilities after the container is built.</li>
<li>Container scanning Pre-deployment - Octopus Deploy will use Trivy to scan the container for known fixed vulnerabilities before a deployment.</li>
</ul>
In Octopus Deploy, I opted for <a href="https://octopus.com/docs/projects/steps/execution-containers-for-workers">execution containers</a> instead of installing Trivy directly on my workers. There are two execution containers with Trivy installed you can use today:
<ul>
<li><a href="https://hub.docker.com/r/octopuslabs/trivy-workertools">octopuslabs/trivy-workertools</a> includes Trivy, PowerShell, Python, and Octopus CLI.</li>
<li><a href="https://hub.docker.com/r/octopuslabs/github-workertools">octopuslabs/github-workertools</a> includes the Git, GitHub CLI, Trivy, PowerShell, Python, and Octopus CLI.
The <code>DOCKERFILE</code> for both execution containers is in the <a href="https://github.com/OctopusDeployLabs/workertools">WorkerTools</a> GitHub repository.</li>
</ul>
<h2 id="process-templates">Process Templates</h2>
My Process Template will contain all the necessary logic to attach the SBOM to the release, scan the SBOM for known vulnerabilities, verify the attestations from GitHub, and scan containers for known third-party vulnerabilities.
The <a href="https://octopus.com/docs/platform-hub/process-templates">Process Template documentation</a> provides a step-by-step guide to creating Process Templates. Instead of a step-by-step guide, I’ll walk you through the specific configuration for my Process Template.
<h3 id="process-template-configuration">Process Template Configuration</h3>
Following our <a href="https://octopus.com/docs/platform-hub/process-templates/best-practices">best practices</a>, I created a Process Template focused on supply chain security, <code>Deploy Process - Attach SBOM and Verify Build Artifacts</code>.
<figure><img src="/blog/img/supply-chain-security-with-platform-hub/list-of-process-templates.png" alt="List of Process Templates on an instance with an arrow pointing to the Process Template to attach SBOM and build artifacts">.</figure>
The Process Template currently has two steps.
<ol>
<li>The first step will extract the SBOM from a package, attach it as a deployment artifact, and then run Trivy to scan for known fixed vulnerabilities.</li>
<li>The second step will loop through a list of packages and containers, run <code>gh attestation verify</code> on each item, and run Trivy on any containers for any known fixed vulnerabilities.</li>
</ol>
<figure><img src="/blog/img/supply-chain-security-with-platform-hub/process-template-steps.png" alt="List of steps in the example Process Template"></figure>
<h3 id="process-template-parameters">Process Template parameters</h3>
For my Process Template, there are four Process Template parameters.
<ol>
<li><code>Template.SBOM.Artifact</code> - a zip file containing the SBOM for a specific application.</li>
<li><code>Template.Git.AuthToken</code> - the GitHub PAT used for <code>gh attestation verify</code> to function properly.</li>
<li><code>Template.Verify.Workerpool</code> - the worker pool to run all the steps.</li>
<li><code>Template.Verify.ExecutionContainerFeed</code> - the container feed for the execution containers.</li>
</ol>
<figure><img src="/blog/img/supply-chain-security-with-platform-hub/process-template-parameters.png" alt="List of parameters for the Process Template"></figure>
<h3 id="processing-the-sbom">Processing the SBOM</h3>
The first step will use the package from the <code>Template.SBOM.Artifact</code>, <code>Template.Verify.Workerpool</code>, and <code>Template.Verify.ExecutionContainer</code> parameters. As a producer of this step, I opted to hardcode the execution container instead of passing it in as a parameter. The consumer shouldn’t need to worry about that configuration.
<figure><img src="/blog/img/supply-chain-security-with-platform-hub/attach-sbom-and-run-trivy-step.png" alt="Step to attach the SBOM and run Trivy"></figure>
I opted for inline scripts because Octopus Deploy stores Process Templates in git. Referencing a third-party repo felt redundant. Below is the script I used.
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="powershell"><code>$OctopusEnvironmentName = $OctopusParameters["Octopus.Environment.Name"]
$extractedPath = $OctopusParameters["Octopus.Action.Package[Template.SBOM.Artifact].ExtractedPath"]

Write-Host "The SBOM extracted file path is this value $extractedPath"
 
$sbomFiles = Get-ChildItem -Path $extractedPath -Filter "*.json" -Recurse

foreach ($sbom in $sbomFiles)
{
 Write-Host "Attaching $($sbom.FullName) as an artifacts"
 New-OctopusArtifact -Path $sbom.FullName -Name "$OctopusEnvironmentName.SBOM.JSON" 

 Write-Host "Running trivy to scan the SBOM for any new vulnerabilities since the build was run"
 trivy sbom $sbom.FullName --severity "MEDIUM,HIGH,CRITICAL" --ignore-unfixed --quiet

 if ($LASTEXITCODE -eq 0)
 {
 Write-Highlight "Trivy successfully scanned the SBOM and no new vulnerabilities were found in the referenced third-party libraries."
 }
 else
 {
 Write-Error "Trivy found vulnerabilities that must be fixed before this application version can proceed. Please update the package references and rebuild the application."
 }
} </code></pre>
<h3 id="verifying-attestations">Verifying attestations</h3>
The second step in the Process Template is much more complex. The initial configuration is similar to the first step. It uses the <code>Template.Git.AuthToken</code>, <code>Template.Verify.Workerpool</code>, and <code>Template.Verify.ExecutionContainer</code> parameters. Just like with the first step, the execution container is hardcoded.
<figure><img src="/blog/img/supply-chain-security-with-platform-hub/step-to-verify-attestations-and-run-trivy.png" alt="Step to verify attestations and run Trivy"></figure>
The complexity stems from decisions I made as the producer of the step to make it easier for consumers to use the template.
<ul>
<li>Maximum re-use: the Process Template must support 1 to N packages/containers. The consumer shouldn’t need to provide a list of those packages/containers either. That information is stored in the variable manifest.</li>
<li>The consumer shouldn’t have to hardcode information that is already included in the variable manifest. For example the GitHub repo is stored in the build information variables.</li>
</ul>
The <code>gh attestation verify</code> command presented two challenges. That command needs a hash to lookup the attestation.
<ol>
<li>For zip / JAR / WAR / NuGet files the hash is created from the file itself. <code>gh attestation verify</code> requires the path to the folder.</li>
<li>For containers the digest hash is used. For private container repositories, verification must occur prior to invoking <code>gh attestation verify</code>.</li>
</ol>
For my applications, I have the following benefits:
<ul>
<li>All services and websites are hosted on Kubernetes clusters.</li>
<li>All containers publicly accessible on <a href="https://hub.docker.com">hub.docker.com</a>.</li>
<li>All deployments to database backends or other services occur via a <a href="https://octopus.com/docs/infrastructure/workers/kubernetes-worker">Kubernetes worker</a> running on the same cluster.</li>
</ul>
That allowed me to perform a couple of shortcuts unique to my configuration.
<ul>
<li>Octopus will download all containers/packages to the same Kubernetes cluster at the start of the deployment.</li>
<li>Any package (including the SBOM package) needed for the deployment is stored in the <code>octopus/files</code> directory.</li>
<li>Being public containers on DockerHub, I didn’t have to worry about authentication when pulling the digest for the container.</li>
</ul>
Below is the PowerShell that works for my configuration. It will require some modifications if you wish to include it in your instance. I’m providing it for example use only.
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="powershell"><code>$gitHubToken = $OctopusParameters["Template.Git.AuthToken"]

$buildInformation = $OctopusParameters["Octopus.Deployment.PackageBuildInformation"]
$OctopusEnvironmentName = $OctopusParameters["Octopus.Environment.Name"]

Write-Host "Getting a list of packages and containers to attest to from the variable manifest"
$objectArray = @()
foreach ($key in $OctopusParameters.Keys)
{
 if ($key -like "*.PackageId")
 {
 Write-Host "Found a package Id parameter: $key - checking to see if it already is in the packages to verify"
 
 $packageId = $OctopusParameters[$key]
 Write-Host "The package ID to check for is $packageId"

 $packageVersionKey = $key -replace ".PackageId", ".PackageVersion"
 Write-Host "The package version key is $packageVersionKey"
 $packageVersion = $OctopusParameters[$packageVersionKey]
 Write-Host "The package version is $packageVersion"

 $packageVersionToVerify = "$($packageId):$($packageVersion)"

 if ($objectArray -contains "$packageVersionToVerify")
 {
 Write-Host "$packageVersionToVerify already exists in the array"
 }
 else
 {
 Write-Host "$packageVersionToVerify does not exist - adding it"
 $objectArray += $packageVersionToVerify
 } 
 } 
}

Write-Host "Getting the GitHub repository from the build information"
$buildInfoObject = ConvertFrom-Json $buildInformation
$vcsRoot = $null

Write-Host "Getting the repo name from build information"
foreach ($packageItem in $objectArray)
{
 $artifactToCompare = $packageItem.Trim().Split(':')
 $packageVersion = $artifactToCompare[1]
 
 Write-Host "The version to look for is: $packageVersion"
 
 foreach ($package in $buildInfoObject)
 {
 Write-Host "Comparing $($package.Version) with $($packageVersion)"
 if ($packageVersion -eq $package.Version)
 {
 Write-Host "Versions match, getting the build URL" 
 $vcsRoot = $package.VcsRoot
 Write-Host "The vcsRoot is $vcsRoot" 
 }
 }
}

if ($null -eq $vcsRoot)
{
 Write-Error "Unable to pull the build information URL from the Octopus Build information using supplied versions in $packageName. Check that the build information has been supplied and try again."
}

$githubLessUrl = $vcsRoot -Replace "https://github.com/", ""

$env:GITHUB_TOKEN = $gitHubToken

Write-Host "Verifying the attestation of all the found packages and containers."
foreach($packageItem in $objectArray)
{ 
 Write-Host "Verifying $packageItem"
 $artifactToCompare = $packageItem.Trim().Split(':')
 $packageName = $artifactToCompare[0].Replace("/", "")
 
 if ($packageItem.Contains("/"))
 {
 $imageToAttest = "oci://$packageItem"

 Write-Host "Attesting to $imageToAttest in the repo $githubLessUrl"
 $attestation=gh attestation verify "$imageToAttest" --repo $githubLessUrl --format json 

 if ($LASTEXITCODE -ne 0)
 {
 Write-Error "The attestation for $packageItem could not be verified"
 }

 Write-Highlight "$packageItem successfully passed attestation verification"
 Write-Verbose $attestation

 Write-Host "Writing the attest output to $packageName.$OctopusEnvironmentName.attestation.json"
New-Item -Name "$packageName.$OctopusEnvironmentName.attestation.json" -ItemType "File" -Value $attestation
New-OctopusArtifact -Path "$packageName.$OctopusEnvironmentName.attestation.json" -Name "$packageName.$OctopusEnvironmentName.attestation.json"

 Write-Host "Running trivy to check the container for any known vulnerabilities that might have been discovered since the build." 
 trivy image --severity "MEDIUM,HIGH,CRITICAL" --ignore-unfixed --quiet $packageItem
 if ($LASTEXITCODE -eq 0)
 {
 Write-Highlight "Trivy successfully scanned $packageItem and no new vulnerabilities have been found in the container or base containers since they were built."
 }
 else
 {
 Write-Error "Trivy found vulnerabilities in the build artifacts that must be fixed. You can no longer deploy this release. Please update the base container version, rebuild the application, and create a new release."
 }
 }
 else
 { 
 if (Test-Path "/octopus/Files/")
 {
 Write-Host "$artifactToCompare is a package from our local repo, getting the information from /octopus/Files/"
$zipFiles = Get-ChildItem -Path "/octopus/Files/" -Filter "*$($artifactToCompare[0])*$($artifactToCompare[1])@*.zip" -Recurse
 }
 else
 {
 Write-Host "$artifactToCompare is a package from our local repo, getting the information from /home/Octopus/Files"
$zipFiles = Get-ChildItem -Path "/home/Octopus/Files" -Filter "*$($artifactToCompare[0])*$($artifactToCompare[1])@*.zip" -Recurse
 }

 $artifactVerified = $false
 foreach ($file in $zipFiles) 
 {
 if (test-path "$packageName.$OctopusEnvironmentName.attestation.json")
 {
 Continue
 }
 
 Write-Host "Attesting to $($file.FullName) in the repo $githubLessUrl"
$attestation=gh attestation verify "$($file.FullName)" --repo $githubLessUrl --format json

 if ($LASTEXITCODE -ne 0)
 {
 Write-Error "The attestation for $packageItem could not be verified - this means no attestation was generated or the package has been tampered with since it was created - stopping the deployment to avoid a security incident."
 }

 Write-Highlight "$packageItem successfully passed attestation verification"
 Write-Verbose $attestation
 $artifactVerified = $true

 Write-Host "Writing the attest output to $packageName.$OctopusEnvironmentName.attestation.json"
New-Item -Name "$packageName.$OctopusEnvironmentName.attestation.json" -ItemType "File" -Value $attestation
New-OctopusArtifact -Path "$packageName.$OctopusEnvironmentName.attestation.json" -Name "$packageName.$OctopusEnvironmentName.attestation.json"
 }

 if ($artifactVerified -eq $false)
 {
 Write-Error "The attestation for $packageItem could not be verified - this means no attestation was generated or the package has been tampered with since it was created - stopping the deployment to avoid a security incident."
 }
 } 
}</code></pre>
<h2 id="policies">Policies</h2>
Platform Hub’s Process templates are half of the solution. The other half are <a href="https://octopus.com/docs/platform-hub/Policies">Policies</a>. The Policies in Octopus Deploy can fail deployments if specific steps (or Process Templates) are not present. That same logic can be applied to runbook runs, but obviously, they’d require different steps.
<h3 id="how-policies-work">How Policies work</h3>
I want to explain Policies because they are a new concept in Octopus Deploy. Our policy engine uses Rego to query Octopus Deploy. The end goal of the policy engine is to provide “hooks” into various actions within Octopus Deploy. The first “hook” we provide is executing Deployments or Runbook Runs.
When a Deployment or Runbook Run occurs, Octopus Deploy will send <code>input</code> information to the policy engine that looks similar to the example below.
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="ruby"><code>Input:
{
 "Environment": {
 "Id": "Environments-42",
 "Name": "Test",
 "Slug": "test"
 },
 "Project": {
 "Id": "Projects-541",
 "Name": "Trident",
 "Slug": "trident-aks"
 },
 "ProjectGroup": {
 "Id": "ProjectGroups-483",
 "Name": "Kubernetes",
 "Slug": "kubernetes"
 },
 "Space": {
 "Id": "Spaces-1",
 "Name": "Default",
 "Slug": "default"
 },
 "SkippedSteps": [],
 "Steps": [
 {
 "Id": "azure-key-vault-retrieve-secrets",
 "Slug": "azure-key-vault-retrieve-secrets",
 "ActionType": "Octopus.AzurePowerShell",
 "Enabled": true,
 "IsRequired": false,
 "Source": {
 "Type": "Step Template",
 "SlugOrId": "ActionTemplates-561",
 "Version": "2"
 }
 },
 {
 "Id": "verify-build-artifacts-attach-sbom-to-release",
 "Slug": "verify-build-artifacts-attach-sbom-to-release",
 "ActionType": "Octopus.Script",
 "Enabled": true,
 "IsRequired": true,
 "Source": {
 "Type": "Process Template",
 "SlugOrId": "deploy-process-verify-build-artifacts",
 "Version": "2.5.0"
 }
 },
 {
 "Id": "verify-build-artifacts-verify-docker-containers",
 "Slug": "verify-build-artifacts-verify-docker-containers",
 "ActionType": "Octopus.Script",
 "Enabled": true,
 "IsRequired": true,
 "Source": {
 "Type": "Process Template",
 "SlugOrId": "deploy-process-verify-build-artifacts",
 "Version": "2.5.0"
 }
 },
 {
 "Id": "deploy-k8s-manifest-deploy-container",
 "Slug": "deploy-k8s-manifest-deploy-container",
 "ActionType": "Octopus.KubernetesDeployRawYaml",
 "Enabled": true,
 "IsRequired": false,
 "Source": {
 "Type": "Process Template",
 "SlugOrId": "deploy-process-deploy-to-kubernetes-via-manifest",
 "Version": "1.1.0"
 }
 },
 {
 "Id": "deploy-k8s-manifest-verify-deployment",
 "Slug": "deploy-k8s-manifest-verify-deployment",
 "ActionType": "Octopus.Script",
 "Enabled": true,
 "IsRequired": false,
 "Source": {
 "Type": "Process Template",
 "SlugOrId": "deploy-process-deploy-to-kubernetes-via-manifest",
 "Version": "1.1.0"
 }
 },
 {
 "Id": "notify-team-of-deployment-status",
 "Slug": "notify-team-of-deployment-status",
 "ActionType": "Octopus.Script",
 "Enabled": true,
 "IsRequired": false,
 "Source": {
 "Type": "Step Template",
 "SlugOrId": "ActionTemplates-101",
 "Version": "15"
 }
 }
 ]
}</code></pre>
The policy engine will attempt to match that input to a policy. If it matches and the policy passes, then the Deployment (or Runbook Run) can proceed. The policy’s success (or failure) will be logged to the audit log.
<figure><img src="/blog/img/supply-chain-security-with-platform-hub/policy-evaulation-logged-in-audit-log.png" alt="Policy evaluation that was logged to the audit log"></figure>
<h3 id="requiring-a-process-template">Requiring a Process Template</h3>
Using the input from before, the policy to require that the Process Template is as follows:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="ruby"><code>name = "Verify Build Artifacts Required"
description = "Requires the Process Template Deploy Process - Verify Build Artifacts for all deployments"
ViolationReason = "Deploy Process - Verify Build Artifacts is required on all deployments to K8s"

scope {
 rego = <<-EOT
 # The package name MUST match the file name that is stored in git. The file name should be verify_build_artifacts_required.ocl
 package verify_build_artifacts_required 

 default evaluate := false

 # Only run this policy for deployments in the projects in the Project Group Kubernetes
 evaluate := true if {
 input.ProjectGroup.Slug == "kubernetes" 
 not input.Runbook 
 }
 EOT
}

conditions {
 rego = <<-EOT
 # The package name MUST match the file name that is stored in git. The file name should be verify_build_artifacts_required.ocl 
 package verify_build_artifacts_required

 # Assume all evaluations will fail
 default result := {"allowed": false}

 result := {"allowed": true} if {
 some step in input.Steps
 # Match using the source.SlugOrId
 step.Source.SlugOrId == "deploy-process-verify-build-artifacts" 
 # Ensure the step is enabled - if it is not then fail it.
 step.Enabled == true 
 not verify_build_artifacts_skipped
 }

 result := {"allowed": false, "Reason": "The Process Template Deploy Process - Verify Build Artifacts is required and cannot be skipped for a deployment to K8s to any environment."} if {
 verify_build_artifacts_skipped
 }

 verify_build_artifacts_skipped if {
 # Fail the evaluation if the user elects to skip the Process Template when creating the deployment
 some step in input.Steps
 step.Id in input.SkippedSteps
 step.Source.SlugOrId == "deploy-process-verify-build-artifacts"
 }
 EOT

}</code></pre>
<h2 id="bringing-everything-together">Bringing everything together</h2>
Adding the Process Template to the deployment process is the same as adding any other step to a deployment process.
<figure><img src="/blog/img/supply-chain-security-with-platform-hub/adding-process-template-to-deploy-process.png" alt="Adding a Process Template to the deploy process with parameters being populated"></figure>
A deployment to the test environment will then show both Policies and Process Templates in action. Because the Process Template is part of the deployment the Policy check passes and the deployment was successful.
<figure><img src="/blog/img/supply-chain-security-with-platform-hub/deployments-with-policies-and-process-templates.png" alt="Deployment with Policies and Process Templates"></figure>
The eagle-eyed among you will likely notice that my scripts fail the deployment when a Trivy scan fails. What if you need to deploy a change to fix a show-stopping bug? I solve that by using <a href="https://octopus.com/docs/releases/guided-failures">guided failures</a>. When Trivy or an attestation verification fails, the deployment pauses and waits for a human to intervene. They decide to ignore the failure or cancel the deployment. Regardless of the decision, that information is logged in the audit log.
<h2 id="conclusion">Conclusion</h2>
I’m not naive enough to believe what is described in this post will 100% secure the software supply chain. Leveraging Process Templates and Policies in Platform Hub makes it much easier to secure the software supply chain in Octopus Deploy. Using Pull Requests in GitHub, Process Templates, Policies, ITSM, and RBAC in Octopus Deploy, it’s much easier to get to <a href="https://slsa.dev/spec/v0.1/levels">SLSA Level 4</a> than ever before. The Process Template includes the necessary steps to guarantee the build artifact about to be deployed hasn’t been tampered with and no new fixed vulnerabilities have been reported. Policies guarantee that each deployment to production includes the appropriate Process Template.
Happy deployments!]]></content>
</entry>
<entry>
<title>Deprecating support for TLS 1.0 and 1.1</title>
<link href="https://octopus.com/blog/deprecating-tls-1-0-and-1-1" />
<id>https://octopus.com/blog/deprecating-tls-1-0-and-1-1</id>
<published>2025-10-14T00:00:00.000Z</published>
<updated>2025-10-14T00:00:00.000Z</updated>
<summary>Octopus Cloud will discontinue support for connecting to targets and workers that require TLS 1.0 or 1.1.</summary>
<author>
<name>Rhys Parry, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Transport Layer Security (TLS) 1.0 and 1.1 are legacy cryptographic protocols that first appeared in 1999 and 2006, respectively. These protocols contain known security vulnerabilities, and more secure versions have superseded them, particularly TLS 1.2 (2008) and TLS 1.3 (2018).
Microsoft has progressively phased out support for TLS 1.0 and 1.1 across Windows Server operating systems:
<ul>
<li>Windows Server 2019 and later: Disables TLS 1.0 and 1.1 by default</li>
<li>Windows Server 2016: Allows you to disable TLS 1.0 and 1.1 via registry settings</li>
<li>Windows Server 2012 R2: Requires updates to support TLS 1.2 as the default protocol</li>
<li>Windows Server 2012: Requires <a href="https://support.microsoft.com/en-au/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392">specific updates</a> to support TLS 1.2</li>
</ul>
We’re following <a href="https://learn.microsoft.com/en-us/dotnet/core/extensions/sslstream-best-practices">Microsoft’s recommendation</a> by deferring TLS version selection to the Operating System. This approach prevents systems that don’t enable legacy protocols by default from using them.
<h3 id="impact-on-octopus-cloud-customers">Impact on Octopus Cloud customers</h3>
We’re removing support for these legacy protocols on Octopus Cloud to enhance security. This change will affect Tentacles on older operating systems that don’t support TLS 1.2+.
Tentacles affected by this change include those running on:
<ul>
<li>Windows Server 2012 and 2012 R2 (without <a href="https://support.microsoft.com/en-au/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392">TLS 1.2 patches</a>)</li>
</ul>
These Tentacles will need TLS 1.2+ support to maintain secure connections and continue deployments.
<div class="info">This will also affect newer Operating Systems if you have explicitly disabled TLS 1.2 or 1.3. If affected, you’ll need to re-enable TLS 1.2 or 1.3.</div>
<h3 id="impact-on-self-hosted-customers-using-linux-docker">Impact on self-hosted customers using Linux Docker</h3>
Our upgrade to Debian 12 in January 2026 will also affect customers using our official Linux Docker image. Like Octopus Cloud, your Tentacles will need TLS 1.2+ support to connect to your Octopus Server.
<h3 id="impact-on-self-hosted-customers-using-windows">Impact on self-hosted customers using Windows</h3>
Self-hosted customers running Octopus Server on Windows won’t see direct changes to their server. However, your Operating System configuration determines your TLS version availability, so you may already use TLS 1.2+ only.
Most Windows Server 2016+ installations already use TLS 1.2+ by default, so you’re likely already prepared.
<h3 id="customer-support-and-monitoring">Customer support and monitoring</h3>
For Octopus Cloud customers: We’re monitoring Octopus Cloud for usages of TLS 1.0 and 1.1, and will reach out to affected customers.
For self-hosted customers: To ensure you’re prepared, please review your environment for TLS 1.0/1.1 dependencies before the January 2026 timeline. This step will help you identify and address any compatibility requirements early.
If you believe your organization may be affected, or if you have questions about TLS protocol support, please don’t hesitate to contact our <a href="https://octopus.com/support">support team</a> for assistance.
<h3 id="what-you-can-do">What you can do</h3>
To keep your systems connected, you have several options:
Recommended approach for all customers:
<ul>
<li>Upgrade your operating system to a supported version (Windows Server 2016 or later, recent Linux distributions)</li>
<li>Update your Tentacle to the latest version, which includes enhanced TLS support</li>
<li>Review external integrations to ensure they support TLS 1.2 or higher</li>
</ul>
Alternative options for specific systems:
<ul>
<li>Windows Server 2012: Apply the <a href="https://support.microsoft.com/en-au/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392">Microsoft update to enable TLS 1.1 and TLS 1.2 as default protocols</a></li>
<li>Windows Server 2012 R2: Install all Windows updates and enable TLS 1.2 in the registry</li>
</ul>
How to check your current setup:
<ul>
<li>External service support: Most modern services already support TLS 1.2+, but you can test connections or contact service providers to confirm</li>
<li>Operating System TLS: Windows Server 2016+ and modern Linux distributions enable TLS 1.2+ by default. Older operating systems, such as Windows Server 2012/2012 R2, may require security updates to enable TLS 1.2. Since Tentacle uses your OS’s TLS capabilities, ensuring your OS supports TLS 1.2+ is the key step for compatibility</li>
</ul>
<h3 id="deprecation-timeline">Deprecation timeline</h3>
<div class="table-wrap">
<table><thead><tr><th>Period</th><th>Octopus Cloud</th><th>Self-Hosted Docker</th></tr></thead><tbody><tr><td>October - November 2025</td><td>We’ll monitor for usages of TLS 1.0/1.1</td><td>Customers should assess their environments</td></tr><tr><td>Mid-November 2025</td><td>We’ll disable TLS 1.0/1.1 on Octopus Cloud (with accommodations for affected customers)</td><td>No immediate change</td></tr><tr><td>December 2025</td><td>We’ll continue to track and help affected customers</td><td>Customers should continue preparation</td></tr><tr><td>January 2026</td><td>Octopus Cloud will use TLS 1.2+ only</td><td>We’ll upgrade the official Docker image to Debian 12, supporting TLS 1.2+ only</td></tr></tbody></table></div>
<div class="info">Note: We may adjust this timeline based on customer impact analysis and feedback. We’re committed to providing adequate notice and support throughout the transition process.</div>
<h2 id="summary">Summary</h2>
Removing support for these outdated protocols brings us in line with modern security standards. Most customers won’t be affected, but if you’re running older systems, now’s the time to plan your upgrade.
Key takeaways:
<ul>
<li>Octopus Cloud customers will see us disable TLS 1.0/1.1 from mid-November 2025, with complete removal by January 2026</li>
<li>Self-hosted Docker customers will experience changes when we upgrade the official image to Debian 12 in January 2026</li>
<li>Self-hosted Windows customers will continue to work as before</li>
</ul>
The best fix is upgrading to modern operating systems with built-in TLS 1.2+ support. If you need more time, apply security patches and enable TLS 1.2 as a temporary measure.
Our <a href="https://octopus.com/support">support team</a> is here to help throughout this transition. If you have concerns about your environment or need help with remediation, please reach out early so we can work together to ensure a smooth migration.
Happy deployments!]]></content>
</entry>
<entry>
<title>Leveling up your deployment pipelines</title>
<link href="https://octopus.com/blog/leveling-up-deployment-pipelines" />
<id>https://octopus.com/blog/leveling-up-deployment-pipelines</id>
<published>2025-10-14T00:00:00.000Z</published>
<updated>2025-10-14T00:00:00.000Z</updated>
<summary>Platform teams follow a common pattern when building deployment pipelines. Learn the three stages of evolution and how to level up your CI/CD infrastructure.</summary>
<author>
<name>Steve Fenton, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Our <a href="https://octopus.com/publications/platform-engineering-pulse">Platform Engineering Pulse report</a> gathered a list of features organizations commonly add to their internal developer platforms. We grouped sample platforms into common feature collections and found that platform teams follow similar patterns when implementing deployment pipelines.
They begin by creating an end-to-end deployment pipeline that automates the flow of changes to production and establishes monitoring. Next, they add security concerns into the pipeline to scan for vulnerabilities and manage secrets. This eventually leads to a DevOps pipeline, which adds documentation and additional automation.
You can use this pragmatic evolution of CI/CD pipelines as a benchmark and a source of inspiration for platform teams. It’s like a natural maturity model that has been discovered through practice, rather than one that has been designed upfront.
<h2 id="stage-1-deployment-pipeline">Stage 1: Deployment pipeline</h2>
The initial concern for platform teams is to establish a complete deployment pipeline, allowing changes to flow to production with high levels of automation. Although the goal is a complete yet minimal CI/CD process, it’s reassuring to see that both test automation and monitoring are frequently present at this early stage.
Early deployment pipelines involve integrating several tools, but these tools are designed to work together, making the integration quick and easy. Build servers, artifact management tools, deployment tools, and monitoring tools have low barriers to entry and lightweight touchpoints, so they feel very unified, even when provided by a mix of different tool vendors or open-source options.
In fact, when teams attempt to simplify the toolchain by using a single tool for everything, they often end up with more complexity, as tool separation enforces a good pipeline architecture.
<figure><img src="/blog/img/leveling-up-deployment-pipelines/platform-pipelines-deployment.png" alt="Deployment pipeline with stages for build, test, artifact management, deployment, and monitoring"></figure>
<h3 id="builds">Builds</h3>
Building an application from source code involves compiling code, linking libraries, and bundling resources so you can run the software on a target platform. While this may not be the most challenging task for software teams, build processes can become complex and require troubleshooting that takes time away from feature development.
When a team rarely changes its build process, it tends to be less familiar with the tools it uses. It may not be aware of features that could improve build performance, such as dependency caching or parallelization.
<h3 id="test-automation">Test automation</h3>
To shorten feedback loops, it is essential to undertake all types of testing continuously. This means you need fast and reliable test automation suites. You should cover functional, security, and performance tests within your deployment pipeline.
You must also consider how to manage test data as part of your test automation strategy. The ability to set up data in a known state will help you make tests less flaky. Test automation enables developers to identify issues early, reduces team burnout, and enhances software stability.
<h3 id="artifact-management">Artifact management</h3>
Your Continuous Integration (CI) process creates a validated build artifact that should be the canonical representation of the software version. An artifact repository ensures only one artifact exists for each version and allows tools to retrieve that version when needed.
<h3 id="deployment-automation">Deployment automation</h3>
Even at the easier end of the complexity scale, deployments are risky and often stressful. Copying the artifact, updating the configuration, migrating the database, and performing related tasks present numerous opportunities for mistakes or unexpected outcomes.
When teams have more complex deployments or need to deploy at scale, the risk, impact, and stress increase.
<h3 id="monitoring-and-observability">Monitoring and observability</h3>
While test automation covers a suite of expected scenarios, monitoring and observability help you expand your view to the entirety of your real-world software use. Monitoring implementations tend to start with resource usage metrics, but mature into measuring software from the customer and business perspective.
The ability to view information-rich logs can help you understand how faults occur, allowing you to design a more robust system.
<h2 id="stage-2-secure-pipeline">Stage 2: Secure pipeline</h2>
The natural next step for platform teams is to integrate security directly into the deployment pipeline. At this stage, teams add security scanning to automatically check for code weaknesses and vulnerable dependencies, alongside secrets management to consolidate how credentials and API keys are stored and rotated.
This shift is significant because security measures are now addressed earlier in the pipeline, reducing the risk of incidents in production. Rather than treating security as a separate concern that happens after development, it becomes part of the continuous feedback loop.
Security integration at this stage typically involves adding new tools to the existing pipeline, with well-defined touchpoints and clear interfaces. Security scanners and secrets management tools are designed to integrate with CI/CD systems, making the additions feel like natural extensions of the deployment pipeline rather than disruptive changes.
<figure><img src="/blog/img/leveling-up-deployment-pipelines/platform-pipelines-secure.png" alt="Two stages have been added to the pipeline for security scanning and secrets management"></figure>
<h3 id="security-scanning">Security scanning</h3>
While everyone should take responsibility for software security, having automated scanning available within a deployment pipeline can help ensure security isn’t forgotten or delayed. Automated scanning can provide developers with rapid feedback.
You can supplement automated scanning with security reviews and close collaboration with information security teams.
<h3 id="secrets-management">Secrets management</h3>
Most software systems must connect securely to data stores, APIs, and other services. The ability to store secrets in a single location prevents the ripple effect when a secret is rotated. Instead of updating many tools with a new API key, you can manage the change centrally with a secret store.
When you deploy an application, you usually have to apply the correct secrets based on the environment or other characteristics of the deployment target.
<h2 id="stage-3-devops-pipeline">Stage 3: DevOps pipeline</h2>
The DevOps pipeline represents a shift from building deployment infrastructure to accelerating developer productivity. At this stage, platform teams add documentation capabilities, infrastructure automation, and one-click setup for new projects. These features focus on removing friction from the developer experience.
The impact of this stage is felt most strongly at the start of new projects and when onboarding new team members. Instead of spending days or weeks on boilerplate setup, teams get a walking skeleton that fast-forwards them directly to writing their first unit test.
While the earlier stages focused on moving code through the pipeline efficiently and securely, this stage is about making the pipeline itself easy to replicate and understand. The automation added here helps teams maintain consistency across projects while giving developers the freedom to focus on features rather than configuration.
<figure><img src="/blog/img/leveling-up-deployment-pipelines/platform-pipelines-devops.png" alt="Three more stages have been added for documentation, one-click setup, and infrastructure automation"></figure>
<h3 id="documentation">Documentation</h3>
To provide documentation as a service to teams, you may either supply a platform for storing and finding documentation or use automation to extract documentation from APIs, creating a service directory for your organization.
For documentation to be successful, it must be clear, well-organized, up-to-date, and easily accessible.
<h3 id="one-click-setup-for-new-projects">One-click setup for new projects</h3>
When setting up a new project, several boilerplate tasks are required to configure a source code repository, establish a project template, configure deployment pipelines, and set up associated tools. Teams often have established standards, but manual setup means projects unintentionally drift from the target setup.
One-click automation helps teams set up a walking skeleton with sample test projects, builds, and deployment automation. This ensures a consistent baseline and speeds up the time to start writing meaningful code.
<h3 id="infrastructure-automation">Infrastructure automation</h3>
Traditional ClickOps infrastructure is hand-crafted and often drifts from the intended configuration over time. Environments may be set up differently, which means problems surface only in one environment and not another. Equally, two servers in the same environment with the same intended purpose may be configured differently, making troubleshooting problems more challenging.
Infrastructure automation solves these problems, making it easier to create new environments, spin up and tear down ephemeral (temporary) environments, and recover from major faults.
<h2 id="evolving-your-platforms-pipelines">Evolving your platform’s pipelines</h2>
Whether you choose to introduce features according to this pattern or decide to approach things differently, it is advisable to take an evolutionary approach. Delivering a working solution that covers the flow of changes from commit to production brings early value. The evolution of the platform enhances the flow and incorporates broader concerns.
Your organization may have additional compliance or regulatory requirements that could become part of a “compliant pipeline”, or you may have a heavyweight change approval process you could streamline with an “approved pipeline”.
Regardless of the requirements you choose to bring under the platform’s capabilities, you’ll be more successful if you deliver a working pipeline and evolve it to add additional features.
Happy deployments!]]></content>
</entry>
<entry>
<title>Announcing Process Templates Public Preview</title>
<link href="https://octopus.com/blog/process-templates" />
<id>https://octopus.com/blog/process-templates</id>
<published>2025-10-10T00:00:00.000Z</published>
<updated>2025-10-10T00:00:00.000Z</updated>
<summary>A blog post outlining our launch of process templates in public preview.</summary>
<author>
<name>Venkatesh Vasudevan, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Today, we’re excited to introduce Process Templates Public Preview, a powerful new feature designed to help teams harmonize their pipelines and reduce duplication across projects and teams. Process Templates enable you to easily create reusable, standardized deployment process building blocks.
<h2 id="what-are-process-templates">What are Process Templates?</h2>
Process Templates are reusable sets of deployment steps that can be shared across multiple Spaces in Octopus Deploy. Instead of copying and pasting deployment processes across teams and applications, which often leads to configuration drift, unnecessary duplication, and operational debt, you create a single source of truth that any project can consume. By abstracting your best practices for deployments into Process Templates, you make it easy for teams to follow standards and accelerate delivery.
<h2 id="why-use-process-templates">Why use Process Templates?</h2>
<ul>
<li>Reduce duplication: Update Process Templates from one place, Platform Hub, and have the changes reflected everywhere.</li>
<li>Consistency at scale: Keep your pipelines consistent no matter how many teams or projects use them.</li>
<li>Safe and secure delivery: Centralizing important deployment patterns in Process Templates ensures that your developers automatically deploy safely and securely whenever they use a Process Template.</li>
<li>Faster onboarding: Developers no longer need to worry about mis-configuring deployment processes. They can consume a trusted, version-controlled Process Template that they can rely on to be updated with best practices.</li>
<li>Shared responsibility: Empower teams with ownership over their process, maintaining flexibility while reusing best practices, ensuring a collaborative approach to deployments.</li>
</ul>
<h2 id="how-to-get-started-with-process-templates">How to get started with Process Templates</h2>
There are several common use cases for Process Templates that show how this feature improves your deployments.
<h3 id="templating-part-of-a-deployment-process">Templating part of a deployment process</h3>
Platform engineers may expect that each project includes manual approval or email notification steps in every process. Each team might build its manual approval steps and email notifications from scratch or copy them from another project. Over time, these steps diverge in configuration, leading to drift and deployment errors. Keeping these governance steps consistent across multiple pipelines requires repetitive work and is prone to errors.
With Process Templates, Platform Engineers can create a template containing the correct approval steps for every deployment process and share it with every Space. This template can be consumed in any project and added to an existing deployment process. The Process Template is customized to fit the project’s needs and will receive updates as it is updated in Platform Hub, ensuring developers can easily stay aligned with best practices.
<h3 id="templating-an-entire-deployment-process">Templating an entire deployment process</h3>
Some companies may use a microservices architecture, which is replicated across multiple projects with only the configuration changing. Even though the deployment steps are identical, platform teams must create and maintain separate processes for each service, customizing configuration values. Over time, these processes drift as it isn’t easy to update every pipeline with the latest changes. With Process Templates, Platform Engineers define the entire deployment process once, with parameterized values for all configuration differences (such as Docker image names, environment variables, or secrets). Each microservice project then consumes this template, supplying its configuration through parameters on the Process Template.
<h3 id="self-service-deployment-processes-for-application-teams">Self-Service Deployment processes for Application teams</h3>
Your company may have many application teams building new business components such as Web APIs, Frontend applications, or Storage components. You want to empower your application teams to go from zero to production-ready deployments in minutes, without waiting on team members or copying and pasting reference projects.With Process Templates, the platform team can create a library of standardized templates for each supported component type. These templates encode best practices for deploying business components. Application teams can pick the template matching their component type, fill out information that tailors the template to their project, and be ready to deploy to production with ease.
<div class="hint"><ul>
<li>For more information on use-cases, please visit our <a href="https://octopus.com/use-case/platform-hub">use-cases page</a> on our website.</li>
<li>For a demo of process templates, you can watch our <a href="https://www.youtube.com/watch?v=TuendU1wDPw">Youtube video</a>.</li>
</ul></div>
<h2 id="how-do-process-templates-work-in-octopus">How do Process Templates work in Octopus?</h2>
Process Templates are simple to set up and work similarly to a regular deployment process.
Prerequisites:
<ul>
<li>You must be on an Enterprise license.</li>
<li>You must visit Platform Hub and connect Octopus to a Git repository.</li>
</ul>
Here’s a quick rundown of how they work:
<ol>
<li>
Add a Process Template from the Process Templates interface in Platform Hub.
<figure><img src="/blog/img/process-templates/Add-Process-Template.webp" alt="Platform Hub interface that allows users to insert process templates"></figure>
</li>
<li>
Add an Octopus built-in step to your deployment process. This step is similar to the existing Process Editor in your project.
<figure><img src="/blog/img/process-templates/Add-Step-Process-Template.webp" alt="Add step to Process template"></figure>
</li>
<li>
You can use a value or a parameter when filling out a step. To set up a parameter, visit the “Add Parameter” experience on a Process Template.
<figure><img src="/blog/img/process-templates/Add-Process-Template-Parameter.webp" alt="Add step to Process template"></figure>
<figure><img src="/blog/img/process-templates/Add-Parameter-Dialog.webp" alt="Add step to Process template"></figure>
</li>
<li>
After you’ve added steps and configured parameters, you’ll need to commit, publish, and share the template. You must commit and publish a new version each time you change the template.
<figure><img src="/blog/img/process-templates/Process-Template-Commit-Flow.png" alt="Add step to Process template"></figure>
</li>
<li>
To use a Process Template in a project, you must add it via the “Add Step” experience. You can select the relevant Process Template from the dropdown and set what updates you’d like to receive.
<figure><img src="/blog/img/process-templates/Process-Template-Add-Step-Experience.png" alt="Add step to Process template"></figure>
</li>
<li>
In the Parameters tab, fill in the required parameters for the Process Template, and your Process Template is ready for deployment.
<figure><img src="/blog/img/process-templates/Process-Template-In-Editor.png" alt="Add step to Process template"></figure>
</li>
</ol>
<div class="hint">To find more in-depth information for Platform Hub, please visit <a href="https://octopus.com/docs/platform-hub">our docs</a></div>
<h2 id="conclusion">Conclusion</h2>
If your current Platform Engineering approach involves building and maintaining everything yourself, we believe process templates are a more effective solution.
Process Templates are available to all Octopus Enterprise Tier customers. An installation guide for self-hosted customers can be found on our <a href="https://octopus.com/docs/platform-hub/installation-guide">installation guide docs page</a>.
Happy deployments!]]></content>
</entry>
<entry>
<title>Resilient AI agents with MCP: Timeout and retry strategies</title>
<link href="https://octopus.com/blog/mcp-timeout-retry" />
<id>https://octopus.com/blog/mcp-timeout-retry</id>
<published>2025-10-03T00:00:00.000Z</published>
<updated>2025-10-03T00:00:00.000Z</updated>
<summary>Learn how to add timeout and retry strategies to your AI agents using the Model Context Protocol (MCP) to enhance their reliability and performance when interacting with external systems.</summary>
<author>
<name>Matthew Casperson, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[MCP reduces the barrier to entry for developers and organizations looking to automate workflows across multiple systems. But while it is possible to build a functional AI agent with just a few lines of code, production-grade systems need to be resilient and handle failures gracefully.
In this post we’ll explore the options available in Langchain and Python to add timeout, retry, and circuit breaker strategies to your AI agents using MCP.
<h2 id="why-add-timeout-and-retry-strategies">Why add timeout and retry strategies?</h2>
By their very nature, MCP clients (and the AI agents that implement them) add the most value when they are orchestrating multiple platforms. However, as the number of external systems increases, so does the likelihood of failure. External systems may be unavailable, slow to respond, or return errors. Our AI agent must be resilient and handle these failures gracefully.
Distributed systems have adopted a common set of patterns to handle failures, including timeouts, retries, and circuit breakers. These patterns help to ensure that our AI agents can continue to function, or fail gracefully, even when external systems are experiencing issues.
<h2 id="retry-strategies-in-langchain">Retry strategies in Langchain</h2>
Langchain interacts with MCP servers via tools. More specifically, tools are instances of the <a href="https://python.langchain.com/api_reference/core/tools/langchain_core.tools.structured.StructuredTool.html">StructuredTool</a> class. Langchain builds instances of StructuredTool classes for you when you call the <code>get_tools</code> function on the <a href="https://v03.api.js.langchain.com/classes/_langchain_mcp_adapters.MultiServerMCPClient.html">MultiServerMCPClient</a> class.
In theory, Langchain has the ability to define retry strategies for tools. Specifically, the <a href="https://python.langchain.com/api_reference/core/runnables/langchain_core.runnables.base.Runnable.html#langchain_core.runnables.base.Runnable">Runnable</a> class has a <code>with_retries</code> function to add retry logic to any Runnable. However, I was unable to take the <code>StructuredTool</code> instances returned by <code>get_tools</code> and add retry logic to them via the <code>with_retries</code> function, and there is no built-in support for retry strategies to tools generated by <code>MultiServerMCPClient</code> class. The inability to customize the generated tools is reflected in <a href="https://github.com/langchain-ai/langchain-mcp-adapters/issues/263">this issue</a>, which documents the limitation around error handling and MCP tools.
To work around this limitation, we will instead use the <a href="https://en.wikipedia.org/wiki/Proxy_pattern">Gang of Four proxy pattern</a> to create a wrapper around the <code>StructuredTool</code> instances returned by the <code>get_tools</code> function. It is inside this wrapper that we will implement our retry logic.
Fortunately we do not have to implement the proxy or retry logic from scratch. The <a href="https://pypi.org/project/wrapt/">wrapt</a> and <a href="https://pypi.org/project/tenacity/">tenacity</a> libraries make implementing the proxy and retry logic straightforward:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>@wrapt.patch_function_wrapper("langchain_core.tools", "StructuredTool.ainvoke")
@retry(
 stop=stop_after_attempt(3),
 wait=wait_fixed(1),
 retry=retry_if_exception_type(Exception),
)
async def structuredtool_ainvoke(wrapped, instance, args, kwargs):
 print("StructuredTool.ainvoke called")
 return await wrapped(*args, **kwargs)</code></pre>
We intercept calls to the <code>ainvoke</code> function of the <code>StructuredTool</code> class by defining a function with the <code>@wrapt.patch_function_wrapper</code> annotation. This annotation takes two arguments: the module name and the function name.
The intercepted calls are then retried with the <code>@retry</code> annotation. This annotation takes several arguments to define the retry strategy. In this example, we will retry up to three times, waiting one second between each attempt, and retry on all exceptions.
Inside the function we add some logging to provide confirmation that our proxy is being called. We then called the wrapped function, which is the original <code>ainvoke</code> function of the <code>StructuredTool</code> class.
And that is it! The <code>wrapt</code> library will intercept all calls to the <code>ainvoke</code> function of any <code>StructuredTool</code> object generated by Langchain, and our retry logic will be applied via the <code>tenacity</code> library.
:::div{.hint} One thing to watch out for using the proxy strategy is that we are wrapping an async function. Not all retry and circuit breaker libraries support async function. You’ll need to keep this in mind if you want to use other resilience libraries. :::
<h2 id="timeouts-in-langchain">Timeouts in Langchain</h2>
Timeouts can be defined through a parameter passed to the <code>ClientSession</code> constructor. The <code>MultiServerMCPClient</code> constructor exposes the <code>session_kwargs</code> argument whose values are passed to the <code>ClientSession</code> constructor.
This example demonstrates how set a read timeout of 60 seconds for a specific MCP server:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>client = MultiServerMCPClient(
 {
 "octopus": {
 "command": "npx",
 "args": [
 "-y",
 "@octopusdeploy/mcp-server",
 "--api-key",
 os.getenv("PROD_OCTOPUS_APIKEY"),
 "--server-url",
 os.getenv("PROD_OCTOPUS_URL"),
 ],
 "transport": "stdio",
 "session_kwargs": {"read_timeout_seconds": timedelta(seconds=60)},
 },
 "zendesk": {
 "command": "uv",
 "args": [
 "--directory",
 "/home/matthew/Code/zendesk-mcp-server",
 "run",
 "zendesk",
 ],
 "transport": "stdio",
 },
 }
 )</code></pre>
<h2 id="circuit-breakers-in-langchain">Circuit breakers in Langchain</h2>
Circuit breakers are used to prevent an application from repeatedly trying to execute an operation that is likely to fail. This prevents downstream services that are already struggling from being overwhelmed with requests.
We’ll make use of the <a href="https://pypi.org/project/purgatory/">purgatory</a> library to implement a circuit breaker for our MCP tools.
The first step is to create a <code>AsyncCircuitBreakerFactory</code> instance. This instance must be long-lived and shared between requests:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>circuitbreaker = AsyncCircuitBreakerFactory(default_threshold=3)</code></pre>
<div class="hint">Circuit breakers are only useful in long-lived applications, for example, a web server or a microservice. This is because the circuit breaker logic needs to maintain state about the number of recent failures. A short-lived application, such as a script that runs once and exits, will not benefit from a circuit breaker.</div>
Similar to the retry logic, we’ll use the <code>wrapt</code> library to create a proxy around the <code>ainvoke</code> function of the <code>StructuredTool</code> class, and use the <code>@circuitbreaker</code> annotation to apply the circuit breaker logic:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>@wrapt.patch_function_wrapper("langchain_core.tools", "StructuredTool.ainvoke")
@circuitbreaker("StructuredTool.ainvoke")
async def structuredtool_ainvoke(wrapped, instance, args, kwargs):
 print("StructuredTool.ainvoke called")
 return await wrapped(*args, **kwargs)</code></pre>
<h2 id="simulating-failures">Simulating failures</h2>
To simulate failures, we can create a proxy around the <code>ainvoke</code> function of the <code>BaseTool</code> class. The <code>StructuredTool</code> class inherits from the <code>BaseTool</code> class, and the <code>ainvoke</code> function of the <code>BaseTool</code> class is called by the <code>ainvoke</code> function of the <code>StructuredTool</code> class. This gives us a convenient place to simulate failures for all tools.
Here we randomly raise an exception two-thirds of the time to simulate a transient error:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>@wrapt.patch_function_wrapper("langchain_core.tools", "BaseTool.ainvoke")
async def basetool_ainvoke(wrapped, instance, args, kwargs):
 print("BaseTool.ainvoke called")
 if random.randint(1, 3) != 3:
 print("Simulated transient error")
 raise RuntimeError("Simulated transient error")
 return await wrapped(*args, **kwargs)</code></pre>
If you have implemented a circuit breaker strategy, you should see that the MCP client eventually stops calling the MCP server after a few failures. If you have implemented a retry strategy with a high level of retries, you should see the prompt succeed as the retry library intercepts the exceptions and retries the request.
<h2 id="conclusion">Conclusion</h2>
Production-grade AI agents need to handle failures gracefully. By implementing timeout, retry, and circuit breaker strategies, we can ensure that our AI agents are resilient and can continue to function even when external systems are experiencing issues.
Langchain has some built-in support for timeouts, but implementing retry and circuit breaker strategies requires some additional work. By using the <code>wrapt</code>, <code>retry</code>, and <code>pybreaker</code> libraries, we can easily add these strategies to our MCP tools via the proxy pattern.
Happy deployments!]]></content>
</entry>
<entry>
<title>Manage context window size with advanced AI agents</title>
<link href="https://octopus.com/blog/advanced-ai-agents" />
<id>https://octopus.com/blog/advanced-ai-agents</id>
<published>2025-10-02T00:00:00.000Z</published>
<updated>2025-10-02T00:00:00.000Z</updated>
<summary>Learn how to execute complex workflows using AI agents with Octopus Deploy while managing context window size limitations.</summary>
<author>
<name>Matthew Casperson, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[The promise of MCP is to expose many platforms and services to AI models, enabling complex queries and workflows to be executed with natural language prompts.
While it is tempting to believe that MCP clients can define arbitrarily complex workflows in a single prompt, in practice, the limitations of the current generation of LLMs present challenges that must be overcome. Specifically, the context window size of LLMs defines an upper limit on how much data a single MCP prompt can consume as part of a request.
In this post we’ll explore strategies for managing context window size limitations when working with AI agents and Octopus Deploy.
<h3 id="what-is-context-window-size">What is context window size?</h3>
You can think of the context window as being the amount of information an LLM can process.
Context windows are measured in tokens, which are chunks of text that can be as short as one character or as long as one word. For example, the word “chat” could be one token, while the word “chatting” could be two tokens (“chatt” and “ing”). While there is not an exact ratio between tokens and words or characters (and the ratio changes between LLMs), a rough approximation is that one token is equals four characters of English text. The Amazon documentation for <a href="https://docs.aws.amazon.com/bedrock/latest/userguide/titan-embedding-models.html">Amazon Titan models</a> notes that:
<blockquote>
The characters to token ratio in English is 4.7 characters per token, on average.
</blockquote>
The context window size is dependent on the specific LLM being used. For example, OpenAI’s gpt-5 model has a context window size of 400,000 tokens (272,000 tokens for input and 128,000 tokens for output), while some variations of the gpt-4 models have a context window size of 32,000 tokens.
These sound like large numbers, but it doesn’t take long to exhaust the context window size when working with large blobs of text or API results. JSON in particular consumes a lot of tokens. In this screenshot from the <a href="https://platform.openai.com/tokenizer">OpenAI Tokenizer tool</a>, you can see that individual quotes and braces are represented as individual tokens:
<img src="/blog/img/advanced-ai-agents/openai-tokenizer.png" alt="A screenshot of a JSON blob highlighting individual tokens">
<h3 id="prompts-that-exhaust-the-context-window">Prompts that exhaust the context window</h3>
Consider the following prompt:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="text"><code>In Octopus, get the last 10 releases deployed to the "Production" environment in the "Octopus Server" space.
Get the releases from the deployments.
In ZenDesk, get the last 100 tickets and their comments.
Create a report summarizing the issues reported by customers in the tickets. 
You must only consider tickets that mention the Octopus release versions. 
You must only consider support tickets raised by customers. 
You must use your best judgment to identify support tickets.</code></pre>
The intention here is to write a report that summarizes customer issues based on the last 10 releases of an application deployed to production. It is simple enough to write this prompt, but behind the scenes, the LLM must execute multiple API calls:
<ul>
<li>Convert the space name to a space ID</li>
<li>Convert the environment name to an environment ID</li>
<li>Get the last 10 deployments to the environment</li>
<li>Get the details of the releases from the deployments</li>
<li>Get the last 100 tickets from ZenDesk</li>
</ul>
Each of these API calls return token-gobbling JSON results that are collected and passed to the LLM to generate the report. The JSON blobs returned by Octopus can be quite verbose, and it is not hard to see how long support tickets can exhaust the context window size, especially given the tendency of email clients to include the entirety of a previous email chain in each reply.
Even if we don’t exhaust the context window size, we may still benefit from reducing the amount of data passed to the LLM, as this <a href="https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents">post from Anthropic</a> notes:
<blockquote>
Studies on needle-in-a-haystack style benchmarking have uncovered the concept of context rot: as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.
</blockquote>
When prompts like this work, they seem almost magical. But when they fail due to context window size limitations, we need to implement some advanced strategies to help manage the context window size.
<h3 id="strategies-for-managing-context-window-size">Strategies for managing context window size</h3>
As we saw in the <a href="https://octopus.com/blog/agentic-ai-with-mcp">previous post</a>, LangChain provides the ability to extract tools from MCP servers and use them in agentic workflows. We can add additional custom tools to this collection to perform operations that help manage context window size.
Consider this tool definition:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>@tool
def discard_deployments(
 tool_call_id: Annotated[str, InjectedToolCallId],
 state: Annotated[dict, InjectedState],
) -> Command:
 """Discards the list of deployments."""

 def trim_release(release):
 if isinstance(release, ToolMessage) and release.name == "list_deployments":
 release.name = "trimmed_list_deployments"
 release.content = ""
 return release

 trim_messages = [trim_release(msg) for msg in state["messages"]]

 return Command(
 update={
 "messages": [
 RemoveMessage(id=REMOVE_ALL_MESSAGES),
 *trim_messages,
 ToolMessage(
 "Discarded list of deployments", tool_call_id=tool_call_id
 ),
 ],
 }
 )</code></pre>
This tool take advantage of a number of advanced features of LangChain:
<ul>
<li>The <a href="https://python.langchain.com/api_reference/core/tools/langchain_core.tools.base.InjectedToolCallId.html">InjectedToolCallId</a> annotation to inject the unique ID of the tool call</li>
<li>The <a href="https://langchain-ai.github.io/langgraph/reference/agents/#langgraph.prebuilt.tool_node.InjectedState">InjectedState</a> annotation to inject the current state of the agent</li>
<li>Returning a <a href="https://langchain-ai.github.io/langgraph/reference/types/#langgraph.types.Command">Command</a> object to update the state of the agent</li>
<li>Using the <a href="https://python.langchain.com/api_reference/core/messages/langchain_core.messages.modifier.RemoveMessage.html">RemoveMessage</a> class to remove all messages from the agent’s state</li>
</ul>
Let’s go through this function line by line.
We start by defining a tool. A tool is simply a function decorated with the <code>@tool</code> decorator. The function docstring is used to describe the tool to the LLM, and is how the LLM knows when to call the tool based on the plain text instructions in the prompt.
This two has two parameters, <code>tool_call_id</code> and <code>state</code>.
The <code>tool_call_id</code> parameter is annotated with the <code>InjectedToolCallId</code> annotation, which tells LangChain to inject the unique ID of the tool call into this parameter.
The <code>state</code> parameter is annotated with the <code>InjectedState</code> annotation, which tells LangChain to inject the current state of the agent into this parameter. It is this state that we want to modify:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>@tool
def discard_deployments(
 tool_call_id: Annotated[str, InjectedToolCallId],
 state: Annotated[dict, InjectedState],
) -> Command:
 """Discards the list of deployments."""</code></pre>
A nested function called <code>trim_release</code> is defined to process each message in the agent’s state. If the message is a <code>ToolMessage</code> with the name <code>list_deployments</code> (this is the name of the tool exposed by the Octopus MCP server), it changes the name to <code>trimmed_list_deployments</code> and clears the content. This effectively removes the verbose JSON content from the message while retaining a record that the tool was called:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code> def trim_release(release):
 if isinstance(release, ToolMessage) and release.name == "list_deployments":
 release.name = "trimmed_list_deployments"
 release.content = ""
 return release</code></pre>
We then use a list comprehension to apply the <code>trim_release</code> function to each message in the agent’s state, producing a new list of messages with the deployments trimmed:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>trim_messages = [trim_release(msg) for msg in state["messages"]]</code></pre>
We then return a <code>Command</code> object that updates the agent’s state. <code>Command</code> objects allow us to update the state of the agent. It is the messages in the state that are placed in the context window, so by modifying these messages, we can manage the context window size.
By default, messages returned from a tool are appended to the existing messages in the state. However, in this case, we want to remove all existing messages and replace them with our trimmed messages. We do this by including a <code>RemoveMessage</code> object with the special ID <code>REMOVE_ALL_MESSAGES</code>, which tells LangChain to remove all existing messages from the state.
Finally, we include our trimmed messages and a new <code>ToolMessage</code> indicating that the deployments have been discarded. This message includes the <code>tool_call_id</code> so that it can be traced back to the specific tool call:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>return Command(
 update={
 "messages": [
 RemoveMessage(id=REMOVE_ALL_MESSAGES),
 *trim_messages,
 ToolMessage(
 "Discarded list of deployments", tool_call_id=tool_call_id
 ),
 ],
 }
 )</code></pre>
Our custom tool is added to the collection of tools exported from the MCP servers:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>tools = await client.get_tools()
tools.append(discard_deployments)</code></pre>
And we can call the new tool from our prompt with the instruction <code>Discard the list of deployments</code>:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="text"><code>In Octopus, get the last 10 releases deployed to the "Production" environment in the "Octopus Server" space.
Get the releases from the deployments.
Discard the list of deployments.
In ZenDesk, get the last 100 tickets and their comments.
Create a report summarizing the issues reported by customers in the tickets. 
You must only consider tickets that mention the Octopus release versions. 
You must only consider support tickets raised by customers. 
You must use your best judgement to identify support tickets.</code></pre>
Now, once the LLM has called the Octopus MCP server to get the list of deployments, and retrieved the releases from those deployments, it calls our custom tool to discard the deployments JSON blob from the state, which in turn means those messages are not passed to the LLM as part of the context window. The deployments were never needed for the final report, so we have reduced the amount of data passed to the LLM without losing any important information.
There are a number of other opportunities to reduce the size of the messages passed to the LLM. The JSON blobs related to releases can be replaced by the release versions, and the ZenDesk tickets can be trimmed.
<h2 id="full-source-code">Full source code</h2>
This is the complete source code, including the additional custom tools used to trim the release details to just the version (<code>trim_releases_to_version</code>) and trim the ticket descriptions to 1000 characters (<code>trim_ticket_descriptions</code>), and the additional instructions in the prompt to call these tools:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>import asyncio
import json
import os
import re
from typing import Annotated

from langchain_core.messages import RemoveMessage, ToolMessage, trim_messages
from langchain_core.tools import tool, InjectedToolCallId
from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain_azure_ai.chat_models import AzureAIChatCompletionsModel
from langgraph.graph.message import REMOVE_ALL_MESSAGES
from langgraph.prebuilt import create_react_agent, InjectedState
from langgraph.types import Command


def remove_line_padding(text):
 """
 Remove leading and trailing whitespace from each line in the text.
 :param text: The text to process.
 :return: The text with leading and trailing whitespace removed from each line.
 """
 return "\n".join(line.strip() for line in text.splitlines() if line.strip())


def remove_thinking(text):
 """
 Remove <think>...</think> tags and their content from the text.
 :param text: The text to process.
 :return: The text with <think>...</think> tags and their content removed.
 """
 stripped_text = text.strip()
 if stripped_text.startswith("<think>") and "</think>" in stripped_text:
return re.sub(r"<think>.*?</think>", "", stripped_text, flags=re.DOTALL)
 return stripped_text


def response_to_text(response):
 """
 Extract the content from the last message in the response.
 :param response: The response dictionary containing messages.
 :return: The content of the last message, or an empty string if no messages are present.
 """
 messages = response.get("messages", [])
 if not messages or len(messages) == 0:
 return ""
 return messages.pop().content


@tool
def trim_ticket_descriptions(
 tool_call_id: Annotated[str, InjectedToolCallId],
 state: Annotated[dict, InjectedState],
) -> Command:
 """Trims the description of the ZenDesk tickets."""

 def trim_description(ticket):
 ticket["description"] = (
 ticket["description"][:1000] + "..."
 if len(ticket["description"]) > 1000
 else ticket["description"]
 )
 return ticket

 def trim_description_list(message):
 if isinstance(message, ToolMessage) and message.name == "get_tickets":
 ticket_data = json.loads(message.content)
 trimmed_ticket_data = [
 trim_description(ticket) for ticket in ticket_data["tickets"]
 ]
 message.content = json.dumps(trimmed_ticket_data)
 return message

 trim_messages = [trim_description_list(msg) for msg in state["messages"]]

 return Command(
 update={
 "messages": [
 RemoveMessage(id=REMOVE_ALL_MESSAGES),
 *trim_messages,
 ToolMessage("Trimmed releases to version", tool_call_id=tool_call_id),
 ],
 }
 )


@tool
def discard_deployments(
 tool_call_id: Annotated[str, InjectedToolCallId],
 state: Annotated[dict, InjectedState],
) -> Command:
 """Discards the list of deployments."""

 def trim_release(release):
 if isinstance(release, ToolMessage) and release.name == "list_deployments":
 release.name = "trimmed_list_deployments"
 release.content = ""
 return release

 trim_messages = [trim_release(msg) for msg in state["messages"]]

 return Command(
 update={
 "messages": [
 RemoveMessage(id=REMOVE_ALL_MESSAGES),
 *trim_messages,
 ToolMessage("Discarded list of deployments", tool_call_id=tool_call_id),
 ],
 }
 )


@tool
def trim_releases_to_version(
 tool_call_id: Annotated[str, InjectedToolCallId],
 state: Annotated[dict, InjectedState],
) -> Command:
 """Trims the details of Octopus releases to their version."""

 def trim_release(release):
 if isinstance(release, ToolMessage) and release.name == "get_release_by_id":
 release_data = json.loads(release.content)
 release.name = "trimmed_release"
 release.content = release_data.get("version", "Unknown Version")
 return release

 trim_messages = [trim_release(msg) for msg in state["messages"]]

 return Command(
 update={
 "messages": [
 RemoveMessage(id=REMOVE_ALL_MESSAGES),
 *trim_messages,
 ToolMessage("Trimmed releases to version", tool_call_id=tool_call_id),
 ],
 }
 )


async def main():
 """
 The entrypoint to our AI agent.
 """
 client = MultiServerMCPClient(
 {
 "octopus": {
 "command": "npx",
 "args": [
 "-y",
 "@octopusdeploy/mcp-server",
 "--api-key",
 os.getenv("PROD_OCTOPUS_APIKEY"),
 "--server-url",
 os.getenv("PROD_OCTOPUS_URL"),
 ],
 "transport": "stdio",
 },
 "zendesk": {
 "command": "uv",
 "args": [
 "--directory",
 "/home/matthew/Code/zendesk-mcp-server",
 "run",
 "zendesk",
 ],
 "transport": "stdio",
 },
 }
 )

 # Use an Azure AI model
 llm = AzureAIChatCompletionsModel(
 endpoint=os.getenv("AZURE_AI_URL"),
 credential=os.getenv("AZURE_AI_APIKEY"),
 model="gpt-5-mini",
 )

 tools = await client.get_tools()
 tools.append(discard_deployments)
 tools.append(trim_releases_to_version)
 tools.append(trim_ticket_descriptions)

 agent = create_react_agent(llm, tools)
 response = await agent.ainvoke(
 {
 "messages": remove_line_padding(
 """
 In Octopus, get the last 10 releases deployed to the "Production" environment in the "Octopus Server" space.
 Get the releases from the deployments.
 Trim the details of Octopus releases to their version.
 Discard the list of deployments.
 In ZenDesk, get the last 100 tickets and their comments.
 Trim the description of the ZenDesk tickets.
 Create a report summarizing the issues reported by customers in the tickets. 
 You must only consider tickets that mention the Octopus release versions. 
 You must only consider support tickets raised by customers. 
 You must use your best judgment to identify support tickets.
 """
 )
 }
 )
 print(remove_thinking(response_to_text(response)))


asyncio.run(main())</code></pre>
<h2 id="alternative-strategies">Alternative strategies</h2>
LangChain also exposes the <a href="https://docs.langchain.com/oss/python/langchain/agents#pre-model-hook">pre-model hook</a> and <a href="https://docs.langchain.com/oss/python/langchain/agents#post-model-hook">post-model hook</a> to allow you to manipulate the state of the AI agent at various points in the processing of a request. The pre-model hook specifically is designed to support message trimming and summarization as a way to manage context window size.
<h2 id="conclusion">Conclusion</h2>
The ability of MCP to define complex, multi-system workflows in natural language is almost magical. By hiding the complexity of API calls behind simple prompts, MCP empowers users to automate tasks that would otherwise require significant custom code.
However, as you work with larger datasets and more complex workflows, you will encounter limitations around LLM context window sizes, and at this point you will need to implement strategies to manage the context window size.
Fortunately, LangChain exposes a number of advanced features that provide a deep level of control over the state of the agent, which in turn allows you to manage the context window size effectively.
This post provided examples of custom tools that manipulated the state of the agent to trim or discard unnecessary data. This allows you to work with data more efficiently and allows your prompts to scale across more systems and larger datasets.
Happy deployments!]]></content>
</entry>
<entry>
<title>Agentic AI with model context protocol (MCP)</title>
<link href="https://octopus.com/blog/agentic-ai-with-mcp" />
<id>https://octopus.com/blog/agentic-ai-with-mcp</id>
<published>2025-10-01T00:00:00.000Z</published>
<updated>2025-10-01T00:00:00.000Z</updated>
<summary>Learn how to create a simple AI agent using the Octopus Model Context Protocol (MCP) server to implement an agentic AI system.</summary>
<author>
<name>Matthew Casperson, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[If you’ve ever asked a platform like ChatGPT to book your next holiday, order groceries, or schedule a meeting, you’ll understand the potential of large language models (LLMs), and likely have been frustrated by a response like <code>I'm not able to book flights directly</code>.
By default, LLMs are disconnected from the internet and can’t perform tasks on your behalf. But they feel so tantalizingly close to being your own personal assistant.
The model context protocol (MCP) is an open standard that enables LLMs to connect to external tools and data sources. When an LLM is connected to an MCP server, it gains the ability to perform actions on your behalf, transforming it from a passive information source into an active agent.
Agentic AI systems go one step further with the creation of AI agents with specific instructions to perform tasks autonomously, as this quote from <a href="https://www.ibm.com/think/topics/agentic-ai">IBM</a> describes:
<blockquote>
Agentic AI is an artificial intelligence system that can accomplish a specific goal with limited supervision. It consists of AI agents—machine learning models that mimic human decision-making to solve problems in real time.
</blockquote>
In this post, we’ll explore how to create a simple AI agent connecting the Octopus and GitHub MCP servers to implement an agentic AI system.
<h2 id="prerequisites">Prerequisites</h2>
The sample application demonstrated in this post is written in Python. You can download Python from <a href="https://www.python.org/downloads/">python.org</a>.
We’ll also use <code>uv</code> to manage our virtual environment. You can install <code>uv</code> by following the <a href="https://docs.astral.sh/uv/getting-started/installation/">documentation</a>.
<h2 id="dependencies">Dependencies</h2>
Our AI agent will use <a href="https://www.langchain.com/">LangChain</a>, a popular framework for building AI applications.
Save the following dependencies to a <code>requirements.txt</code> file:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="text"><code>langchain-mcp-adapters
langchain-ollama
langchain-azure-ai
langgraph</code></pre>
Create a virtual environment and install the dependencies:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>uv venv
# This instruction is provided by the previous command and is specific to your OS
source .venv/bin/activate
uv pip install -r requirements.txt</code></pre>
<h2 id="text-processing-functions">Text processing functions</h2>
A big part of working with LLMs is cleaning and processing text. AI agents sit at the intersection between LLMs consuming and generating natural language and imperative code that requires predictable inputs and outputs. In practice, this means AI agents spend a lot of time manipulating strings.
We start with a function to trim the leading and trailing whitespace from each line in a block of text:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>def remove_line_padding(text):
 """
 Remove leading and trailing whitespace from each line in the text.
 :param text: The text to process.
 :return: The text with leading and trailing whitespace removed from each line.
 """
return "\n".join(line.strip() for line in text.splitlines() if line.strip())</code></pre>
Next, we have a function to remove <code><think>...</think></code> tags and their content from the text. The <code><think></code> tag is an informal convention used by reasoning LLMs to wrap the model’s internal reasoning steps.
OpenAI describes reasoning models <a href="https://platform.openai.com/docs/guides/reasoning">like this</a>:
<blockquote>
Reasoning models think before they answer, producing a long internal chain of thought before responding to the user.
</blockquote>
We typically don’t want to display the internal chain of thought in the final output, so we remove it:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>def remove_thinking(text):
 """
 Remove <think>...</think> tags and their content from the text.
 :param text: The text to process.
 :return: The text with <think>...</think> tags and their content removed.
 """
 stripped_text = text.strip()
 if stripped_text.startswith("<think>") and "</think>" in stripped_text:
return re.sub(r"<think>.*?</think>", "", stripped_text, flags=re.DOTALL)
 return stripped_text</code></pre>
<h2 id="extracting-responses">Extracting responses</h2>
LangChain provides a common abstraction over many AI platforms. These platforms will often have their own specific APIs. Consequently, LangChain functions frequently return generic dictionary objects containing the response to API calls. It is our responsibility to access the required data from these dictionaries.
We’ll be using the Azure AI Foundry service for this demo, and making use of the <a href="https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/chatgpt">Chat completions API</a>.
The response from the Chat completion API is a dictionary with a <code>messages</code> key containing a list of message objects. Here we extract the list of messages and return the content of the last message, or an empty string if no messages are present:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>def response_to_text(response):
 """
 Extract the content from the last message in the response.
 :param response: The response dictionary containing messages.
 :return: The content of the last message, or an empty string if no messages are present.
 """
 messages = response.get("messages", [])
 if not messages or len(messages) == 0:
 return ""
 return messages.pop().content</code></pre>
<h2 id="setting-up-mcp-servers">Setting up MCP servers</h2>
We can now start building the core functionality of our AI agent.
Our agent will use two MCP servers: the Octopus MCP server to interact with an Octopus instance, and the GitHub MCP server to interact with GitHub repositories.
These MCP servers are represented by the <code>MultiServerMCPClient</code> class, which is a client for connecting to multiple MCP servers:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>async def main():
 """
 The entrypoint to our AI agent.
 """
 client = MultiServerMCPClient(
 {
 "octopus": {
 "command": "npx",
 "args": [
 "-y",
 "@octopusdeploy/mcp-server",
 "--api-key",
 os.getenv("OCTOPUS_CLI_API_KEY"),
 "--server-url",
 os.getenv("OCTOPUS_CLI_SERVER"),
 ],
 "transport": "stdio",
 },
 "github": {
 "url": "https://api.githubcopilot.com/mcp/",
"headers": {"Authorization": f"Bearer {os.getenv('GITHUB_PAT')}"},
 "transport": "streamable_http",
 },
 }
 )</code></pre>
We then create an instance of the <code>AzureAIChatCompletionsModel</code> class to allow us to interact with the Azure AI service. This class is responsible for building the Azure AI API requests and processing the responses:
<div class="hint">LangChain provides a variety of classes to interact with different AI platforms. The ability to swap out one AI platform for another is a key benefit of frameworks like LangChain.</div>
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code> # Use an Azure AI model
 llm = AzureAIChatCompletionsModel(
 endpoint=os.getenv("AZURE_AI_URL"),
 credential=os.getenv("AZURE_AI_APIKEY"),
 model="gpt-5-mini",
 )</code></pre>
The <code>MultiServerMCPClient</code> provides access to the tools exposed by each MCP server:
<div class="hint">Tools are typically self-describing functions that an LLM can call. It is possible to <a href="https://python.langchain.com/docs/concepts/tools/">create tools manually</a>. However, the benefit of using MCP servers is that they expose tools in a consistent way that any MCP client can consume.</div>
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>tools = await client.get_tools()</code></pre>
The <code>llm</code> (which is the interface to the Azure AI service) and the <code>tools</code> (which are the functions exposed by the MCP servers) can then be used to create a ReAct agent:
<div class="hint">ReAct agents are described in the <a href="https://arxiv.org/abs/2210.03629">ReAct paper</a> and implement a feedback loop to iteratively reason and act:<img src="/blog/_astro/react-loop.SSN4AKO__ZvmItv.webp" alt="ReAct agent diagram" loading="lazy" decoding="async" fetchpriority="auto" width="1432" height="806"></div>
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>agent = create_react_agent(llm, tools)</code></pre>
We now have everything we need to instruct our AI agent to perform a task. Here, we ask the agent to provide a risk assessment of changes in the latest releases of an Octopus project. This works because this project implements <a href="https://octopus.com/docs/packaging-applications/build-servers/build-information">build information</a> to associate Git commits with each Octopus release:
<div class="hint">You’ll need to replace the name of the Octopus space in the prompt with a space that exists in your Octopus instance.</div>
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code> response = await agent.ainvoke(
 {
 "messages": remove_line_padding(
 """
 In Octopus, get all the projects from the "Octopus Copilot" space.
 In Octopus, for each project, get the latest release.
 In GitHub, for each release, get the git diff from the Git commit. 
 Scan the diff and provide a summary-level risk assessment.
 You will be penalized for asking for user input.
 """
 )
 }
 )</code></pre>
The prompt provided to the agent highlights the power of agentic AI. It is written in natural language and describes a non-trivial set of steps the same way you might describe the task to a developer.
<div class="hint">If you’re unfamiliar with prompt engineering, the instructions “penalizing” specific behavior might seem odd. This prompting style addresses a common limitation of LLMs, where they struggle with being told what not to do. The particular phrasing used here comes from the paper <a href="https://arxiv.org/html/2312.16171v1">Principled Instructions Are All You Need for Questioning</a>, which provides several common prompt engineering patterns.</div>
The response from the agent is processed and printed to the console:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>print(remove_thinking(response_to_text(response)))</code></pre>
The final step is to call the <code>main</code> function asynchronously:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>asyncio.run(main())</code></pre>
<h2 id="running-the-agent">Running the agent</h2>
Run the agent with the command:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>python3 main.py</code></pre>
If all goes well, you should see a report detailing the risk assessment of the changes in the latest releases of each project in the “Octopus Copilot” space.
<h2 id="the-complete-application">The complete application</h2>
This is the complete script:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="python"><code>import asyncio
import os
import re

from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain_azure_ai.chat_models import AzureAIChatCompletionsModel
from langgraph.prebuilt import create_react_agent


def remove_line_padding(text):
 """
 Remove leading and trailing whitespace from each line in the text.
 :param text: The text to process.
 :return: The text with leading and trailing whitespace removed from each line.
 """
 return "\n".join(line.strip() for line in text.splitlines() if line.strip())


def remove_thinking(text):
 """
 Remove <think>...</think> tags and their content from the text.
 :param text: The text to process.
 :return: The text with <think>...</think> tags and their content removed.
 """
 stripped_text = text.strip()
 if stripped_text.startswith("<think>") and "</think>" in stripped_text:
return re.sub(r"<think>.*?</think>", "", stripped_text, flags=re.DOTALL)
 return stripped_text


def response_to_text(response):
 """
 Extract the content from the last message in the response.
 :param response: The response dictionary containing messages.
 :return: The content of the last message, or an empty string if no messages are present.
 """
 messages = response.get("messages", [])
 if not messages or len(messages) == 0:
 return ""
 return messages.pop().content


async def main():
 """
 The entrypoint to our AI agent.
 """
 client = MultiServerMCPClient(
 {
 "octopus": {
 "command": "npx",
 "args": [
 "-y",
 "@octopusdeploy/mcp-server",
 "--api-key",
 os.getenv("OCTOPUS_CLI_API_KEY"),
 "--server-url",
 os.getenv("OCTOPUS_CLI_SERVER"),
 ],
 "transport": "stdio",
 },
 "github": {
 "url": "https://api.githubcopilot.com/mcp/",
"headers": {"Authorization": f"Bearer {os.getenv('GITHUB_PAT')}"},
 "transport": "streamable_http",
 },
 }
 )

 # Use an Azure AI model
 llm = AzureAIChatCompletionsModel(
 endpoint=os.getenv("AZURE_AI_URL"),
 credential=os.getenv("AZURE_AI_APIKEY"),
 model="gpt-5-mini",
 )

 tools = await client.get_tools()
 agent = create_react_agent(llm, tools)
 response = await agent.ainvoke(
 {
 "messages": remove_line_padding(
 """
 In Octopus, get all the projects from the "Octopus Copilot" space.
 In Octopus, for each project, get the latest release.
 In GitHub, for each release, get the git diff from the GitHub Commit. 
 Scan the diff and provide a summary-level risk assessment.
 You will be penalized for asking for user input.
 """
 )
 }
 )
 print(remove_thinking(response_to_text(response)))


asyncio.run(main())</code></pre>
<h2 id="challenges-with-agentic-ai">Challenges with agentic AI</h2>
Describing complex tasks in natural language is a powerful capability, but it can mask some of the challenges with agentic AI.
The ability to correctly execute the instructions depends a great deal on the model used. We used the <code>gpt-5-mini</code> model from Azure AI Foundry in this example. I selected this model after some trial and error with different models that failed to select the correct tools to complete the task. For instance, GPT 4.1 continually attempted to load Octopus project details from GitHub. Other models can produce very different results for exactly the same code and prompt, and it is often unclear why.
The quality of the prompt is also important. LLMs are not universally advanced enough today to correctly interpret all prompts. Prompt engineering is still required to allow AI agents to perform complex tasks.
<h2 id="next-steps">Next steps</h2>
This example provides the ability to generate one-off reports. A more complete solution would run as a long-lived process responding to events such as those generated by <a href="https://octopus.com/docs/administration/managing-infrastructure/subscriptions">Octopus subscriptions</a> to generate reports automatically when new releases are created. You’d also likely post the results to an email MCP server or an MCP server for one of the many chat platforms available today.
<h2 id="conclusion">Conclusion</h2>
It is early days for agentic AI, but the potential is clear. Agentic AI may finally deliver on the promise of low/no-code solutions that allow non-developers to automate complex tasks.
Agentic AI is not without its challenges. You still need a good understanding of the capabilities and limitations of LLMs, and prompt engineering is still required to get the best results.
However, once you strip away all the boilerplate code to interact with multiple MCP servers, it is possible to orchestrate complex tasks with just a few lines of code and a well-crafted prompt.
Learn more about the Octopus MCP server in our <a href="https://octopus.com/docs/octopus-ai/mcp">documentation</a>.
Happy deployments!]]></content>
</entry>
<entry>
<title>The power of patterns: How technology helped us see what matters</title>
<link href="https://octopus.com/blog/building-our-jira-journey-in-people" />
<id>https://octopus.com/blog/building-our-jira-journey-in-people</id>
<published>2025-10-01T00:00:00.000Z</published>
<updated>2025-10-01T00:00:00.000Z</updated>
<summary>How we integrated Jira into our people team at Octopus Deploy</summary>
<author>
<name>Mary Lee, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[When I joined Octopus in January 2023, the People team looked very different from what it is today. Back then, most of our work centered on ongoing projects and answering employee questions through Slack or email. We were like engines keeping the ship moving, focused on making sure employees were supported and cared for.
The team was still relatively new. Only a few years in, our priority was to build trust and move away from being seen as the stereotypical “HR” group. We were small and lean, most of the time we were so absorbed in the day-to-day that we rarely paused to think strategically or dive into data.
Looking back now, it is surprising that we waited so long to implement Jira. IT had already been using it successfully, and although the People team had talked about it for some time, it never became a priority. Ultimately, I took ownership and drove this forward.What started as a small idea became one of the most exciting and rewarding projects I have had the chance to lead.
<h2 id="from-idea-to-implementation">From idea to implementation</h2>
When we began, we honestly did not know what to expect. The goal was simple: build it, launch it, and see what happens. What followed far exceeded our expectations.
We knew we had to design Jira in a way that worked with Octopus’s culture. Slack is our primary communication tool, and most employee inquiries came through Slack messages. Requests from third parties, such as employment verifications, arrived in our inbox. With that in mind, we needed Jira to integrate seamlessly with Slack, so employees could continue asking questions in the same way they always had.
On the Operations side, we automated our People inbox directly into Jira and set up Slack workflows where adding specific emojis to messages automatically created tickets. This helped us avoid missing requests and improved our responsiveness.
On the HRBP side, Jira changed the way we work. Previously, we operated in silos, using Google Docs to manage performance cases, reorganizations, and other sensitive processes. With Jira, HRBPs now have a centralized place to document and track cases. This makes our work more consistent and allows any team member to step in seamlessly if needed.
<h2 id="what-changed">What changed?</h2>
For both Ops and HRBPs, the most transformative part of Jira has been reporting. What did not surprise us at first was the sheer number of tickets coming in. We already knew we were a lean team working across many priorities, but seeing the reality in numbers gave us a new appreciation for the scale of what we handle and gratitude for the team behind it.
What went beyond the numbers, however, was far more revealing. With the addition of AI powered reporting, we could move past raw volume and see deeper insights. The data showed us where questions and issues were coming from across departments, roles, and regions, which exposed weak points we had not clearly seen before. Instead of assumptions, we had evidence of where employees needed the most support.
The AI highlighted recurring themes, surfaced gaps in our processes, and even suggested where our attention should shift. It became clear for us that onboarding, offboarding, and employee recognition required more investment than we had realized. These patterns were not obvious through traditional reporting, but the AI made them visible.
This combination of real time data and AI driven analysis has turned reporting into a strategic tool. It not only helps us prioritize projects with more confidence and precision, it also guides us toward targeted improvements that will have the greatest impact on employees.
<h2 id="whats-next">What’s next?</h2>
We are only just beginning. Our next steps include expanding Jira automations, creating new workflows to support our Work from Anywhere policy, and streamlining processes around benefits and other key employee touch points.
Implementing Jira has been fun and energizing, but more than that, it has been transformative. It has given us structure, clarity, and consistency. It has helped us evolve from a team focused on tasks to one that is strategic, data informed, and scalable.
Happy deployments!]]></content>
</entry>
<entry>
<title>Introducing Argo CD in Octopus</title>
<link href="https://octopus.com/blog/argo-cd-in-octopus" />
<id>https://octopus.com/blog/argo-cd-in-octopus</id>
<published>2025-09-30T00:00:00.000Z</published>
<updated>2025-09-30T00:00:00.000Z</updated>
<summary>Argo CD is now integrated into Octopus to simplify your Kubernetes deployments</summary>
<author>
<name>Robert Erez, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Argo CD is the leading GitOps solution for Kubernetes. It excels at syncing manifests to clusters and gives engineers a powerful UI to verify and troubleshoot deployments.
However Argo CD was never designed to handle the full software delivery cycle. While platform teams can use it for cluster bootstrapping and configuration management, most real-world delivery pipelines require multiple environments, tests, security and compliance checks, change management, and many other steps. Today, many teams work around this gap by stitching together tools like Jenkins or GitHub Actions and Argo CD with custom scripting. This quickly becomes brittle. As the number of Argo CD instances, Applications, and clusters grows, so does the maintenance overhead. Engineers also lose centralized visibility and must jump between different Argo CD dashboards to understand deployment status.
Octopus solves deployment challenges at scale. As a complete CD platform, it provides guardrails, orchestration, and visibility. We realised that combining Argo CD and Octopus would allow our users to get a solution that can scale and has both great CD and GitOps capabilities. Now, with built-in support for Argo CD, teams can eliminate custom glue code and combine the strengths of both approaches out of the box.
This post introduces Argo CD in Octopus and shows how to get started.
Argo CD in Octopus is currently in Early Access, rolling out to Octopus Cloud in early October.
<h2 id="what-is-argo-cd">What is Argo CD?</h2>
Argo CD is a declarative, GitOps-based tool for deploying Kubernetes manifests. Following the <a href="https://opengitops.dev/">GitOps principles</a>, it continuously monitors Git repositories for changes and ensures that the cluster state matches the desired state described in those repositories.
<h3 id="why-is-it-good">Why is it good?</h3>
Argo CD makes Kubernetes delivery predictable and transparent. Configuration is stored as code in Git, so every deployment is versioned, auditable, and easy to roll back. Engineers can rely on Git history to know exactly what is running in a cluster. Developers don’t need direct cluster access—they simply commit changes using familiar tools and workflows, and Argo CD applies them.
A major advantage of Argo CD over many other GitOps tools is its built-in UI. The dashboard gives teams real-time visibility into application health and sync status, reducing the need for extra tooling to verify or troubleshoot deployments.
<h3 id="argo-cds-limitations">Argo CD’s limitations</h3>
It’s important to be clear about what Argo CD was designed to do and what it was not. Argo CD excels at synchronizing manifests to Kubernetes, but it is not an end-to-end Continuous Delivery solution. In practice, teams often combine it with CI/CD tools to orchestrate broader delivery pipelines. Many of Argo CD’s limitations show up when it is stretched beyond its intended scope.
<h4 id="environment-promotions">Environment promotions</h4>
Successful software delivery involves more than updating a single cluster. Changes typically progress through a series of environments, with tests and approvals at each stage. Some teams try to model this workflow directly in Git, automating Git updates with scripts, but Git was not built for environment promotion management. As a result, promotion logic can become brittle and hard to maintain, especially at scale.
Octopus solves this with advanced <a href="https://octopus.com/docs/releases/lifecycles">Environment Lifecycle modelling</a>, providing enforced guardrails that reduce the risk of premature production changes.
<h4 id="complex-orchestrations">Complex orchestrations</h4>
Argo CD’s job is to sync Kubernetes manifests. Real-world deployments often require much more — database migrations, external cloud resource updates, integration tests, compliance checks, notifications, and monitoring. Teams can add scripts or tools to cover these steps, but doing so outside of Argo CD creates fragmentation. This disjointed approach is error-prone and makes it difficult to reason about the state of the system as a whole.
Enterprises also deploy more than just Kubernetes workloads. VMs, serverless functions, and SaaS integrations are common, but Argo CD alone cannot unify these deployment targets.
Octopus solves this through its broad library of <a href="https://octopus.com/docs/projects/steps">Steps</a> and <a href="https://octopus.com/docs/infrastructure/deployment-targets">Deployment Targets</a>, covering Kubernetes, Argo CD, and much more.
<h4 id="rich-rbac-controls">Rich RBAC controls</h4>
While Argo CD integrates with Kubernetes RBAC, it lacks fine-grained role-based access control for approvals, gates, and deployment responsibilities across environments. For organizations in regulated industries, this can make it difficult to enforce compliance requirements or maintain clear audit trails.
The audit trail that can be found in git history might provide some record after the fact, but git was never built with fine-grained permissions in mind, particularly when coupled with the complex access configurations required for multi-team environment promotions or more advanced compliance and governance requirements.
Octopus solves this through the customizable <a href="https://octopus.com/docs/best-practices/octopus-administration/users-roles-and-teams">RBAC controls</a>, external <a href="https://octopus.com/docs/approvals">ITSM integrations</a> and (coming soon) <a href="https://octopus.com/docs/platform-hub/policies">Policies</a>.
<h4 id="multi-cluster-management">Multi-cluster management</h4>
Argo CD supports several different installation topologies for managing multiple clusters, <a href="https://octopus.com/docs/platform-hub/policies">each with their pros and their cons</a>.
The “hub and spoke” model allows for a single Argo CD instance to manage multiple clusters, however it requires opening up access to each cluster and does not provide very good isolation or security. A popular alternative model is installing a “standalone” Argo CD instance in each required cluster. This reduces some scaling and isolation concerns however there is now additional management and access complexity that is introduced in its place.
Octopus solves this by providing a single pane of glass through which you can view your application’s sync state, regardless of the underlying cluster that they are running on. While Octopus doesn’t currently manage the Argo CD instances themselves, the projects that your team cares about can all be presented in one place. The job of keeping the state in sync remains left to Argo CD, but this state is directed by Octopus through your git manifests.
<h2 id="introducing-argo-cd-with-octopus">Introducing Argo CD with Octopus</h2>
Octopus has had native support for Kubernetes for many years, most recently with our own live object status capability. We know that some customers want to leverage the strengths that Argo CD provides in supporting GitOps workflows. We can now provide capabilities in Octopus to get the best of both products, leveraging the strong points of each without sacrificing what makes both Argo CD and Octopus useful and without trying to hide the fact that Argo CD is playing its role.
Let’s take a look at how this new feature works. This blog post won’t explore all the possible configurations but instead run through some of the highlights as well as discuss some of our suggested best practices to make the most of these new capabilities.
<h3 id="declarative-integration">Declarative integration</h3>
In providing Argo CD integration into Octopus Deploy, it was important to us that we provide a model that would align with the way that typical users of Argo CD want to work. This means that rather than thinking of Argo CD as a typical Octopus target, we instead automatically use declarative annotations stored in the Application manifests from connected instances.
Since each Application in an Argo CD instance typically maps to a specific deployable app in a specific environment (perhaps per cluster), a series of annotations can be added to the declarative Application manifest to signal to Octopus which are relevant for a given Project and Environment deployment context.
No need to configure each application in Octopus, just connect your Argo CD to Octopus and your declarative configuration does the rest. This configuration more naturally fits into the GitOps mindset that is prevalent in Kubernetes pipelines.
<h3 id="deployments-are-commits">Deployments are commits</h3>
In Octopus, a deployment is the execution of a pipeline in the context of an environment. A successful deployment means every step in the pipeline has been completed. For Kubernetes, this might involve applying manifests with <code>kubectl</code> or upgrading Helm charts with <code>helm upgrade</code>.
Argo CD, however, works differently. Its core responsibility is to synchronize the contents of a Git repository with a Kubernetes cluster. This means that during a deployment, Octopus modifies the desired state in Git, and Argo CD takes care of reconciling those changes to the cluster.
We’ve modelled Git updates as deployment steps in Octopus. This lets you combine GitOps-driven updates with the rest of your delivery process. For example, you can run a database migration before promoting an Application through Argo CD, execute smoke tests after the update, and send a Slack notification if those tests fail.
<h3 id="argo-cd-connectivity">Argo CD connectivity</h3>
The first thing you will need to do is to set up the connection between Octopus Deploy and your Argo CD instances.
Connecting your Argo CD instance involves running an Octopus-Argo CD Gateway in the cluster alongside each Argo CD instance, and we provide a similar helpful Helm installation flow to that used by our popular <a href="https://octopus.com/docs/kubernetes/targets/kubernetes-agent">Kubernetes Agent</a>.
<img src="/blog/_astro/octopus-argo-gateway.BozMTYdZ_Qp3A0.webp" alt="Octopus Argo CD Gateway" loading="lazy" decoding="async" fetchpriority="auto" width="1510" height="592">
As part of this process, there is also the option to scope the connection to specific environments or, when relevant, tenants. Used in conjunction with Octopus Deploy’s RBAC system, this configuration provides one example where stricter controls can be optionally placed around your Argo CD instance and, by extension, deployments to the applications it manages.
<h3 id="new-octopus-steps">New Octopus steps</h3>
This first release of Argo CD integration introduces two new steps that make promotions of Argo CD Applications easier and safer.
<h4 id="update-argo-cd-application-image-tags">Update Argo CD Application Image Tags</h4>
Most changes to Kubernetes manifests are simple container image tag updates. For every infrastructure change, there are usually dozens—or even hundreds—of new application versions to deploy.
If your team manages manifest files through a separate promotion process (manual or automated) but needs a reliable way to detect new builds, update container tags, and safely promote them through environments, the Update Argo CD Application Image Tags step handles this.
<img src="/blog/_astro/deploy-is-commit-1.DbnNJPg3_Z2oCDSi.webp" alt="Argo CD watches repository for changes" loading="lazy" decoding="async" fetchpriority="auto" width="748" height="438">
When an Octopus deployment runs, it looks for Argo CD Applications annotated for the relevant project and environment. For each discovered Application (across one or many Argo CD instances), Octopus retrieves the Git location, updates the image tags in the manifests (or Helm values files), and commits the changes.
<img src="/blog/_astro/deploy-is-commit-2.DYiFWaRJ_1DpuGJ.webp" alt="Octopus updates manifest in repository" loading="lazy" decoding="async" fetchpriority="auto" width="748" height="438">
Argo CD then detects the change and syncs the updated manifests to the cluster.
<img src="/blog/_astro/deploy-is-commit-3.EVlpM1q-_11hrq4.webp" alt="Desired state applied to cluster" loading="lazy" decoding="async" fetchpriority="auto" width="724" height="415">
<h4 id="update-argo-cd-application-manifests">Update Argo CD Application Manifests</h4>
The second step supports more complex scenarios and introduces a stricter approach to managing manifests.
Unlike the Update Argo CD Application Image Tags step, which modifies existing files in an Application’s <code>source</code> folder, this step copies one or more files from a designated <code>input</code> folder and commits them into the Application <code>source</code>.
<img src="/blog/_astro/template-step-1.Bp63AZ1U_cwAVJ.webp" alt="Argo CD watches repository for changes" loading="lazy" decoding="async" fetchpriority="auto" width="1236" height="450">
During a deployment, Octopus commits the selected files. Any files with the same name are overwritten.
<img src="/blog/_astro/template-step-2.CuJUVEKz_Z2w0Eu2.webp" alt="Argo CD watches repository for changes" loading="lazy" decoding="async" fetchpriority="auto" width="1096" height="439">
Argo CD then syncs those changes to the cluster.
<img src="/blog/_astro/template-step-3.vp21_KjR_29dset.webp" alt="Argo CD watches repository for changes" loading="lazy" decoding="async" fetchpriority="auto" width="1132" height="427">
What does this enable?
<ul>
<li>Full manifest control – You can modify, add, or remove any fields in your manifests, not just image tags.</li>
<li>Application creation – You can create manifests for entirely new Argo CD Applications. For example, when creating a new tenant, environment, or cluster, Argo CD (with ApplicationSets if configured) will create a new Application, and Octopus will pick it up and generate the manifests with the next deployment.</li>
<li>Stricter governance – By overwriting files, this step enforces a single source of truth. Even if someone makes direct changes in an Application’s <code>source</code> folder, Octopus can reset them during the next deployment. This ensures only tested, approved configurations flow into production.</li>
</ul>
What can go in the <code>input</code> folder?
<ul>
<li>Shared files – The simplest option is a single file (such as Helm values) applied across environments. Updating the file before deployment creates a clear, auditable history of changes in Git.</li>
<li>Environment-specific configurations – For per-environment differences, you can either maintain separate folders or treat files as templates. Octopus variables can replace placeholders during deployment, injecting the correct values for each environment.</li>
</ul>
This flexibility lets teams choose between lightweight image updates and strict manifest ownership, depending on their governance and security needs.
<h2 id="best-practices">Best practices</h2>
We designed this feature with established Argo CD best practices in mind. Following them helps you get the most value from Octopus and avoid common pitfalls. This isn’t a full guide to GitOps and Argo CD best practices, but here are a few that are especially relevant when using Octopus with Argo CD:
<ul>
<li>Avoid putting environment configuration directly in Argo CD Application manifests. Applications should describe how to deploy, not encode environment-specific details.</li>
<li>Keep values files separate from the application source. Store them in dedicated locations so they can be promoted and managed consistently across environments.</li>
<li>Separate manifest repositories from application code repositories. This makes pipelines cleaner and avoids coupling application development with infrastructure changes.</li>
<li>Be cautious with Helm for internal applications. Helm can be useful, but for simple services, you may not need the overhead. Additionally, if Applications from different environments reference the same Helm chart, updating the chart will result in simultaneous changes to all Applications. A more secure approach would be to promote these changes through the environments instead. If you use Helm, keep a copy of the chart per environment to prevent cross-environment drift.</li>
</ul>
For more context, see <a href="https://codefresh.io/blog/argo-cd-anti-patterns-for-gitops/">Argo CD anti-patterns</a> from one of our Argo CD maintainers, and this guide on <a href="https://codefresh.io/blog/how-to-structure-your-argo-cd-repositories-using-application-sets/">structuring repositories with ApplicationSets</a>.
<h2 id="current-limitations--future-plans">Current limitations & future plans</h2>
Our goal with this first offering is to provide the core capabilities required to perform a deployment to a Kubernetes cluster via Argo CD. As such, we plan to continue investing in further features as well as improve the capabilities initially delivered.
Talking to Argo CD users, we found that about 50% polled liked having the ability to make direct changes to the manifests that Argo CD is watching to quickly push changes that might bypass typical promotion mechanisms. The other 50% preferred managing centralized templating repositories using tools like Helm or Kustomize and enforcing that all changes must be promoted through successive environments. Confusingly, a not-insignificant percentage wanted the capabilities of both patterns at once!
To move fast, we have built on top of Octopus’s current systems, and this means that particularly large repositories may take time to clone. Since the industry best practices are to separate your application code repository from your infrastructure manifests, we expect that this shouldn’t be a problem for most users; however, we are investigating some promising improvements that can be made.
<h2 id="how-to-try-it-out">How to try it out</h2>
Argo CD in Octopus is currently in Early Access, rolling out to Octopus Cloud in early October.
If you’re an Octopus Cloud user, there’s nothing extra required to enable the feature. Simply open the Argo CD Instances section under Infrastructure, and connect one of your Argo CD instances to Octopus. From there, you can start modeling deployments that combine GitOps and Continuous Delivery out of the box.
<h2 id="conclusion">Conclusion</h2>
Argo CD is a powerful GitOps tool for Kubernetes, but it wasn’t built to manage the full software delivery lifecycle. Octopus complements Argo CD by adding environment promotions, orchestration across diverse workloads, fine-grained RBAC, and centralized visibility across clusters.
With Argo CD integration, Octopus lets teams combine the strengths of GitOps and Continuous Delivery without building custom automation. You get the reliability of Git-driven deployments and the safety, governance, and flexibility of a full CD platform—all in one place.
Happy deployments!]]></content>
</entry>
<entry>
<title>Launching the Octopus MCP Server</title>
<link href="https://octopus.com/blog/launching-octopus-mcp" />
<id>https://octopus.com/blog/launching-octopus-mcp</id>
<published>2025-09-29T00:00:00.000Z</published>
<updated>2025-09-29T00:00:00.000Z</updated>
<summary>The Octopus MCP Server provides your AI assistant with powerful tools that allow it to explore, inspect, and diagnose problems within your Octopus instance, transforming it into your ultimate DevOps wingmate.</summary>
<author>
<name>Andrew Best, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Artificial intelligence, and GenAI technologies in particular, are transforming our technology landscape.
For Continuous Delivery, AI allows us to solve previously-unsolvable problems. Parsing complex log files and diagnosing root cause failures and providing intelligent remediation; natural-language exploration of your software landscape, simplifying auditing, compliance, and standardization; agentic workflows providing intelligent glue between your essential software services.
At Octopus, we are bringing these capabilities to the best Continuous Delivery tool on the market, lowering risk, improving efficiency, and accelerating your software delivery.
Our most recent AI-powered capability is the <a href="https://github.com/OctopusDeploy/mcp-server">Octopus MCP Server</a>.
<h2 id="what-is-mcp">What is MCP?</h2>
<a href="https://modelcontextprotocol.io/docs/getting-started/intro">Model Context Protocol (MCP)</a> allows the AI assistants you use in your day-to-day work, like VS Code, Claude, or ChatGPT, to connect to the systems and services you own in a standardized fashion, allowing them to pull information from those systems and services to answer questions and perform tasks.
<h2 id="the-octopus-mcp-server">The Octopus MCP Server</h2>
The Octopus MCP Server provides your AI assistant with powerful tools that allow it to explore deployments, inspect configuration, and diagnose problems within your Octopus instance, transforming it into your ultimate DevOps wingmate. For a list of supported use-cases and sample prompts, see <a href="https://octopus.com/docs/octopus-ai/mcp">our documentation</a>.
The MCP server architecture ensures that your deployment data remains secure while enabling powerful AI-assisted workflows. All interactions are logged and auditable, maintaining the compliance and governance standards your organization requires.
The initial release of the Octopus MCP Server is a local MCP server - this means it runs on your local machine, and communicates with your Octopus instance via secure HTTPS. If you are interested in remote MCP, in which the MCP server is embedded within your Octopus instance, please register your interest <a href="https://roadmap.octopus.com/c/228-remote-mcp-server-ai-">on our roadmap</a>.
<h2 id="breaking-down-devops-silos">Breaking down DevOps silos</h2>
One of the strengths of MCP is that it allows your AI assistant to perform tasks across your DevOps ecosystem. It can work alongside other MCP servers to accomplish more complex orchestrations across Octopus and your other essential DevOps services.
With Continuous Delivery, one of the challenges that arises is understanding the continual flow of changes to production, and monitoring to ensure they are happy and healthy. Typically, you need to work across a number of systems to answer questions within this space. Let’s explore how MCP supercharges our ability to do this all in one place - our AI client of choice.
<h3 id="what-has-just-shipped-and-is-it-healthy">What has just shipped, and is it healthy?</h3>
This example uses Claude Desktop, with Sonnet 4 as the model.
<blockquote>
I’d like to know what Octopus changes are just about to be released to our customers. Find the latest untenanted deployment of the Octopus Server project to the Production environment, and then find a commit in GitHub in OctopusDeploy/OctopusDeploy with a tag matching the version number of the deployment, and tell me the commit details so I can understand what is being shipped.
</blockquote>
<figure><img src="/blog/img/launching-octopus-mcp/mcp-example-1.png" alt="Octopus MCP finding the latest deployed version"></figure>
Claude has used the Octopus MCP server to explore our Octopus instance (of course we use Octopus to ship Octopus!) and find the latest release to our Production environment. It then digs into the release to find the version number of the release.
Next it uses the Github MCP server to find a commit tagged with that version. Traceability is essential in Continuous Delivery - you have to know what changes in your source control correspond to what released versions of your software.
<figure><img src="/blog/img/launching-octopus-mcp/mcp-example-2.png" alt="GitHub MCP finding the details of a deployed change"></figure>
It finds the tagged commit, digs into the details, and gives us a summary of the change - in this case it looks like a small bugfix to ensure backwards compatibility for API clients. Great!
Now, has the deployment gone smoothly? The deployment itself is green, but we know that is only the start of the story - let’s provide another prompt in the same chat to see how it is behaving out in the real world.
<blockquote>
Can you see any errors in Honeycomb regarding this release?
</blockquote>
We use <a href="https://www.honeycomb.io/">Honeycomb</a> as a key part of our observability stack at Octopus, helping us monitor our Production environment to identify, diagnose, and remediate problems as they come up.
<figure><img src="/blog/img/launching-octopus-mcp/mcp-example-3.png" alt="Honeycomb MCP checking for errors after a recent deployment"></figure>
LLMs can be quite persistent in their pursuit of an answer. In this case, Claude keeps looking for more specific examples of errors that might indicate a serialization problem, as it has understood that this is what the change was intended to fix. Very clever!
<h2 id="getting-started">Getting started</h2>
Begin your AI-powered DevOps journey today with the Octopus MCP Server. As an early access participant, you’ll help shape these features while gaining early access to capabilities that will transform how teams deploy software.
<a href="https://github.com/OctopusDeploy/mcp-server?tab=readme-ov-file#-installation">Get Started with the Octopus MCP Server</a>]]></content>
</entry>
<entry>
<title>Adoption strategies for internal platforms</title>
<link href="https://octopus.com/blog/adoption-strategies-internal-platforms" />
<id>https://octopus.com/blog/adoption-strategies-internal-platforms</id>
<published>2025-09-23T00:00:00.000Z</published>
<updated>2025-09-23T00:00:00.000Z</updated>
<summary>Our Platform Engineering pulse report looked at many aspects of real-world practice, but one interesting study area was the themes for common platform features.</summary>
<author>
<name>Matthew Allford, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Our upcoming report examines how organizations <a href="https://octopus.com/publications/platform-engineering-pulse">adopt and succeed with Platform Engineering</a>. We’ll be launching a broader survey soon to dive deeper into patterns and practices of Platform Engineering, but one of the areas that surfaced was the platform adoption strategy; whether companies make the platform optional or mandatory, and perceived success factors for each approach.
The Platform Engineering community has been pretty clear on this one. Treat your platform like a product, let it compete for internal market share, and generally, don’t mandate adoption. After all, if your platform genuinely provides a path to success and compliance with the organization’s standards, developers should naturally gravitate toward it, right?
This philosophy draws heavily from product management thinking. Just as external products succeed by solving customer problems better than alternatives, internal platforms should win developer adoption by genuinely improving their daily experience. The theory suggests that when platforms must compete for users, they naturally evolve to be more user-focused, innovative, and valuable.
<h2 id="mandatory-adoption">Mandatory adoption</h2>
Let’s be honest about why mandatory platforms are so appealing. They work. At least from an organizational standpoint. When leadership mandates platform adoption, it’s because the platform initiative is created and funded to solve specific business problems. Our research shows that the top 3 reasons for adopting Platform Engineering are to:
<ul>
<li>Improve efficiency</li>
<li>Standardize processes</li>
<li>Increase developer productivity</li>
</ul>
From a business perspective, these are legitimate wins.
The budget numbers back up the mandatory approach too. Our research found that mandatory platforms report almost 2.5x higher confidence that their funding will remain secure over the next five years.
<h2 id="optional-adoption">Optional adoption</h2>
Optional platforms can face real challenges. They struggle with budget uncertainty (2x more likely to worry about funding cuts) compared to mandatory platforms, but when platforms must compete for users, something important happens. They hyper-focus on solving real developer problems because frustrated users will simply choose alternatives if they don’t.
Organizations often undermine their own platform adoption by inconsistently enforcing standards. When teams can bypass organizational requirements for security, compliance, and operational practices, they see little value in adopting an internal developer platform. These teams happily create their own build pipelines, deploy infrastructure manually through portals, and sidestep approval processes. After all, they’re avoiding both the platform and the problems it was designed to solve.
The dynamic shifts dramatically when organizations enforce standards uniformly. When teams must meet security, compliance, and operational requirements regardless of whether they use the platform, the platform transforms from an obstacle into the obvious solution. Rather than struggling to meet complex requirements independently, teams naturally gravitate toward a platform that makes compliance straightforward and built-in.
Users choose these platforms because they genuinely make work easier while allowing them to take actions without triple-checking whether they comply with the organization’s rules.
<h2 id="the-perception-gap-between-builders-and-users">The perception gap between builders and users</h2>
This is where our research gets very interesting. We found a significant disconnect between how platform teams (producers) measure success, what consumers experience, and how the platform’s sponsors view the platform’s success.
<figure><img src="/blog/img/adoption-strategies-internal-platforms/success-radar-chart.png" alt="Radar chart displaying satisfaction levels split between mandatory and optional platforms from both producer and consumer perspectives."></figure>
For mandatory platforms, 87.5% of producers said the platform met many or all of its goals; however, only 50% of those consuming the platform agreed.
For optional platforms, 50% of producers rate them highly successful, saying they meet many or all goals, compared to 67% of consumers rating the platform as successful.
Producers think mandatory platforms are more successful, whereas consumers are more likely to rate an optional platform as successful. Mandatory platforms may suffer from producer bias, where producers overestimate the value of the platform they are building. That’s why moving beyond assumptions and measuring multiple aspects of the Platform is crucial to tracking success.
The executives and budget holders who sponsor platform initiatives overwhelmingly find that only some goals have been met, regardless of adoption strategy. This suggests that even when platforms achieve technical success, they may not deliver the business outcomes that justify their investment. This disconnect can stem from unclear or misaligned platform goals. When platform teams aren’t certain what business problems they should solve, they default to technical achievements rather than user or business outcomes.
<h2 id="measuring-platform-success">Measuring platform success</h2>
Whether the platform is mandatory or optional, you’ll hear people discuss platform adoption metrics, usually to help support how successful the platform is. However, focusing purely on adoption tells you almost nothing about whether the platform is successful. Mandatory platforms should, by definition, have high adoption rates. For optional platforms, low adoption rates could be one signal to indicate a problem with the platform that needs further investigation, but it doesn’t tell the whole story. Either way, looking at adoption alone won’t tell you whether the business is getting value, if users are satisfied, or if the platform is meeting the goals it was set out to achieve.
In fact, one metric alone won’t tell you much about the goals and success of a platform, which is why it’s crucial to capture metrics that tie back to the platform’s goals. Platform sponsors want to know whether the money and time being invested are making an impact. Capturing and presenting vanity metrics like “90% adoption rate” or “5 nines of uptime” might make platform teams feel good, but they don’t answer a fundamental question. Is this platform helping our developers be more productive and our business more successful?
We found that organizations that measure more dimensions of the Platform were more likely to be successful. In fact, there’s a clear correlation between the number of metrics tracked and platform success rates. Organizations measuring 6 or more different aspects of their platform reported the highest success rates.
<figure><img src="/blog/img/adoption-strategies-internal-platforms/high-performer-metric-count.png" alt="Bar chart showing platform success rates increasing from 33% with one metric to 75% with six or more metrics tracked."></figure>
We found that 23% of organizations don’t use metrics and instead rely on intuitive or subjective assessments. In their <a href="https://platformengineering.org/reports/state-of-platform-engineering-vol-3">state of Platform Engineering report</a>, Humanitec found 44% of organizations don’t measure any metrics. Not measuring anything creates a <a href="https://octopus.com/blog/how-organizations-measure-platform-engineering#breaking-the-success-illusion">zero-metric success illusion</a> where platform teams report high success rates simply because they’re not collecting data that might contradict their assumptions. Among organizations that do measure, many rely on technical metrics that make platform teams feel good but completely miss user satisfaction and business impact.
The solution is user-centric measurement. You can use the <a href="https://octopus.com/devops/metrics/monk-metrics/">MONK metrics</a> to measure your Platform Engineering initiative, which provides a balanced approach of benchmarkable metrics with user satisfaction that can help track the platform’s progress against business objectives.
<h2 id="when-optional-tooling-naturally-wins">When optional tooling naturally wins</h2>
Many years ago, I worked at a University, and the team I was on managed, among hundreds of other applications, the Microsoft Exchange environment for thousands of staff members. Creating shared resources like distribution lists, rooms, or shared mailboxes required several teams to be involved.
The ticket went from the support desk to team 1, to team 2, back to team 1, back to the service desk, and finally back to the user. It took an even longer path if information was missing or something needed clarification. A request from an end user for a new resource would take days, sometimes weeks. Many rules were required regarding resource names, email address formats, mail routing configurations, permissions, etc.
It was a frustrating experience for everyone involved, and we got dozens of these requests every month, sometimes more. An independent consultant surveyed the business, and at the time, the email system was the #1 critical tool being used day-to-day. We had buy-in from our managers to improve the process because it distracted systems teams from strategic work, and resulted in frustrated customers who were waiting days for their requests to be completed.
We decided to write a tool to automate the process. Initially, this was purely selfish, as we wanted to eliminate the manual work and reduce errors when we received the ticket. However, as we developed it, we realized we could give this tool directly to the service desk staff, who received the initial requests from the end users. We engaged with the service desk team, informed them of what we were planning, and listened to their requirements if they were to use the tool.
We didn’t mandate the use of the tool. The service desk team could still assign the ticket to us, and we would use the tool to create the resource. However, we found that the service desk team used the tool 100% of the time, and only issues with the tool itself were escalated to our team.
Everyone was happier. The service desk could provision resources immediately instead of waiting days for our team to get to the ticket. They had confidence that they were doing it correctly because the tool guided them through the process and validated all the inputs. Users were delighted because their requests were fulfilled instantly. We were happier as our team could focus on more strategic work instead of routine provisioning tasks, which were viewed as tedious administrative work.
I get it - this is a bespoke example, and it’s not an entire platform. But that’s kind of the point. Don’t try to build the whole platform on day 1. Find genuine pain points in existing workflows today, and start there, not with abstract goals like “improve security” that are challenging for platform creators to interpret, implement, and measure. My aim with this story isn’t to tell you about specific technology or even automation. It’s about what happens when you build something that genuinely improves the experience for everyone involved. When platforms deliver real value, adoption becomes natural rather than forced.
<h2 id="building-platforms-worth-choosing">Building platforms worth choosing</h2>
While our initial research shows that mandatory platforms achieve specific organizational metrics and enjoy better budget security, it also reveals why the Platform Engineering community advocates so strongly for optionality. The most successful platforms we studied had something in common: they would thrive even if they weren’t mandated. Consumers chose them not because they had to, but because they were the best tool for getting work done quickly and aligning with organizational standards.
So before you decide on your adoption strategy, ask yourself this question: If this platform weren’t required, would consumers still choose it? If the answer is no, you might have a platform problem, not an adoption problem. And that’s precisely the problem that Platform Engineering, done well, is designed to solve.
Happy Deployments!]]></content>
</entry>
<entry>
<title>The top 5 features of internal developer platforms</title>
<link href="https://octopus.com/blog/top-5-features-of-internal-developer-platforms" />
<id>https://octopus.com/blog/top-5-features-of-internal-developer-platforms</id>
<published>2025-09-16T00:00:00.000Z</published>
<updated>2025-09-16T00:00:00.000Z</updated>
<summary>Our Platform Engineering pulse report looked at many aspects of real-world practice, but one interesting study area was the themes for common platform features.</summary>
<author>
<name>Steve Fenton, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Our <a href="https://octopus.com/publications/platform-engineering-pulse">Platform Engineering Pulse report</a> looked at many aspects of real-world practice, but one interesting study area was the themes for common platform features. We’re launching a broader study to investigate this further, but here are the top 5 features the platform teams we asked had added to internal developer platforms.
<ol>
<li>Build automation</li>
<li>Deployment automation</li>
<li>Infrastructure automation</li>
<li>Test automation</li>
<li>Monitoring and observability</li>
</ol>
<h2 id="1-build-automation">1. Build automation</h2>
Build automation should be triggered each time you change the code and provide you with fast feedback on your changes. If you’re practicing Continuous Delivery, you’ll commit changes to the main branch every few hours, with the feedback from the build process, including fast-running tests, arriving in around 5 minutes.
The build process includes compilation, linking, and bundling. It usually consists of a suite of fast-running tests that validate the functionality and fitness of the application. In practice, this is typically a sequence of scripts or commands that run each tool in the build chain, but some build processes are more complex.
The benefit of bringing build automation into your internal developer platform is the opportunity to harmonize pipelines and bring them all up to a common standard for fast and secure builds. For example, instead of each team having to invent a way to sign their package so it can be verified later in the deployment pipeline, platform teams can make this a standard part of the build.
Development teams rarely touch their build process, compared to how much focus a platform team might put into builds. That means they are less familiar with the tools and may not be aware of features that could improve build performance or security.
<h2 id="2-deployment-automation">2. Deployment automation</h2>
Manual deployments are one of the primary reasons for bad paths to production. Even simple manual deployments can go drastically wrong, and when they do, the organization responds by introducing process steps that slow down the flow of change. This is well-meaning, but we’ve learned that reducing deployment frequency results in larger batches, which carry more risk and cause bigger problems.
Deployment automation is the heart of change in your software delivery. When deployments are reliable, repeatable, and low-effort, you can teach the organization to do them more often. Automated deployments help you build trust and reduce heavyweight processes like change approval by committee, which universally clogs the ability to deploy small batches frequently and safely.
The steps, process templates, project templates, and policies related to deployments are a perfect fit for Platform Engineering. The platform team can ensure crucial steps are included in all deployments, like verifying the provenance of the packages being deployed and ensuring the packages and deployment process have progressed through appropriate environments before reaching production.
When the organization needs to level up security across all deployments, a platform team using the right deployment tools can quickly bring the whole organization into compliance with the new standards.
<h2 id="3-infrastructure-automation">3. Infrastructure automation</h2>
There was a time when ClickOps was the default for infrastructure changes. Modern software teams have rejected the idea of managing their infrastructure by clicking around in administration consoles, cloud portals, and command lines, as the result is that no two instances of anything are the same. These differences, though sometimes subtle, can cause production incidents that are difficult to identify and resolve.
By treating infrastructure as code, the definitions can be stored in version control and follow the same review and promotion patterns developers apply to application code. When infrastructure is created and managed this way, each instance is an identical copy, and it’s easier to scale out, recover from a disaster, or create ephemeral environments for testing.
Platform teams can create standard setups for teams to use that are aligned to the technology choices in their golden pathways. Reducing the breadth of choice makes it easier to secure the infrastructure, control costs, and apply patches and updates.
<h2 id="4-test-automation">4. Test automation</h2>
Sometimes it seems there are automated tests everywhere, from unit tests that run continuously in the background as a developer makes changes, to tests used in the build process, to validate end-to-end functionality, and test the fitness of the application’s performance and security. The reason for their prevalence is that testing really works.
Without test automation, your team would need to perform the same checks manually, and when you don’t do it, your customers do, which is incredibly frustrating.
While platform teams don’t typically write tests (the research shows the most effective automated tests are written by the developer creating the feature), they can provide the tools that make it easy to define tests and have them run throughout the software delivery process. Platform teams may also provide easy ways to consume test services, making it easy to spin up end-to-end tests or performance tests without managing infrastructure.
To shorten feedback loops, all types of testing should be performed continuously and ideally represented by fast, reliable test automation suites. You should cover functional, security, and performance tests within your deployment pipeline.
You should consider how test data is managed as part of your test automation strategy. The ability to set up data in a known state will help you make tests less flaky. Test automation lets developers know early if their change causes a fault, reduces team burnout, and increases software stability.
<h2 id="5-monitoring-and-observability">5. Monitoring and observability</h2>
While test automation covers a suite of expected scenarios, monitoring and observability help you expand your view to the entirety of your real-world software use. Monitoring implementations tend to start with resource usage metrics, but mature into measuring software from the customer and business perspective.
The ability to see information-rich logs can help you understand how faults occur so you can design a more robust system.
<h2 id="other-popular-features">Other popular features</h2>
Though they didn’t make it into the top 5, documentation, security scanning, one-click setup for new projects, artifact management, and secrets management are common features of internal developer platforms.
The features are useful on their own, but when combined, they amplify their effects on overall software delivery and operational performance. Platform teams who provide a seamless toolchain from commit through to production and on to day 2 operations will find they have lifted a massive burden from developers.
<figure><img src="/blog/img/top-5-features-of-internal-developer-platforms/top-10-platform-features.png" alt="The relative popularity of the top 10 features"></figure>
<h2 id="what-high-performers-do-differently">What high performers do differently</h2>
The high-performing organizations used the amplification effect to provide a complete toolchain for deployment pipelines. Platforms that provided this set of functionality had more impact on the organization and its goals for Platform Engineering.
<ul>
<li>Builds</li>
<li>Test automation</li>
<li>Artifact management</li>
<li>Deployment automation</li>
<li>Infrastructure automation</li>
<li>Monitoring and observability</li>
</ul>
By creating a strong pipeline with equal consideration for long-term sustainability of the platform, you can create an offering that helps developers today and continues to help them as the organization navigates changing requirements, regulations, and competition.
We also looked at organizations with low performance; they were often missing 3 key features:
<ul>
<li>Test automation</li>
<li>Artifact management</li>
<li>Monitoring and observability</li>
</ul>
If your platform is missing any of these, you may be missing an opportunity to amplify the benefits of platform adoption.
<h2 id="platform-success">Platform success</h2>
Throughout our study, we used each organization’s individual definition of success for its platform. There are many different motivators for funding a platform initiative, and the ultimate test of a platform is whether it meets the specific goals it was founded to achieve.
You can use the <a href="https://octopus.com/devops/metrics/monk-metrics/">MONK metrics</a> to measure your Platform Engineering initiative. They balance benchmarkable metrics with contextual measures that track the platform’s progress against the organization’s goals.
Despite the many different ways platforms are measured, the presence of a complete feature set increased the chances of success.
Happy deployments!]]></content>
</entry>
<entry>
<title>Introducing Kubernetes Live Object Status</title>
<link href="https://octopus.com/blog/kubernetes-live-object-status" />
<id>https://octopus.com/blog/kubernetes-live-object-status</id>
<published>2025-04-16T00:00:00.000Z</published>
<updated>2025-09-15T00:00:00.000Z</updated>
<summary>The Octopus Kubernetes monitor is the next major expansion of capabilities of the Octopus Kubernetes agent.</summary>
<author>
<name>Nick Josevski, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Kubernetes is rapidly becoming the dominant platform for hosting and running applications.
At Octopus, we want to provide the best experience for deploying and monitoring your applications on Kubernetes.
To make your deployments to Kubernetes simpler, faster, and safer, Octopus has a deployment target called the Kubernetes agent. The Kubernetes agent is a small, lightweight application you install into your Kubernetes cluster.
Kubernetes Live Object Status—our Kubernetes monitor—is the next major expansion of this deployment agent’s capabilities.
<h2 id="post-deployment-monitoring">Post-deployment monitoring</h2>
Monitoring is an important part of the deployment process and is even more important for Kubernetes. It gives you confidence that your applications are running as expected.
When troubleshooting an unhealthy app, you often need to use a combination of tools and login credentials to figure out what’s going wrong. That can be quite fiddly, especially with Kubernetes. Your Octopus Deploy instance already has these credentials and awareness of your applications, similar to runbooks. We’re aiming to make Octopus the first port of call as you and your team continuously deliver software.
We roll up the combined status for the objects in a given release, per environment, into a single live status.
<img src="/blog/img/kubernetes-live-object-status/klos-project-view.png" alt="Project view with live status">Project view with live status
<h3 id="detailed-resource-inspection">Detailed resource inspection</h3>
Dive into the details of each Kubernetes resource to understand how your deployment has been configured and monitor your application itself.
Kubernetes Live Object Status gives a quick view of all the Kubernetes resources included in your application. You can then dig in to each resource to view the manifests, events and application logs for each Kubernetes resource.
<img src="/blog/img/kubernetes-live-object-status/live-status-drawer-manifest.png" alt="Kubernetes resource manifest">Kubernetes resource manifest
<h2 id="if-youre-already-using-the-kubernetes-agent">If you’re already using the Kubernetes agent</h2>
If you already use the Kubernetes agent, your upgrade path will be simple.
<h3 id="upgrading-your-agents-to-the-version-containing-the-monitor">Upgrading your agents to the version containing the monitor</h3>
We’re working on a one-click upgrade process you can access in Octopus Deploy.
If you can’t wait until then, you can upgrade existing Kubernetes agents by running a Helm command on your cluster. <a href="https://octopus.com/docs/kubernetes/live-object-status/installation#upgrading-an-existing-kubernetes-agent">See our documentation for all the details</a>.
<h2 id="new-to-using-octopus-for-kubernetes-deployments">New to using Octopus for Kubernetes deployments?</h2>
After you install the agent, it registers itself with Octopus Server as a new deployment target. This lets you deploy your applications and manifests into that cluster, without the need for workers, external credentials, or custom tooling. All new installations of the agent will have the monitor enabled.
<h3 id="installing-the-agent">Installing the agent</h3>
The Kubernetes agent gets packaged and installed via a Helm chart. This makes managing the agent very simple and makes automated installation easy.
The Kubernetes monitoring component comes along for the ride. <a href="https://octopus.com/docs/kubernetes/live-object-status/installation">See our docs for detailed instructions</a>.
<img src="/blog/img/kubernetes-live-object-status/kubernetes-agent-wizard-config.png" alt="Kubernetes agent wizard configuration options">Kubernetes agent configuration options
<h2 id="new-to-octopus-deploy-entirely">New to Octopus Deploy entirely?</h2>
How exciting! Welcome to scalable, simple, and safe Kubernetes CD with Octopus.
Octopus is one user-friendly tool for developers to deploy, verify, and troubleshoot their apps. Platform engineers use this powerful tool to fully automate Continuous Delivery, manage configuration templates, and implement compliance, security, and auditing best practices.
We empower your teams to spend less time managing and troubleshooting Kubernetes deployments and more time shipping new features to improve your software.
Octopus models environments out-of-the-box and reduces the need for custom scripting. You define your deployment process once and reuse it for all your environments. You can go to production confidently as your process has already worked in other environments.
If you’re interested in trying it out, sign up for a <a href="https://octopus.com/start">free 30-day trial</a>.
<h3 id="getting-started-with-the-agent-and-monitor">Getting started with the agent and monitor</h3>
The Octopus Kubernetes agent targets are a mechanism for executing Kubernetes steps and monitoring application health from inside the target Kubernetes cluster, rather than via an external API connection.
Like the Octopus Tentacle, the Kubernetes agent is a small, lightweight application that’s installed into the target Kubernetes cluster.
You install the Kubernetes agent using Helm via the octopusdeploy/kubernetes-agent chart. For the complete details, see our docs about <a href="https://octopus.com/docs/kubernetes/targets/kubernetes-agent#installing-the-kubernetes-agent">installing the Kubernetes agent</a>.
<h3 id="when-can-i-use-it">When can I use it?</h3>
<div class="info">Kubernetes Live Object Status is now generally available and recommended for production use for Octopus Cloud and self-hosted customers running Octopus Server 2025.3 or later.Support for Octopus Server running in high availability clusters is not yet available, but will be coming in the next self-hosted release.</div>
The Kubernetes agent is available now as an Early Access Preview (EAP) in Octopus Cloud! If you don’t see the feature available, please reach out and we can fast-track your cloud instance getting this release.
Remember this is an opt-in upgrade for existing Octopus agents installed on your cluster(s). <a href="https://octopus.com/docs/kubernetes/live-object-status/installation#upgrading-an-existing-kubernetes-agent">See this documentation page for all the details</a>.
<img src="/blog/img/kubernetes-live-object-status/kubernetes-agent-wizard-config.png" alt="Kubernetes agent as deployment targets">Kubernetes agent as deployment targets
<h2 id="how-we-built-kubernetes-live-object-status">How we built Kubernetes Live Object Status</h2>
To facilitate a potentially large flow of new data coming to Octopus Server, a separate and non-disruptive web host runs alongside the main host. This isolation level gives us confidence that this is an additive feature and if there are performance complications, they’ll get isolated and managed with minimal impact on Octopus Server’s regular operations.
The cluster-based monitoring capability uses two values to identify the incoming request:
<ul>
<li>The client certificate thumbprint</li>
<li>An installation ID in the request headers</li>
</ul>
Octopus Server uses a long-lived bearer token as a shared secret for authentication. The token gets generated when the monitoring capability installs in the cluster and registers with Octopus Server. This token is rotatable by customers and only valid for use on the gRPC endpoint.
This allowed us to build gRPC services to handle the data flowing from the monitoring agent in the Kubernetes clusters. <a href="https://grpc.io/">gRPC</a> is a modern open-source high-performance remote procedure call (RPC) framework. This is the first time we’re using gRPC as part of an Octopus feature.
In the cluster, alongside the Octopus Kubernetes agent, we have this new component that’s responsible for the monitoring aspect. It sits in the cluster and monitors the deployed resources, pumping relevant live-status data back out over gRPC to Octopus Deploy.
As we also run Octopus Deploy in Kubernetes for our Octopus Cloud customers, we have a new nginx-based ingress configuration to help with partitioning and scalability. To find out more have a look at <a href="https://www.youtube.com/watch?v=DH7YDySEPHU">how we use Kubernetes for Octopus Cloud</a>.
<h3 id="written-in-go">Written in Go</h3>
This is the first large-scale feature our team has built in <a href="https://go.dev/">Golang</a> in Octopus. This has given us access to a large set of great libraries built for Kubernetes. Examples include Helm packages and the Argo GitOps engine. Our team got the expertise uplift from the Codefresh engineers who are now part of Octopus.
The GitOps engine is a flexible library with enough configuration and extension points for us to save very specific information on a per-resource basis. This helps us get the right information out of the cluster and back to Octopus. Go is also the de facto programming language for Kubernetes.
We’re exploring options to open-source parts of our implementation. Stay tuned for when that’s all decided, as we’ll have a follow-up blog post. The likely first step will be making the source available for inspection. This is part of offering more transparency into the tools we’re asking customers to run in the security context of their clusters.
<h2 id="whats-coming-next">What’s coming next</h2>
Today’s release is the EAP. The list below represents capabilities we think are worth adding next (though it’s not the complete list). If you have thoughts and opinions, please reach out to us in the comments section below or on our <a href="https://octopus.com/slack">community Slack</a>.
<ul>
<li>Terraform-based setup</li>
<li>Support Kubernetes API targets</li>
<li>Octopus HA (multi-node server) support</li>
<li>Custom health checks</li>
<li>Orphan and drift detection</li>
</ul>
<h3 id="this-looks-cool-but-what-if-i-dont-deploy-to-kubernetes">This looks cool, but what if I don’t deploy to Kubernetes?</h3>
Currently, there are no plans to extend this beyond Kubernetes deployments. Please let us know where and why you’d like to use this monitoring capability.
<h2 id="let-us-know-your-thoughts">Let us know your thoughts</h2>
We’re excited to see how you use this monitoring feature. Please let us know in the comments section below or on our <a href="https://octopus.com/slack">community Slack</a> what new opportunities this opens up for your application delivery objectives.
Happy deployments!]]></content>
</entry>
<entry>
<title>Troubleshooting common Octopus Deploy issues</title>
<link href="https://octopus.com/blog/troubleshooting-common-octopus-deploy-issues" />
<id>https://octopus.com/blog/troubleshooting-common-octopus-deploy-issues</id>
<published>2025-09-11T00:00:00.000Z</published>
<updated>2025-09-11T00:00:00.000Z</updated>
<summary>Exploring common issues in Octopus Deploy and ways to resolve them.</summary>
<author>
<name>Donny Bell, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Octopus Deploy provides a powerful, flexible platform for automating deployments and runbook execution. However, there are times when you may encounter challenges that require troubleshooting. In this post, we’ll walk through some of the most common issues that users may run into and provide guidance on how to resolve them.
<h2 id="tentacle-communication-issues">Tentacle communication issues</h2>
Deployment targets and workers running the Octopus Tentacle agent are key to Octopus infrastructure. If Tentacles cannot communicate with your Octopus Server, deployments and runbooks will fail. Some of the issues we commonly see when setting up a new Tentacle agent include: firewall restrictions, network connectivity issues, SSL offloading, and misconfigured certificates.
Our <a href="https://octopus.com/docs/infrastructure/deployment-targets/tentacle/troubleshooting-tentacles">Troubleshooting Tentacles documentation</a> is a comprehensive guide for troubleshooting Tentacle communication issues. It covers:
<ul>
<li>Verifying that Tentacle services are running</li>
<li>Checking firewall rules</li>
<li>Ensuring correct thumbprints are configured</li>
<li>Debugging connectivity with Octopus diagnostic tools</li>
</ul>
<h2 id="calamari-issues-and-antivirus-exclusions">Calamari issues and antivirus exclusions</h2>
If you ever run into an error message in your logs that includes:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="text"><code>Bootstrapper did not return the bootstrapper service message</code></pre>
This normally indicates that antivirus or other security software is interfering with an Octopus task (such as a deployment or runbook).
Octopus tasks are powered by <a href="https://octopus.com/docs/octopus-rest-api/calamari">Calamari</a>, a lightweight deployment bootstrapper invoked for each deployment or runbook step. It’s automatically installed and updated as needed in the Tools folder of the Tentacle home directory. Additionally, steps for a given task are processed in a temporary folder inside of the Work folder, also residing in the Tentacle home directory.
Sometimes, antivirus or endpoint protection software can lock or quarantine files in these folders, causing deployments to fail.
To prevent this, we recommend working with your security team to add exclusions as necessary for these directories. For additional information, please review our <a href="https://octopus.com/docs/security/hardening-octopus#configure-malware-protection">Hardening Octopus documentation</a>.
<h2 id="polling-tentacles-over-port-443-https">Polling tentacles over port 443 (HTTPS)</h2>
In some environments, firewall policies can make it difficult or impossible to open additional ports. <a href="https://octopus.com/docs/infrastructure/deployment-targets/tentacle/polling-tentacles-over-port-443">Octopus supports configuring Polling Tentacles over port 443</a>, which allows communication through a port that is typically already allowed in enterprise networks.
This option simplifies network configuration and can reduce the setup burden in restrictive environments. This also allows for Octopus instances that communicate with other organizations or network environments to have a path for Tentacle communication that may otherwise not be possible.
<h2 id="variable-snapshots-in-projects-and-runbooks">Variable snapshots in Projects and Runbooks</h2>
Octopus variables are a seemingly simple, but common point of confusion that we often help our users with. Octopus leverages <a href="https://octopus.com/docs/releases">project releases</a> and <a href="https://octopus.com/docs/runbooks/runbook-publishing">runbooks snapshots</a> to preserve an immutable set of information to make deployments and runbooks repeatable and predictable.
You can view the variable values associated with a release by selecting the [Show Snapshot] option in the Variable Snapshot section of a release or runbook. This can be a helpful step for confirming the variable values for a given release or runbook.
<figure>
<img src="/blog/img/troubleshooting-common-octopus-deploy-issues/light-image1.png" alt="Octopus Deploy UI showing a project release and the steps to update the variables for that release">
</figure>
<a href="https://octopus.com/docs/projects/variables">Project variables and associated library variable set variables</a> are captured in a snapshot when a release or runbook snapshot is created. In order for variable updates to take effect, you must also do the following in an associated project or runbook:
For projects:
<ul>
<li>Create a new release so that the variable snapshot updates, or</li>
<li>Update an existing release’s variable snapshot</li>
</ul>
For runbooks:
<ul>
<li>Create and publish a new runbook snapshot</li>
</ul>
<div class="hint">The exception to the above is changes to Tenant variables.From our <a href="https://octopus.com/docs/tenants/tenant-variables#tenant-variables-and-snapshots">Tenant Variables documentation</a>:<blockquote>
[…] we don’t take a snapshot of tenant variables. This enables you to add new tenants at any time and deploy to them without creating a new release. This means any changes you make to tenant-variables will take immediate effect.
</blockquote></div>
<h2 id="debugging-variables-with-variable-logging">Debugging variables with variable logging</h2>
When deployments or runbooks don’t behave as expected, variable issues are a common culprit. Octopus provides the ability to debug variables by <a href="https://octopus.com/docs/support/how-to-turn-on-variable-logging-and-export-the-task-log">enabling variable logging and viewing the raw task log</a>.
By turning on variable logging, you can:
<ul>
<li>Inspect the evaluated values of your variables</li>
<li>Verify scoping and precedence rules</li>
<li>Export raw task logs for detailed review</li>
<li>Save significant troubleshooting time when debugging complex variable configurations</li>
</ul>
Alternatively, you may now enable Debug Mode for Octopus deployments and runbooks. For project deployments, this option is available on the “deploy” screen:
<figure>
<img src="/blog/img/troubleshooting-common-octopus-deploy-issues/light-image2.png" alt="Octopus Deploy UI showing a project release and the steps to enable or disable debug mode">
</figure>
When running a runbook, you must click the <code>Show advanced</code> button to reveal Debug mode:
<figure>
<img src="/blog/img/troubleshooting-common-octopus-deploy-issues/light-image3.png" alt="Octopus Deploy UI showing a runbook snapshot and the steps to enable or disable debug mode">
</figure>
<h2 id="resources-for-custom-api-scripts">Resources for custom API scripts</h2>
<a href="https://octopus.com/docs/octopus-rest-api">Octopus Deploy features a powerful REST API</a>. Many Octopus users extend their automation by writing custom scripts that interact with Octopus programmatically. You can find <a href="https://octopus.com/docs/octopus-rest-api/examples">API examples in our documentation</a>. We also offer a <a href="https://github.com/OctopusDeploy/OctopusDeploy-Api/tree/master/REST">public GitHub repository</a> with many scripts that may fit your needs as written or provide a good baseline to iterate and customize for your needs.
If you can’t find what you need or would like additional inspiration, our <a href="https://octopus.com/slack">Octopus Community Slack channel</a> is a great place to interact with other Octopus users and Octopus employees who can help!
<h2 id="conclusion">Conclusion</h2>
Octopus Deploy is a powerful deployment tool that can handle many complex and scaled scenarios. If you need additional help, <a href="https://octopus.com/support">contact Octopus Support</a>.]]></content>
</entry>
<entry>
<title>Your IDP needs DDD</title>
<link href="https://octopus.com/blog/your-idp-needs-ddd" />
<id>https://octopus.com/blog/your-idp-needs-ddd</id>
<published>2025-09-09T00:00:00.000Z</published>
<updated>2025-09-09T00:00:00.000Z</updated>
<summary>As Platform Engineering grows into a movement at scale, we need to revisit the past and apply some lessons from domain-driven design to our internal developer platforms (IDPs).</summary>
<author>
<name>Steve Fenton, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[It has been more than two decades since Eric Evans published his book on domain-driven design (DDD). The idea was to create software designed after the business domain, using the same language and mental models people used outside of the software team.
We don’t talk about domain-driven design much these days. But as George Santayana said: “Those who cannot remember the past are condemned to repeat it.”
As Platform Engineering grows into a movement at scale, we need to revisit the past and apply some lessons from domain-driven design to our internal developer platforms (IDPs). Otherwise, we continually step on rakes to learn why they shouldn’t be left on the lawn.
There’s a host of interesting interconnected ideas in domain-driven design, but one that resonates with Platform Engineering is the concept of a core domain.
<h2 id="what-core-domains-are">What core domains are</h2>
When you build software, there are several areas where your innovation, opinions, and solutions create unique value for your organization. You also need many things that don’t add much value, but your software isn’t viable without them.
Let’s use a pizza restaurant as an example. If you sell pizza, you want to make it easy for customers to choose what they want to eat and have it delivered. To complete the process, you need to look up their address and take a payment.
Core domains are the areas where you want to do something different that will give you a competitive edge. For your pizza company, that might be how you present the menu, collect customizations, and offer deals and rewards.
Non-core domains, also called generic domains, are areas where innovation and differentiation make little difference, or where doing things differently may even be undesirable. Customers expect that looking up their address and paying will work like elsewhere. They don’t want you to be innovative here, as it makes it harder to use.
So, core domains are something unique or special to your organization. It’s essential to your business’s existence, and where you should invest the most. This is something you want to do so well that it’s hard for your competitors to copy.
<h2 id="the-problem-of-generic-domains">The problem of generic domains</h2>
When you spend time on generic domains, you direct time, attention, energy, and investment away from the areas that impact your organization most. Generic domains have limited value because they don’t benefit from doing something different or unique. The pizza company will never create such an excellent payment flow that you’d choose their offering over a competitor who offers better customization.
Generic domains can be just as complex as your core domains, which means they can consume large amounts of investment. Suppose there’s a commercial provider of an offering in your generic domain space. In that case, they’ll be treating it as a core domain and innovating the space, which puts additional pressure on you to invest to avoid falling behind user expectations.
Organizations that avoid the generic domain trap can outpace their competitors as they spend more time working on features that will make them stand out.
<h2 id="how-to-tame-generic-domains">How to tame generic domains</h2>
There’s an easy way to avoid the generic domain trap. Domain-driven design provides a pattern for managing them, which recognizes the asymmetry in the value gained by investment in core domains versus generic domains.
Instead of reducing costs on paper, the goal is to minimize the real cost of working on generic domains: Lost value.
<figure><img src="/blog/img/your-idp-needs-ddd/taming-generic-domains.png" alt="Domain-driven design prefers to buy off the shelf, then falls back to isolation, outsourcing, and minimalism"></figure>
You should work through this list from the top and choose the earliest exit available.
<ol>
<li>Off-the-shelf: Look for existing software or services that address the generic domain. In particular, look to use:
<ol>
<li>Commercial products and software-as-a-service offerings where the provider treats it as a core domain. Their innovation and support will ensure the generic domain doesn’t become an anchor dragging you back.</li>
<li>Open source tools that are robust and maintained, and where the overheads of adopting and updating them are low.</li>
</ol>
</li>
<li>Isolation: Where you have to build custom code for a generic domain, encapsulate and isolate it. Placing it behind a well-defined interface minimizes the impact on your core domain and lets you switch it out if an off-the-shelf solution emerges later.</li>
<li>Outsourcing: While outsourcing your core domain can cause problems, outsourcing generic domains helps control the cost and distraction of the work. You can define the interface and have an outsourced team focus on the implementation details.</li>
<li>Minimalism: When no other option is available, create a simple minimalist solution that meets the immediate need. Don’t over-engineer the generic domain or add features you don’t need. You can be reluctant to iterate the solution and keep your eyes and ears open for when someone creates a software product or service you can use to replace it.</li>
</ol>
<h2 id="analyzing-build-versus-buy">Analyzing build versus buy</h2>
Platform Teams who want to create the most significant force multiplier for the developers they serve need to protect their focus on fitting the tools to the organization. To do that, they need to identify and eliminate areas where their skills are wasted.
A crucial part of this optimization process is performing a solid build versus buy analysis, which should factor in the initial development cost, ongoing maintenance and support costs, and the opportunity cost of diverting resources away from the core domains.
Returning to the pizza restaurant, offloading the address lookup to a vendor that commonly provides this feature will mean users are familiar with how it works. The vendor will dedicate more attention to improving the user experience of their tool, and when the vendor introduces innovations, they appear commonly enough that users accept them.
Similarly, you’d want to offload payments to a fast and secure payment provider. Hence, it works like other sites and keeps pace with developments like 3D secure, tokenization, card security codes, multi-factor authorization, and biometrics. These industry innovations would have forced the developers to revisit this generic domain many times just to keep pace with the baseline.
<h2 id="why-this-is-crucial-for-platform-engineering">Why this is crucial for Platform Engineering</h2>
Domain-driven design (DDD) tells us to optimize our development efforts where they will have the most impact on the organization’s success. You shouldn’t over-invest in non-core domains, as they have limited business value and drain resources. Building custom solutions for non-core domains brings unnecessary complexity and maintenance burden, and for what? To build something that you could have bought or outsourced.
The software industry is about to re-learn the lessons that led to the discovery of domain-driven design. Industry-wide, we are dedicating thousands of developers to building the same thing. Not a simple minimalist solution to fill a gap left by commercial products, software-as-a-service, or open source software, but a million giant platforms that are out of date before they’ve been pushed to production.
Internal developer platforms sink unless platform teams can shift weight down to underlying tools. By transferring ballast to commercial products or open source tools, the platform team can get back to agility and create simple, minimal solutions that handle real gaps in toolchains caused by truly bespoke needs.
And it’s these very needs that are missed with behemoth platforms. An organization that needed to go an extra two miles on security may adopt Platform Engineering to tailor a truly robust solution to their security needs. As that platform grows and accumulates additional custom features, the focus on security is lost, and the investment is wasted building and maintaining code that doesn’t solve a unique need for the organization.
But it’s not all doom and gloom for Platform Engineers. Commercial and open source tools can rescue them from this inevitability by providing features that make it easy to shift the weight down and keep the platform light enough to float.
<h2 id="float-on-our-platform-hub">Float on our Platform Hub</h2>
That’s where Platform Hub comes in. By adding features platform teams need, like process templates, project templates, and policies, platform teams can transfer the effort down to Octopus and lighten their platform by removing thousands of lines of bespoke templating code.
Platform Teams can get back to focusing on the unique needs that make their platform vital to their organization. They will benefit from our innovative mechanisms for template management and policies, which go well beyond the attack of the template clones and the synchronization conflicts that platform teams report with their bespoke solutions.
Happy deployments!]]></content>
</entry>
<entry>
<title>Focus on your end users when creating AI workloads</title>
<link href="https://octopus.com/blog/focus-on-end-users-for-ai" />
<id>https://octopus.com/blog/focus-on-end-users-for-ai</id>
<published>2025-09-04T00:00:00.000Z</published>
<updated>2025-09-04T00:00:00.000Z</updated>
<summary>Why it is important to focus on helping end users above all else when creating AI workloads.</summary>
<author>
<name>Bob Walker, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Recently, I attended a conference targeted at CIOs, CTOs, and VPs of Technology. As expected, there were many sessions on AI and how it can help companies be more efficient. The example given was the well-known use of AI in the hiring process; using AI as gatekeepers to quickly weed out all the unqualified candidates. “Your human resources people won’t have to wade through so many CVs and phone screens!”
That use case improves the efficiency of human resources or your people team. But that efficiency comes at the cost of the end users, the people you are trying to hire. Everyone hates how AI is used in hiring processes today. Phrases like dystopian and Orwellian are common. In this article, I’ll discuss why focusing on both your AI feature’s beneficiary and end users is essential.
<h2 id="beneficiary-user-vs-end-user">Beneficiary User vs. End User</h2>
A beneficiary user is a person who benefits from leveraging AI. The end user is the person who will use an AI feature to accomplish a specific task.
Returning to the hiring process, the beneficiary user is responsible for wading through CVs and performing the initial phone screen. The end user is the person submitting their CV. The person in charge of going through CVs benefits from AI by offloading the repetitive work of screening unqualified candidates. Imagine a job posting for a senior .NET developer, but 30% of CVs submitted only include project manager experience. You might think I’m exaggerating, but you’d be surprised. As a former hiring manager who had to wade through CVs, I was shocked by how many people were “CV Bombing” - applying for as many positions as possible.
Looking at Octopus Deploy, the beneficiary of our AI Assistant is the platform engineer. The end user is the developer who uses the assistant to accomplish a particular task. For example, you can ask the Octopus AI Assistant why a deployment or runbook run failed. The AI Assistant will look at the failure message, and using our knowledge base, our docs, and the web, will come up with a reason why the failure occurred and suggestions on how to fix it. Assuming the suggestion is correct, the developer can quickly self-serve a solution without involving the platform engineer. The platform engineer benefits because they can focus on high-value tasks instead of helping debug a specific deployment failure. If the platform engineer didn’t know the answer, they’d go through our docs or do a Google search.
Now that we understand the two kinds of users, let’s examine what happens when a person is both the beneficiary and the end user.
<h2 id="learning-the-wrong-lessons-from-the-success-of-chatgpt">Learning the wrong lessons from the success of ChatGPT</h2>
ChatGPT and similar tools are unique because their users are both the beneficiary and the end user.
One of many benefits of ChatGPT is that it is an evolution of search engines. Before ChatGPT, you did a Google search, which returned a list of results. The search engine ranked the results for you. They had complex algorithms to find the best results based on their internal ranking system. A cottage SEO industry (Search Engine Optimization) sprang up to get higher results. ChatGPT changed that by providing you with answers curated from the content of many websites.
For common questions, with many sources agreeing on the same answer, the results between Google and ChatGPT are close. ChatGPT is not infallible; once, it insisted that Omaha, Nebraska, was 29 nautical miles from Chicago, Illinois. Google can be more accurate, but that is a result of maturity. They’ve had 25 years to improve and iterate their search results algorithm.
ChatGPT is popular because of the interface. It is very similar to the Google Search box. The results are where they differ. ChatGPT collates information and generates an answer that is easy to read. In addition, Google Searches are very transactional: search, get a result, move on with your day. With ChatGPT, the sessions are interactive. You can ask additional questions, and ChatGPT remembers the entire conversation.
I’m only focused on ChatGPT’s question/answer aspect. I know it can do so much more, including generating content, images, composing songs, and more.
Unfortunately, companies seem insistent on learning the wrong lessons when analyzing popular trends. They see that “people like prompts and providing answers or content to them. Let’s do that for [insert use case here]!”
<h2 id="an-awful-user-experience-and-its-impact">An awful user experience and its impact</h2>
That wrong lesson has its roots in computer graphic adventure games from the 1980s/early 1990s.
My first computer game was <a href="https://en.wikipedia.org/wiki/Space_Quest_III">Space Quest III</a> from Sierra. Like computer games of that era, I typed in commands to get the on-screen character to act. There was no help guide or tutorial. I had to figure it out. My brother and I spent weeks trying to escape the first area. We had to find the magic set of commands to execute in a specific sequence in specific areas.
Last year, I started the multi-month process of changing banks from a regional to a national bank. The national bank offered a high-yield savings account, while the regional bank didn’t. I had to call the national bank a few times. They have followed the latest trend in phone support. Dial the number, and a human-sounding voice asks you what you need help with. Too often, the response is “I’m sorry, I didn’t get that” or “I didn’t understand.” I needed to know the magic phrase to get help. There was no clear escape hatch to get to an operator.
Their online AI help agent was no better. The AI help agent was trained on their public documents. If the answer wasn’t in the documents, it couldn’t help me. Often, it referred me to calling their support line, creating an endless cycle of frustration.
That experience was so bad that I went back to the regional bank. They proudly promote that you’ll talk to a real person when calling for help. I would rather lose thousands of dollars over many years than deal with the national bank’s awful AI-based help system.
I’m not the only one who hates talking to AI chatbots for support. The Commonwealth Bank of Australia (CBA) <a href="https://www.abc.net.au/news/2025-08-21/cba-backtracks-on-ai-job-cuts-as-chatbot-lifts-call-volumes/105679492">recently reversed its decision</a> to eliminate jobs after introducing an AI-powered help due to poor customer experience.
<h2 id="augmenting-the-end-user-experience">Augmenting the end user experience</h2>
The problem is that, just like humans, AI makes mistakes. Without appropriate settings, it will insist that it is correct. Where humans and AI differ is that AI is “book smart” but not “street smart,” but people can be “book smart” and “street smart.” That means that humans use a combination of experiences and acquired knowledge to make decisions. Humans learn and evolve. At the same time, AI needs to be retrained. The best analogy came from Neil deGrasse Tyson on a <a href="https://www.youtube.com/watch?v=BYizgB2FcAQ">recent interview with Hasan Minhaj</a> - think of AI like Albert Einstein, but he is locked in a box. It is a sensory deprivation tank, where he does not know the outside world. Someone asks him random questions, and he responds with his current knowledge. He has no context outside the knowledge he has acquired before going into the box.
As a result, AI struggles with complex decisions. It doesn’t do well when something is outside the expected parameters. In a recent study from <a href="https://arxiv.org/pdf/2412.14161">Carnegie Mellon University and Duke University</a>, AI Agents are correct 30 to 35 percent for multi-step tasks. And the results depended on the model used, with GPT-4o achieving an 8.6% success rate. In a <a href="https://ml-site.cdn-apple.com/papers/the-illusion-of-thinking.pdf">recent study</a> by Apple Computers, many popular LRMs (Large Reasoning Models) models couldn’t handle puzzles (Tower of Hanoi, Checker Jumping, Block World, and River Crossing) once the number of pieces increased beyond simple examples. Today’s AI still has to undergo many more evolutions to become similar to <a href="https://en.wikipedia.org/wiki/J.A.R.V.I.S.">Tony Stark’s Jarvis</a> in the <abbr title="Marvel Cinematic Universe">MCU</abbr>.
I’m not against using AI. Far from it. However, it’s essential to understand its limitations when designing an end-user experience.
We’ve been very methodical in finding the proper use cases for our AI Assistant. We looked at how AI could augment the user experience. That means the Octopus AI Assistant is not intended to replace the current end-user interface. That would result in a sub-par experience, the opposite of augmentation.
The challenge we wanted to solve was surfacing the correct information for the users at the right time. We wanted to let the user ask AI for help and not annoy them with unwanted pop-ups or suggestions. We didn’t want to create Clippy 2.0 in the product.
Knowing that, our four use cases for the AI Assistant are:
<ol>
<li>Deployment Failure Analyzer: Read the logs of a failed deployment and offer suggestions to fix the issue.</li>
<li>Tier-0 Support: Provide answers to end-users for common Octopus-related questions. For example, “summarize this deployment process” or “what’s a project?”</li>
<li>Best Practices Analyzer: Using Octopus Deploy’s strong opinions, review the user’s instance to find areas for improvement.</li>
<li>Prompt-Based Project Creation: Using templates provided by Octopus Deploy, create a new project to deploy to specific deployment targets.</li>
</ol>
Interestingly, you don’t need AI to list the first three items. I can take a deployment failure, do a Google search, and likely produce similar results. Or, I can use our Octopus Linting tool, <a href="https://octopus.com/blog/octolint-best-practices">Octolint</a>, for best practices. AI is short-cutting all of that by collating all that information and surfacing it to the user. It’s enabling self-service for the end user.
But just as necessary, if the AI assistant can’t help, users can still ask their DevOps or Platform Engineers for help.
That is very different from using AI in hiring or AI-based help agents. They are replacement end-user interfaces. They don’t augment the user experience. Instead, they act as pseudo-gatekeepers to the hiring managers and provide support. They only focus on reducing the load for the beneficiary users. Most likely as a way for companies to cut costs or keep demand for additional headcount down. Unless you know someone at the hiring company or the magic phrase for AI Agent-based help, there are no alternatives.
But end users hate that experience. I believe that is one of the main reasons why <a href="https://www.ibm.com/thought-leadership/institute-business-value/en-us/c-suite-study/ceo">IBM found</a> that only 25% of AI initiatives have delivered the expected ROI over the past few years.
<h2 id="considerations-for-the-end-user-experience">Considerations for the end user experience</h2>
When designing the <a href="https://octopus.com/use-case/ai-assistant">Octopus AI assistant</a>, we started with multiple questions about augmenting the end-user experience. We didn’t want to “sprinkle AI” into the product and claim we had an AI strategy.
<ol>
<li>What problem is the AI feature attempting to solve for the end user?</li>
<li>What is the fallback when the AI feature encounters an unknown use case?</li>
<li>What is an acceptable level of accuracy for the AI feature?</li>
<li>If the response is wrong, what is the escalation process for the end user?</li>
<li>How will the functionality be discovered?</li>
</ol>
The answers for the deployment failure functionality of the AI Assistant are:
<ol>
<li>Often, failures result from an incorrect configuration, transient error, bug in the script, permissions, or some other common problem. In many cases, it is outside the direct control of Octopus. Surface the information to the user to enable them to self-service the fix and decrease the recovery time.</li>
<li>Provide a generic answer and encourage the user to contact Octopus Support or their internal experts.</li>
<li>Reasonable accuracy is expected. Various conditions outside the control of Octopus Deploy can cause errors. Provide multiple suggestions using publicly available documentation. If none work, encourage the user to escalate to a human.</li>
<li>If the response doesn’t help, provide a link to Octopus Support or to contact their internal experts. In either case, they will escalate to a human.</li>
<li>When navigating to a failed deployment or runbook run, the Octopus AI Assistant will provide a suggestion that the user can click on to get the answer.</li>
</ol>
The focus has been “How can we take what we have and make it better?”, not ” How can we ensure that Platform or DevOps engineers are never bothered again?”
<h2 id="conclusion">Conclusion</h2>
When an AI feature has a beneficiary user and end user, focus on providing a fantastic experience for the end user. Augment the end-user experience. But assume that at some point the AI will be incorrect (just like a person is incorrect), and offer a clear escalation path. Despite the many advances in AI, experienced people can handle complex scenarios much better. When the end-user isn’t considered, and the only focus is “improving the bottom line,” it creates an inferior replacement for an existing experience. End users will only put up with so much before they decide to change.]]></content>
</entry>
<entry>
<title>How organizations measure Platform Engineering</title>
<link href="https://octopus.com/blog/how-organizations-measure-platform-engineering" />
<id>https://octopus.com/blog/how-organizations-measure-platform-engineering</id>
<published>2025-09-02T00:00:00.000Z</published>
<updated>2025-09-02T00:00:00.000Z</updated>
<summary>One of the areas we explored in the Platform Engineering Pulse report was how organizations measure their internal developer platforms, with results that varied from technical measures to not collecting any metrics at all.</summary>
<author>
<name>Steve Fenton, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[Our Platform Engineering Pulse report is coming soon, containing insights, strategies, and real-world data on how organizations adopt and succeed with Platform Engineering. We’ll also launch a survey to deepen our understanding of the patterns, challenges, and future direction of successful platform building.
One of the areas we explored in the <a href="https://octopus.com/publications/platform-engineering-pulse">Platform Engineering Pulse report</a> was how organizations measure their internal developer platforms, with results that varied from technical measures to not collecting any metrics at all.
This post looks at which metrics were popular and how you can use them to structure your measurement approach to avoid the zero-metric illusion.
<h2 id="measurement-is-essential">Measurement is essential</h2>
At the start of a <a href="https://octopus.com/devops/platform-engineering/">Platform Engineering</a> initiative, the immediate problems take precedence, and measurement becomes an afterthought. This leaves platform teams without a pre-platform baseline, which makes it challenging to demonstrate the platform’s impact.
The lack of measurement also increases the risk of platforms adding features that don’t align with the organization’s core motivations. For instance, a platform team might focus on standardization, only to discover that the primary driver for investing in Platform Engineering was to improve developer experience.
Platforms often fail not because they are inherently bad, but because they target the wrong personas and attempt to solve the wrong problems.
Even successful platforms struggle with ongoing justification and optimization when they lack clear goals, a robust measurement system that reflects those goals, and baseline data. The platform team may find leadership challenges continued investment if they can’t show the platform’s value.
Therefore, it is crucial to measure platform performance against its established goals. But how are organizations currently approaching this?
<h2 id="what-organizations-measure">What organizations measure</h2>
The survey found organizations focused on 3 key areas for measurement: Software delivery, operational performance, and user experience. The variety of metrics likely reflects the variety of contexts that platforms can assist, though is also evidence that metric systems are skewed to <a href="https://octopus.com/blog/productivity-delusion">the elusive productivity problem</a> rather than true developer experience and engagement.
<h3 id="software-delivery-metrics">Software delivery metrics</h3>
The software delivery metrics assess the speed, quality, and throughput of development teams using the platform. They often align with DORA measurements, highlighting how platforms are seen as a route to shipping software more often and at higher quality. The metrics encompass throughput (e.g., deployment frequency, build time, features delivered) and stability (e.g., change failure rate, build success rate).
<ul>
<li>Deployment frequency</li>
<li>Deployment times</li>
<li>Change failure rate</li>
<li>Recovery time</li>
<li>Build success rate</li>
<li>Build time</li>
<li>Features delivered</li>
</ul>
While valuable for understanding delivery performance, these metrics primarily reflect downstream outcomes rather than the platform’s direct contribution to developer productivity. They are most effective when measured before and after platform adoption to demonstrate improvement.
<h3 id="operational-performance-metrics">Operational performance metrics</h3>
Metrics for operational performance track the cost, performance, and efficiency of applications that use the platform. They combine traditional infrastructure monitoring (e.g., reliability, error rates, system performance) with resource optimization (e.g., usage efficiency, cost management). Project count is a basic adoption indicator, but it lacks the context of the addressable market size.
<ul>
<li>Reliability</li>
<li>Error rates</li>
<li>System performance</li>
<li>Resource usage</li>
<li>Infrastructure cost</li>
<li>Project count</li>
</ul>
These metrics are crucial for demonstrating that the platform is operationally sound and cost-effective, but they don’t necessarily indicate developer value or ease of use.
<h3 id="user-experience-metrics">User experience metrics</h3>
These metrics directly measure how developers and teams perceive and interact with the platform, treating internal developers as customers. They focus on satisfaction and onboarding journeys. <a href="https://octopus.com/devops/metrics/platform-satisfaction/">Net promoter score (NPS)</a> offers benchmarkable sentiment data, while user satisfaction provides broader feedback. Onboarding time is critical as it represents the first impression and adoption barrier.
<ul>
<li>User satisfaction</li>
<li>Net promoter score (NPS)</li>
<li>Onboarding time</li>
</ul>
These metrics are vital for platforms run as products with optional adoption, indicating whether the platform is compelling enough for developers to choose and continue using voluntarily.
<figure><img src="/blog/img/how-organizations-measure-platform-engineering/success-metrics.png" alt="Popular metrics include deployment frequency, reliability, build success rate, deployment times, and user satisfaction"></figure>
Most organizations prioritize technical and delivery metrics, with fewer focusing on user experience or business outcomes. This suggests a risk that platform teams are measuring what’s easy to collect rather than what truly demonstrates business value. The heavy emphasis on technical metrics indicates that many organizations still measure platforms like infrastructure rather than products serving internal customers.
<h2 id="how-measurement-improves-platform-performance">How measurement improves platform performance</h2>
For metrics to improve platform performance, you need to measure multiple dimensions, not just one. Internal developer platforms offer many benefits, so the measurement system should cover all platform goals.
We found organizations that measure more dimensions were more likely to be successful. A single metric gives you a one-in-three chance of creating a successful platform, while 2 metrics make it 50/50. Organizations measuring 6 or more metrics were most likely to be successful.
Platform sponsors may expect you to deliver technical reliability, boost developer productivity, offer a positive user experience, manage costs, encourage adoption, and align with business objectives. Relying on just a handful of metrics cannot adequately capture the interplay of all these dimensions.
<figure><img src="/blog/img/how-organizations-measure-platform-engineering/success-by-metric-count.png" alt="With a single metric, only a third of platforms achieve their goals, but platforms with 6 or more metrics have a 75% success rate"></figure>
<h2 id="breaking-the-success-illusion">Breaking the success illusion</h2>
The data shows a zero-metric high-success effect. This occurs when organizations that don’t collect any concrete measures of the Platform Engineering effort report high success rates. This phenomenon comes from two very different situations masquerading as the same outcome.
There may be easy and obvious success criteria the platform can address, such as a critical and evident problem where success is undeniable without formal measurement. Where the effectiveness is apparent, formal measurements may be unnecessary. A more likely explanation is that there’s an illusion of success caused by a lack of measurement.
Without concrete metrics, platform teams can focus on outputs (e.g., features built, no outages) rather than actual outcomes (e.g., increased developer productivity, achievement of business goals). Stakeholders may mistake activity for impact, especially if the team is busy and there are no apparent failures.
This also helps explain the dramatic increase in success rates observed when moving from one metric to three or more. Teams relying on a single metric might choose one that doesn’t capture holistic success, leading to a false sense of achievement. However, when multiple dimensions are measured, maintaining illusions becomes difficult. For instance, you can’t claim unqualified success if deployment frequency is high but Net Promoter Score (NPS) is low.
The data also suggests a dangerous middle ground where minimal measurement can create more problems than no measurement. It provides false confidence without the comprehensive feedback necessary for genuine improvement.
<figure><img src="/blog/img/how-organizations-measure-platform-engineering/success-illusion.png" alt="When organizations don't measure their Platform Engineering initiative, they operate under the illusion of success"></figure>
<h2 id="using-monk-metrics">Using MONK metrics</h2>
<a href="https://octopus.com/devops/metrics/monk-metrics/">MONK metrics</a> offer a balanced approach to measuring Platform Engineering success, combining external validation and internal alignment. This framework is more adaptable than purely technical metrics, yet still provides a standardized basis for comparison and improvement.
The MONK metrics are:
<ul>
<li>Market share</li>
<li>Onboarding times</li>
<li>Net Promoter Score (NPS)</li>
<li>Key customer metrics</li>
</ul>
The first three, market share, onboarding times, and NPS, form a benchmarkable trio. These metrics allow for comparison against industry standards and are broadly applicable to Platform Engineering initiatives, serving as a starting point to understand high performance in other organizations. For example, if your onboarding times are slower than those of your industry peers, you can investigate their methods and implement similar improvements.
Including “key customer metrics” is crucial for preventing the measurement framework from losing touch with business realities. Organizations kick off Platform Engineering to solve specific organizational problems, but their success is measured using generic technical metrics that don’t reflect the original investment’s purpose. Instead, it’s essential to translate the motivations behind adopting Platform Engineering into the key customer metrics to track progress towards the platform’s objectives effectively.
MONK metrics address the common issue of platform teams optimizing for metrics that appear favorable but don’t contribute to actual business value. For instance, if you introduce Platform Engineering to reduce time-to-market, measures of infrastructure uptime or build failures fail to track tangible improvements in delivery flow.
<h2 id="lack-of-measurement-makes-your-platform-vulnerable">Lack of measurement makes your platform vulnerable</h2>
Without measurement, platform teams end up in a vulnerable position. They can’t demonstrate their value when budget discussions come up, they can’t identify what’s working versus what needs improvement, and they can’t make compelling cases for continued investment or expansion.
The absence of data also hinders course correction. Platform Engineering involves complex trade-offs between developer experience, operational efficiency, security, and cost. Without clear metrics, teams may prioritize visible or politically expedient solutions over those that deliver actual value.
MONK metrics offer a practical solution. They are accessible, enabling organizations to begin measuring with minimal tooling or data infrastructure. You can gather basic market share data through surveys, track onboarding times simply, and get NPS using lightweight feedback tools.
Their benchmarkable nature also helps address the common “what’s good enough?” dilemma. Instead of abstractly debating whether a two-day onboarding time is acceptable, teams can compare their performance to similar organizations.
Happy deployments!]]></content>
</entry>
<entry>
<title>Platform Engineering and woodworking</title>
<link href="https://octopus.com/blog/platform-engineering-and-woodworking" />
<id>https://octopus.com/blog/platform-engineering-and-woodworking</id>
<published>2025-08-26T00:00:00.000Z</published>
<updated>2025-08-26T00:00:00.000Z</updated>
<summary>What is something that woodworkers, blacksmiths, and programmers have in common? One answer is that practitioners of these crafts have the unique ability to make their own tools.</summary>
<author>
<name>Paul Stovell, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[What is something that woodworkers, blacksmiths, and programmers have in common? One answer is that practitioners of these crafts have the unique ability to make their own tools.
In fact, making your own tools is so essential to these crafts that tool-making is part of their training and tradition. Hammers, tongs, and chisels are among the first items an apprentice blacksmith learns to make. The first projects for an amateur woodworker are often to build a workbench, a circular saw guide, sawhorses, or a cross-cut sled. Tool-making is so essential to these crafts that it’s not uncommon to detour midway through a production project into making a tool to assist with the project, a detour that becomes a natural part of the work process.
Programmers are, perhaps, the ultimate tool-makers. Every programmer has a collection of scripts and utility programs they’ve built to make small tasks more productive. Octopus Deploy started life as a collection of automation scripts I would take from project to project in my consulting days. Tool-making isn’t just a way to gain productivity; it’s also immensely satisfying. It gives us extensive control over our work environment: unlike every other profession, we don’t need to put up with bad tools, because we can always make our own.
<h2 id="when-making-the-tool-consumes-the-project">When making the tool consumes the project</h2>
Tool-making is never free, however. In woodworking or blacksmithing, it consumes raw materials and time. For programmers, we don’t have a raw material constraint (except perhaps coffee, the raw material that programmers turn into working code!), but we do have a time constraint. And the complexity of software and the optimistic nature of programmers mean that we often underestimate how difficult a particular tool can be to make.
For example, a programmer may need to complete a task that takes 5 minutes, like resetting the local test data they use in the application they are working on. And they might perform that task 5 or 6 times a month. So it’s quite common for good programmers to take an hour or so to create a script or a small utility program to automate the task. Even if the ROI calculation means the time they save automating isn’t going to be paid back for a long time, it can still be a smart thing to do if it results in less context switching, better accuracy, or is simply more satisfying.
As organizations scale their Continuous Delivery practices, this craft approach can lead to an unexpected problem: the tool-building starts consuming more resources than the actual work. Teams that began by automating a few deployment scenarios find themselves spending months building elaborate internal platforms to handle every edge case across dozens of applications. A deployment pipeline that started as a simple script to push a web application to production grows into a complex system supporting microservices, legacy mainframes, mobile apps, and that one critical application written in a programming language nobody wants to touch.
The irony is striking. The organization wants to create valuable software for its customers, but engineering teams are spending more and more time maintaining their custom-built tooling instead of creating features. Like a woodworker who spends more time perfecting their jigs than crafting furniture, these teams have lost sight of what they’re really trying to accomplish.
<h2 id="platform-engineering-and-developer-experience">Platform Engineering and developer experience</h2>
Platform Engineering is downstream of developer experience, even when it’s not the primary motivation for building an internal developer platform. Removing barriers to let developers improve the flow of value benefits the whole organization. Getting software into production and running that software in production is hard, and it wastes time for each team to reinvent solutions to this from first principles.
The best platform teams never lose sight of that developer experience. They build thin platforms that let the innovation of underlying tools accelerate their pace, so their platform can remain market-leading over the long term and at a lower cost than chasing that innovation with a custom-built platform. We often refer to internal developer platforms as the glue. What if we changed that to think of these platforms as the minimal jig that helps fit the professional-grade saws and drills to the shape the organization needs?
The platform, like the jig, should never become the build. When it does, it gets in the way and slows developers down instead of being their force multiplier.
<h2 id="platform-hub-shifting-complexity-away-from-platform-engineers">Platform Hub: Shifting complexity away from Platform Engineers</h2>
We built Platform Hub to lighten the load for platform builders. When they need to support Continuous Delivery at scale, Platform Hub tackles the complexity of template management and policy guardrails. The traditional approach is to create a template and clone it across all your applications, then face the nightmare of keeping hundreds of copies in sync as requirements evolve.
Platform Hub solves the cloning problem by keeping a single versioned template connected to all the places you use it. You can roll out non-breaking changes automatically and track the progress of significant updates. You can even require crucial steps like security scanning using policies, so you know all your deployments meet your standards.
By handling this complexity below the platform level, your teams can focus on what matters: shaping the tools to fit your organization’s specific needs while letting professional-grade tooling handle the heavy lifting. Less time building jigs; more time creating value.
Happy deployments!]]></content>
</entry>
<entry>
<title>Migrating Octopus projects to Terraform with Octoterra</title>
<link href="https://octopus.com/blog/importing-terraform-projects" />
<id>https://octopus.com/blog/importing-terraform-projects</id>
<published>2025-08-25T00:00:00.000Z</published>
<updated>2025-08-25T00:00:00.000Z</updated>
<summary>Learn how to bring existing Octopus projects under Terraform management with Octoterra.</summary>
<author>
<name>Matthew Casperson, Octopus Deploy</name>
</author>
<content type="html"><![CDATA[With the release of <a href="https://registry.terraform.io/providers/OctopusDeploy/octopusdeploy/latest/docs">version 1 of the Octopus Terraform Provider</a>, DevOps teams can now manage their Octopus resources using a fully supported Terraform based Infrastructure as Code (IaC) solution.
New teams populating their first Octopus spaces can take advantage of the Terraform provider from the outset. However, it is arguably established teams with existing Octopus projects that will benefit the most from IaC capabilities. But how do you migrate existing Octopus projects to Terraform?
In this post we will cover how the Octoterra tool can bring existing projects under Terraform management.
<h2 id="what-is-octoterra">What is Octoterra?</h2>
<a href="https://github.com/OctopusSolutionsEngineering/OctopusTerraformExport">Octoterra</a> is a CLI tool that scans an existing Octopus space and converts the projects, runbooks, and other resources into Terraform configuration files.
A new feature in Octoterra generates Bash and PowerShell scripts to reimport the existing resources into the state file of the exported Terraform configuration. This allows teams to:
<ol>
<li>Export existing Octopus resources into Terraform configuration files.</li>
<li>Import the configuration of existing resources into the Terraform state file associated with the exported configuration.</li>
<li>Manage the existing resources using Terraform going forward.</li>
</ol>
<h2 id="exporting-an-existing-octopus-project">Exporting an existing Octopus project</h2>
Octoterra is distributed as self-contained binaries for Windows, Linux, and macOS, available from the <a href="https://github.com/OctopusSolutionsEngineering/OctopusTerraformExport/releases">GitHub releases page</a>.
You can also run Octoterra as a Docker container, which is often the simplest way to get started. The following command will run Octoterra in a Docker container, exporting the configuration of an existing Octopus project into the current directory:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>docker run -v $PWD:/tmp/octoexport --rm ghcr.io/octopussolutionsengineering/octoterra \
-url https://instance.octopus.app \
-space Spaces-## \
-apiKey API-xxxx \
-projectName "My Project" \
-lookupProjectDependencies \
-generateImportScripts \
-dest /tmp/octoexport</code></pre>
The Octoterra arguments from this example are:
<ul>
<li><code>-url</code>: The URL of the Octopus server.</li>
<li><code>-space</code>: The ID of the Octopus space containing the project.</li>
<li><code>-apiKey</code>: The API key to authenticate with the Octopus server.</li>
<li><code>-projectName</code>: The name of the project to export.</li>
<li><code>-lookupProjectDependencies</code>: Enables the use of data sources to look up the IDs of space-level resources such as environments, lifecycles, and variables. This exports the project as a self-contained Terraform configuration referencing existing space-level resources by name.</li>
<li><code>-generateImportScripts</code>: Generates Bash and PowerShell scripts to locate and import the existing resources into the Terraform state file.</li>
<li><code>-dest</code>: The destination directory to write the exported Terraform configuration files and import scripts. When using a Docker container, this directory must be mounted as a volume to allow the container to write files to the host filesystem.</li>
</ul>
For this post we’ll export a simple project called “My Project” that has a single deployment step running a PowerShell script and a channel called HotFix. The project also has a variable scoped to an environment and a channel.
<img src="/blog/_astro/process-steps.ty0Y7JtZ_1z4GNq.webp" alt="Octopus deployment project steps screenshot" loading="lazy" decoding="async" fetchpriority="auto" width="3840" height="2150">
<img src="/blog/_astro/project-variables.BZYnDYfU_iqGM7.webp" alt="Octopus project variables screenshot" loading="lazy" decoding="async" fetchpriority="auto" width="3840" height="2150">
Once the Terraform configuration files have been generated, run the following command in the <code>space_population</code> directory to initialize the directory containing the exported Terraform configuration files:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>terraform init</code></pre>
Because we have supplied the <code>-generateImportScripts</code> argument, Octoterra will generate Bash and PowerShell scripts to reimport the project into the Terraform state file. All the script file names start with the prefix <code>import_</code>. In addition, two scripts called <code>import.sh</code> and <code>import.ps1</code> are generated which run all the other import scripts, providing a convenient way to import all the resources in the exported configuration.
If running on Linux or macOS, the scripts must be made executable before they can be run:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>chmod +x *.sh</code></pre>
The import scripts can then be run to import the existing resources into the Terraform state file. The following command runs the Bash script to import the existing resources:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>./import.sh API-xxx https://instance.octopus.app Spaces-##</code></pre>
If running on Windows, the PowerShell script can be run using the following command:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="powershell"><code>.\import.ps1 API-xxx https://instance.octopus.app Spaces-##</code></pre>
You may need to allow PowerShell to run unsigned scripts by setting the <a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.5">execution policy</a>.
The import scripts first attempt to find the matching resources in the target space by name, and if found, import the resources into the Terraform state file using the <code>terraform import</code> command.
<div class="hint">In this example we have used the default local state. Production environments should use <a href="https://developer.hashicorp.com/terraform/language/state/remote">remote state</a>, such as an S3 bucket or Azure Storage Account, to ensure the Terraform state is stored securely and can be accessed by all team members.</div>
<h2 id="checking-the-terraform-state">Checking the Terraform state</h2>
Once the project is imported, you can run <code>terraform plan</code> to see any differences between the generated Terraform configuration files and the imported state:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>terraform plan \
 -var=octopus_apikey=API-xxxxx \
 -var=octopus_server=https://instance.octopus.app \
 -var=octopus_space_id=Spaces-###</code></pre>
There are <a href="https://github.com/OctopusDeploy/terraform-provider-octopusdeploy/issues">open issues in the Terraform provider</a> at the time of writing that lead to the plan showing differences between the generated configuration and the imported state. For example, the <code>octopusdeploy_variable</code> resources may show fields like <code>is_editable</code>, <code>is_sensitive</code>, and <code>value</code> will be added, again when these are no-op changes.
Future releases of the Terraform provider and Octoterra will resolve these import differences, but for now, it is expected that the plan will show some differences between the generated configuration and the imported state.
That said, the primary purpose of the import scripts is to allow the exported Terraform configuration to be reapplied to the existing Octopus resources while avoiding errors about resources already existing in the target space.
This is an example of the plan output from my sample project showing the differences:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="plaintext"><code>Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
 ~ update in-place

Terraform will perform the following actions:

 # octopusdeploy_project.project_my_project will be updated in-place
 ~ resource "octopusdeploy_project" "project_my_project" {
 id = "Projects-9441"
 name = "My Project"
 # (18 unchanged attributes hidden)

 + connectivity_policy {
 + allow_deployments_to_no_targets = true
 + exclude_unhealthy_targets = false
 + skip_machine_behavior = "None"
 + target_roles = []
 }

 + versioning_strategy {
 + template = "#{Octopus.Version.LastMajor}.#{Octopus.Version.LastMinor}.#{Octopus.Version.NextPatch}"
 }
 }

 # octopusdeploy_variable.my_project_project_test_variable_1 will be updated in-place
 ~ resource "octopusdeploy_variable" "my_project_project_test_variable_1" {
 id = "e1b1bb15-d61e-d241-316d-651e495b46e1"
 + is_editable = true
 + is_sensitive = false
 name = "Project.Test.Variable"
 + value = "whatever"
 # (4 unchanged attributes hidden)

 # (1 unchanged block hidden)
 }

Plan: 0 to add, 2 to change, 0 to destroy.
╷
│ Warning: Block Deprecated
│ 
│ with octopusdeploy_project.project_my_project,
│ on project_project_my_project.tf line 36, in resource "octopusdeploy_project" "project_my_project":
│ 36: resource "octopusdeploy_project" "project_my_project" {
│ 
│ octopusdeploy_project.versioning_strategy is deprecated in favor of resource octopusdeploy_project_versioning_strategy. See
│ https://oc.to/deprecation-tfp-project-versioning-strategy for more info and migration guidance.</code></pre>
It is good practice to run <code>terraform plan</code> after importing the resources to ensure that the Terraform configuration files match the state of the Octopus resources, and manually review the generated Terraform configuration files if needed to confirm they are correct.
<h2 id="backing-up-your-octopus-instance">Backing up your Octopus instance</h2>
Before making any changes to production resources, it is highly recommended that you <a href="https://octopus.com/docs/administration/data/backup-and-restore">backup the Octopus database</a>. While changes to projects are tracked in the Octopus audit log, having a backup of the database allows you to restore the state of your Octopus instance if something goes wrong.
You may also consider testing the export and import process on a test instance of Octopus running a copy of your production data, or on a cloned project. This allows you to verify the export and import process works as expected before applying it to your production projects.
<h2 id="applying-the-terraform-configuration">Applying the Terraform configuration</h2>
Once you are satisfied that the plan does not show any unexpected changes, you can run <code>terraform apply</code> to apply the configuration:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>terraform apply \
 -var=octopus_apikey=API-xxxxx \
 -var=octopus_server=https://instance.octopus.app \
 -var=octopus_space_id=Spaces-###</code></pre>
This will apply the Terraform configuration back to Octopus. We expect this operation to make no changes to the project, as the exported configuration matches the state of the project in Octopus.
Once the apply operation is complete, the project is managed by Terraform, and you can make any future changes to the project by editing and reapplying the Terraform configuration.
<h2 id="dealing-with-sensitive-variables">Dealing with sensitive variables</h2>
Octoterra reads the state of Octopus projects and variables via the API. The API does not export the values of sensitive variables, so Octoterra can not include sensitive values in the exported Terraform configuration files.
To manage sensitive variables, you can either:
<ul>
<li>Pass the value of sensitive variables as Terraform variables when running <code>terraform apply</code>, as Octoterra creates Terraform variables to define the values of all exported sensitive variables.</li>
<li>Exclude sensitive variables from the exported configuration and manage them separately in Octopus.</li>
</ul>
To exclude variables from the exported configuration, you can use the <code>-excludeProjectVariable</code> argument when running Octoterra. This argument can be passed multiple times to exclude multiple variables from the exported configuration.
For example, if the project had a sensitive variable called <code>Project.Test.Secret</code> that we wished to exclude from the exported configuration, we would run the following command:
<pre class="astro-code light-plus" style="background-color:#FFFFFF;color:#000000; overflow-x: auto;" tabindex="0" data-language="bash"><code>docker run -v $PWD:/tmp/octoexport --rm ghcr.io/octopussolutionsengineering/octoterra \
 -url https://instance.octopus.app \
 -space Spaces-## \
 -apiKey API-xxxx \
 -projectName "My Project" \
 -lookupProjectDependencies \
 -generateImportScripts \
 -excludeProjectVariable Project.Test.Secret \
 -dest /tmp/octoexport</code></pre>
This will exclude the <code>Project.Test.Secret</code> variable from the exported configuration, meaning it is not managed by Terraform, allowing you to manage it separately in the Octopus UI.
<h2 id="making-manual-changes-to-the-exported-configuration">Making manual changes to the exported configuration</h2>
The exported Terraform configuration files can be manually edited to apply any customizations or address any issues you may find. The beauty of Terraform and the Octopus Terraform provider is that the configuration files use an open, documented, and editable format.
You have complete control and ownership of the configuration once it is exported, and are free to make any changes you need.
<h2 id="conclusion">Conclusion</h2>
Customers with existing Octopus projects can now place them under Terraform management using the Octoterra tool. By exporting the projects to their equivalent Terraform configuration, importing the state, and applying the configuration, Octopus projects can be effectively migrated in-place with minimal disruption.]]></content>
</entry>
</feed>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=http%3A//feeds.feedburner.com/OctopusDeploy"><img src="valid-atom.png" alt="[Valid Atom 1.0]" title="Validate my Atom 1.0 feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//feeds.feedburner.com/OctopusDeploy

Home · About · News · Docs · Terms