This is a valid Atom 1.0 feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<link rel="self" href="https://octopus.com/feed" />
^
line 112, column 0: (26 occurrences) [help]
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-0 ...
line 112, column 0: (26 occurrences) [help]
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-0 ...
line 446, column 0: (2 occurrences) [help]
<iframe width="560" height="315" src="https://www.youtube.com/embed/3Ct0K ...
<feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">Octopus Deploy</title>
<subtitle type="text">Automated deployment platform</subtitle>
<id>https://octopus.com/feed</id>
<updated>2025-06-16T06:20:36.9374123Z</updated>
<link rel="alternate" href="https://octopus.com/blog" />
<link rel="self" href="https://octopus.com/feed" />
<entry>
<id>https://octopus.com/blog/ephemeral-environments</id>
<title type="text">Help shape Ephemeral Environments</title>
<published>2025-06-23T14:00:00Z</published>
<updated>2025-06-16T06:08:21.7366756Z</updated>
<author>
<name>harriet.alexander@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/ephemeral-environments" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-06/ephemeral-environments/blog-ephemeralenvironments25.png" alt="Banner showing a parent environment branching to two ephemeral environments while two illustrated developers point to the child nodes against a blue-green gradient background." /></p>
<p>In the fast-paced world of software development, few phrases provoke as much frustration as “it works on my machine”. It’s the ultimate debugging roadblock. Your code works flawlessly in your local environment, but everything breaks when it merges. But what if there was a way to ensure your code wasn’t just “working on your machine” but on an environment that mirrors your production environment before you merge?</p>
<p>In this post, I introduce our solution—Ephemeral Environments.</p>
<h2 id="what-are-ephemeral-environments">What are Ephemeral Environments?</h2>
<p>We've been hard at work developing Ephemeral Environments, tailored for modern development workflows. These environments are automatically generated and linked to feature branches created through pull requests (PRs). They offer a temporary space for testing code changes without affecting the main lifecycle environments.</p>
<p>The primary goal is to <em>shift left</em> in the development process: identifying issues earlier when they are easier and less costly to address. This then minimizes surprises later in the workflow.</p>
<h2 id="how-ephemeral-environments-will-work">How Ephemeral Environments will work</h2>
<ul>
<li>Feature branch-based: When you create a pull request (PR) from your feature branch, the ephemeral environment automatically spins up.</li>
<li>Temporary by design: After you close or merge the PR, the environment spins down in a hassle-free manner.</li>
<li>Designed for early feedback: The feature will provide developers and collaborators with early integration testing, UI validation, and fast feedback loops.</li>
</ul>
<h2 id="why-you-should-get-excited">Why you should get excited</h2>
<p>Catching issues earlier in the development lifecycle leads to better software, faster delivery, and happier teams. Here’s why we’re excited about Ephemeral Environments—and why we think you will be, too:</p>
<ul>
<li>Fewer environment bottlenecks: Don’t waste time waiting for staging slots or shared resources. Every feature branch gets its own environment.</li>
<li>Increased confidence in merges: Know your code works before merging into the main branch, so there are fewer surprises and regressions.</li>
<li>Seamless feedback loops: Ephemeral Environments are dynamic and easy to share. This increases collaboration across teams and stakeholders.</li>
</ul>
<h2 id="have-your-say-and-get-early-access-to-ephemeral-environments">Have your say and get early access to Ephemeral Environments</h2>
<p>We’re building this feature to make pull request workflows smarter, faster, and more reliable— but we'd love your feedback.</p>
<p>Whether you want to sign up for a product demo, participate in our alpha testing, or simply get notified when early access is available, we want to hear from you.</p>
<h3 id="whats-in-it-for-you">What’s in it for you?</h3>
<ul>
<li>Get early access: Get access to the ephemeral environment feature before it’s widely available.</li>
<li>Influence design: Your feedback will directly shape how we refine the feature, ensuring it meets real-world workflows.</li>
</ul>
<h2 id="how-to-sign-up">How to sign up</h2>
<p><a href="https://octopusdeploy.typeform.com/to/ZOia9Aje" rel="nofollow">Register your interest via our form</a>.</p>
<p>We're hoping to release ephemeral environments in all instances later this year.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/announcing-the-first-state-of-gitops-report</id>
<title type="text">The State of GitOps report: Exploring effective GitOps</title>
<published>2025-06-17T14:00:00Z</published>
<updated>2025-06-16T06:20:36.9374123Z</updated>
<author>
<name>steve.fenton@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/announcing-the-first-state-of-gitops-report" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-06/announcing-the-first-state-of-gitops-report/what-is-gitops-2025.png" alt="Person holds magnifying glass over GitOps logo, surrounded by icons for declarative, versioned and immutable, pulled automatically, and continuously reconciled." /></p>
<p>We're thrilled to announce the release of the <a href="https://octopus.com/publications/state-of-gitops-report">State of GitOps report</a>. This report is the first to explore how practitioners apply GitOps concepts in the real world. Based on data from 660 survey responses and interviews with a panel of experts and practitioners, our goal was to understand what &quot;good&quot; GitOps looks like, explore different adoption styles, and analyze whether GitOps delivers the expected benefits.</p>
<p>Combining version control, developer practices, and an automated reconciliation loop, GitOps can deliver a secure and auditable way to drive system state with human-readable files. While teams with well-established GitOps practices are seeing a return on their investment, those who haven't achieved a sufficient depth and breadth of adoption are struggling to beat the j-curve to get the benefits. This is where the State of GitOps report can help.</p>
<h2 id="four-key-findings">Four key findings</h2>
<p>Our research explored various aspects of GitOps adoption and its impact, and we've uncovered 4 key findings:</p>
<ol>
<li><strong>Better software delivery:</strong> High-performing GitOps teams demonstrated higher software delivery performance, as measured by the DORA 4 key metrics (change failure rate, time to recover, deployment frequency, and lead time for changes).</li>
<li><strong>Increased reliability:</strong> These high-performing teams also reported the best reliability records, based on user satisfaction, meeting uptime targets, and avoiding slowdowns and outages.</li>
<li><strong>Security and compliance:</strong> We found a clear link between GitOps maturity (how many practices teams adopt) and achieving security and compliance benefits.</li>
<li><strong>Adoption is increasing:</strong> Most organizations (93%) plan to continue or increase their GitOps adoption, indicating strong confidence in the approach.</li>
</ol>
<p>The report delves into the nuances of adoption, distinguishing between 'breadth' (the extent across production systems) and 'depth' (how many practices are implemented and how well).</p>
<p>We found that GitOps is most often used for application or service deployments (79%), application configurations (73%), and infrastructure (57%). We also challenge the idea that GitOps is <em>only</em> for Kubernetes, with 26% of organizations applying it to other technology stacks.</p>
<h2 id="the-gitops-model">The GitOps model</h2>
<p>A significant part of the report introduces the GitOps Model, outlining the 6 practices we found necessary for successful adoption and positive outcomes:</p>
<ol>
<li>Declarative desired state</li>
<li>Human readable format</li>
<li>Responsive code review</li>
<li>Version control</li>
<li>Automatic pull</li>
<li>Continuous reconciliation</li>
</ol>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-06/announcing-the-first-state-of-gitops-report/gitops-model.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-06/announcing-the-first-state-of-gitops-report/gitops-model.png' class="img-fluid center" alt='The 6 GitOps practices drive DevOps outcomes for software delivery, reliability, and wellbeing' /></a></p>
<p>We developed a GitOps score based on how closely organizations align with these practices and found organizations with higher scores are most likely to obtain the benefits of GitOps. This means teams with higher scores were significantly more likely to report:</p>
<ul>
<li>Increased security</li>
<li>Prevention of configuration drift</li>
<li>Improved auditability</li>
<li>Easier compliance</li>
<li>Reduced elevated access</li>
</ul>
<p>The ability to recreate applications from version control is also strongly linked to higher scores.</p>
<h2 id="gitops-practices-and-devops-outcomes">GitOps practices and DevOps outcomes</h2>
<p>Beyond specific GitOps benefits, the report also examines the relationship between GitOps and broader DevOps outcomes, like software delivery performance, reliability, and even wellbeing. Higher GitOps scores correlate positively with these outcomes.</p>
<p>It's essential to be aware of the potential &quot;j-curve&quot; effect when adopting new practices like GitOps. You might see an initial dip in performance as you introduce new skills and practices, but sticking with it leads to significant long-term gains. The 6 GitOps practices are mutually supportive; leaving one out can create gaps in the effectiveness of others.</p>
<p>Of course, adopting GitOps isn't without its challenges. The report identifies potential &quot;trip hazards&quot;, like the risk of accidental resource deletion, leaking secrets in version control, overloading version control systems, and gaps in deployment processes or access controls. Understanding these pitfalls and adopting protective measures, like dry-runs, approval workflows, secret management tools, and robust access control, is crucial.</p>
<p>The State of GitOps Report is a comprehensive baseline for where GitOps stands today. It offers valuable insights into the practices that drive success and helps you understand how to improve your own outcomes.</p>
<p>We encourage you to <a href="https://octopus.com/publications/state-of-gitops-report">dive into the full report</a> to explore the findings, understand the GitOps model, and identify areas for continuous improvement on your GitOps journey.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/inside-devops-oluwateniola-olubowale</id>
<title type="text">Inside DevOps with Oluwateniola Olubowale from United Capital</title>
<published>2025-06-16T14:00:00Z</published>
<updated>2025-06-13T06:33:09.8433565Z</updated>
<author>
<name>joanna.wyganowska@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/inside-devops-oluwateniola-olubowale" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-06/inside-devops-oluwateniola-olubowale/img-blog-inside-inside-devops-750x400-oluwateniola-1x-no-title.png" alt="Photo of Oluwateniola Olubowale" /></p>
<p>This post is the next in our <a href="https://octopus.com/blog/tag/Inside%20DevOps">Inside DevOps series</a>, where we share lessons learned from those on the frontlines of DevOps.</p>
<p>Hear from <a href="https://www.linkedin.com/in/oluwateniola-olubowale-362905200/" rel="nofollow">Oluwateniola Olubowale</a>, DevOps Engineer at United Capital, a leading African financial and investment banking group.</p>
<p><strong>What is DevOps to you? How do you define it?</strong></p>
<p><em>Oluwateniola:</em> DevOps represents a fundamental cultural shift rather than just a technical discipline. It’s about fostering close collaboration between development and operations teams to deliver high-quality software at speed. It emphasizes automation, transparency, and continuous feedback, all aimed at driving measurable business outcomes.</p>
<p><strong>How did your DevOps journey start?</strong></p>
<p><em>Oluwateniola:</em> It began when I transitioned from a backend development role to one that required more involvement with infrastructure and deployment processes. I became increasingly curious about the delays and inefficiencies that occurred after code was written. This curiosity led me to explore Continuous Integration, containerization, and Infrastructure as Code (IaC)—areas that gradually shaped my path into DevOps.</p>
<p><strong>What’s the most challenging part of DevOps?</strong></p>
<p><em>Oluwateniola:</em> The biggest challenge often lies in changing organizational culture. Encouraging teams to adopt a shared sense of ownership, prioritize automation, and embrace continuous learning can take time. Tools and pipelines can be implemented, but achieving true cross-functional collaboration requires leadership, patience, and clear communication.</p>
<p><strong>What’s the most rewarding part of DevOps?</strong></p>
<p><em>Oluwateniola:</em> It’s incredibly fulfilling to see deployment processes evolve from being high-risk and manual to being streamlined, automated, and dependable. Knowing that you’ve helped build systems that allow developers to deliver confidently and recover gracefully from failure makes the work meaningful.</p>
<p><strong>What DevOps trend have you been following lately?</strong></p>
<p><em>Oluwateniola:</em> Recently, I’ve been following the rise of GitOps and Platform Engineering. GitOps offers a powerful, declarative approach to managing infrastructure and application deployments, while Platform Engineering focuses on building internal developer platforms (IDPs) that improve scalability and developer experience.</p>
<p><strong>What are some DevOps best practices your organization has implemented?</strong></p>
<p><em>Oluwateniola:</em> Our team has embraced several best practices, including Infrastructure as Code with Terraform, Continuous Integration and Continuous Delivery, automated testing, and the use of blue/green deployments. We also use centralized logging and observability, using tools like the ELK Stack and Prometheus with Grafana. Regular retrospectives are part of our process to ensure continuous improvement.</p>
<p><strong>What’s the biggest challenge Octopus has helped you with?</strong></p>
<p><em>Oluwateniola:</em> Octopus has played a critical role in standardizing and simplifying our deployment workflows. It has brought consistency across environments, improved auditability, and significantly reduced manual intervention. With Octopus, we’ve been able to automate complex deployments while maintaining visibility and control.</p>
<p><strong>What advice would you give someone just starting their DevOps journey?</strong></p>
<p><em>Oluwateniola:</em> Focus on the principles before the tools. Understand the value of collaboration, automation, and Continuous Delivery. Start small, learn version control, build simple CI/CD pipelines, and iterate. Most importantly, don’t be afraid to make mistakes; each challenge is an opportunity to learn and grow.</p>
<p><strong>What DevOps book would you recommend reading?</strong></p>
<p><em>Oluwateniola:</em> <a href="https://octopus.com/devops/reading-list/#the-phoenix-project">The Phoenix Project</a> by Gene Kim remains one of the most accessible and insightful introductions to DevOps. It conveys key concepts through relatable storytelling. For a deeper dive, <a href="https://octopus.com/devops/reading-list/#the-devops-handbook">The DevOps Handbook</a> by Gene Kim, Jez Humble, Patrick Debois, and John Willis offers a comprehensive, practical guide to implementing DevOps practices.</p>
<p><strong>What’s one thing about you that might surprise us?</strong></p>
<p><em>Oluwateniola:</em> I originally aspired to become a marine engineer. That foundation in systems thinking and design eventually led me to software engineering. Today, instead of engines and vessels, I focus on building and optimizing robust software systems, but the problem-solving mindset remains the same.</p>
<p><strong>Thank you for sharing your insights with us, Oluwateniola!</strong></p>
<div class="alert alert-info"><p>If you’d like to be featured in our series, <a href="https://octopus.com/blog/tag/Inside%20DevOps" class="alert-link">Inside DevOps</a>, please reach out to <a href="https://www.linkedin.com/in/joannawyganowska/" class="alert-link" rel="nofollow">Joanna on LinkedIn</a> to set up a time for a quick chat.</p>
</div>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/beyond-skeleton-pipelines-who-owns-software-pipelines</id>
<title type="text">Beyond skeleton pipelines: who owns your software pipeline?</title>
<published>2025-06-11T14:00:00Z</published>
<updated>2025-06-06T03:51:36.4237762Z</updated>
<author>
<name>matthew.allford@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/beyond-skeleton-pipelines-who-owns-software-pipelines" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-06/beyond-skeleton-pipelines-who-owns-software-pipelines/blogimage-highperformancedevopstoolchain-2023.png" alt="Stylized image of two people doing maintenance work on a DevOps infinity symbol with a cog and timer at its center." /></p>
<p>Your current software delivery processes are probably working fine. They build your code, maybe run a test or two, and get your software to production. That's no small achievement, but here's a question that might make you pause.</p>
<p>When did someone last spend time improving them?</p>
<p>If you're like many software teams I've worked with, the answer is probably &quot;not recently&quot;. Maybe not ever.</p>
<p>I've worked with developer teams at different maturity levels and have repeatedly seen this pattern. Great development teams who are busy building software but aren't large enough to have platform teams or dedicated operational folk responsible for the software delivery process. They typically start with a template from their cloud provider, delivery tooling vendor, or, these days, their favorite AI LLM. Initially, it gets the job done, but I refer to these as skeleton pipelines—the bare minimum framework to ship code.</p>
<p>Skeleton pipelines are a great starting point. They get you from nothing to shipping code quickly, but your pipelines are living, breathing artifacts. Before long, they need some meat added to the skeleton to provide functionality beyond the basics and make your delivery process robust and delightful.</p>
<p>I've seen when teams experience friction with their software release process, but don't treat it as a bug or feature improvement that needs to be logged, prioritized, and worked on. If your deployment pipelines are responsible for delivering your product to customers, shouldn't you treat them as part of your product? When was the last time someone added a pipeline improvement to your backlog or spent time making your deployment process better?</p>
<p>The important shift is treating delivery process improvements as regular development work, not spare-time projects that inevitably get pushed aside.</p>
<h2 id="the-ownership-vacuum">The ownership vacuum</h2>
<p>Ask any group of engineers, &quot;Who owns your software delivery pipelines?&quot; and I bet you'll get different answers. When writing this post, I put that question into a search engine and reviewed the discussions, which weren't surprising. Some say developers should own what they build, others insist it's up to platform or DevOps engineers. Then there's the view that everyone is responsible because DevOps is about everyone working together. My observation is that often, no one owns it, and that's when it becomes a problem.</p>
<p>The distinction that matters isn't really about ownership. It's about accountability. Someone needs to be accountable for ensuring your delivery process evolves, improves, and supports your organization with shipping software rather than being a friction-filled process people loathe working with. Without that accountability, pipelines can easily become unmanaged components that gradually deteriorate until they become technical debt and a bottleneck instead of an enabler.</p>
<p>There's no one-size-fits-all answer for who should own and be accountable for your pipelines. You must discuss and agree based on your maturity, size, team structure, and individual skill sets. The important thing is that it is discussed and agreed upon, and not left to assumptions. Ask yourself now if everyone on the team knows how and where to raise an issue with the deployment process today. If the answer is no, then start there. Determine who's responsible and establish clear channels for pipeline feedback, problems, and improvements.</p>
<h2 id="the-cost-of-skeleton-pipelines">The cost of skeleton pipelines</h2>
<p>This ownership vacuum creates predictable problems I've seen many times. Teams fall into the &quot;if it ain't broke, don't fix it&quot; mentality, leaving pipelines as-is for months or years. The issue is that what worked well 6, 12, or 18 months ago likely isn't fit for purpose today. New tooling and techniques exist now that didn't then. Your team will likely ship more frequently—or at least want to—and handle more complex deployments than when you first created that pipeline. The infrastructure you're deploying to has likely changed. Different developers and engineers might work at your company who didn't before. You're missing out on tooling and practices that could:</p>
<ul>
<li>Save weekly hours</li>
<li>Bring new functionality to your software delivery lifecycle that adds business value</li>
<li>Catch issues before they become customer problems</li>
</ul>
<p>Worse, they often become single points of knowledge. Whoever initially sets up the pipeline is the only person who understands how it works. When that person leaves or gets pulled onto other projects, your team inherits a mysterious system everyone fears touching.</p>
<p>Fragile pipelines break at the worst possible moments. They miss opportunities to catch issues early, optimize build times, have predictable outcomes, or provide better feedback to developers. Maybe, most importantly, they frustrate your team and slow down what they're supposed to enable: shipping great software and products.</p>
<h2 id="you-cant-afford-to-ignore-this">You can't afford to ignore this</h2>
<p>&quot;We're too busy building features to worry about pipeline improvements.&quot; Sound familiar? It's a common pushback I hear from teams, and I get it. When trying to ship products and keep customers happy, spending time on what feels like an internal process is often considered a luxury you can't afford.</p>
<p>Platform teams are getting a lot of attention lately, and for good reason, as they work well for larger organizations. But if your company doesn't need everything else a platform team typically handles, creating one just for pipeline ownership is unnecessary. The reality is that you don't need a dedicated platform team to own your pipelines. You can borrow their mindset by treating your delivery process as part of your product. Pipeline improvements get backlog items, performance issues get bug tickets, and deployment pain points get the same attention as user-reported problems.</p>
<p>Start by paying attention to where your process hurts. If deployments make you nervous, your team loathes &quot;release day&quot;, when releases fail for mysterious reasons or when you're manually testing things your team can automate. These pain points are your roadmap for high-value improvements.</p>
<h2 id="making-the-investment">Making the investment</h2>
<p>Improvements may include:</p>
<ul>
<li>Adding vulnerability scanning during builds</li>
<li>Configuring integration tests against ephemeral infrastructure</li>
<li>Properly storing and versioning your deployment artifacts</li>
<li>Implementing flexible approval workflows</li>
<li>Creating a robust deployment strategy</li>
<li>Measuring deployment metrics</li>
</ul>
<p>I'm not giving you a shopping list of things to do. Instead, I recognize that &quot;you don't know what you don't know&quot; because I've been there too, and you may be experiencing issues you didn't know there were solutions to.</p>
<p>We have a white paper titled <a href="https://octopus.com/whitepapers/ten-pillars-of-pragmatic-deployments">The ten pillars of pragmatic deployments</a>. I bring this to your attention not for a checklist of everything you should do but for insight into what we think good deployments look like based on years of experience building a deployment automation tool. The ideas discussed in this post might help you enhance your software delivery process today or provide insight into issues and solutions you may not have been aware of.</p>
<h2 id="take-ownership">Take ownership</h2>
<p>It's easy to overlook software delivery pipelines. They're usually out of sight until they get in your way, kind of like plumbing. It's invisible when it works and catastrophic when it doesn't. Excellent plumbing supports everything in your house to function smoothly, and great delivery processes do the same for your product development.</p>
<p>Claim ownership of your software delivery processes and ensure someone is accountable for their care and feeding. Talk to your engineers involved in developing and releasing software, and find out where the pain is. Implement easy-to-use feedback loops, add pipeline improvements to your backlog, and treat deployment pain points as bugs worth investing in and fixing.</p>
<p>Your future self and team will thank you when your next deployment goes smoothly instead of keeping everyone up after hours or nervously huddling around a few pizzas doing your monthly release with crossed fingers.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/changes-to-enterprise</id>
<title type="text">New to our Enterprise tier</title>
<published>2025-06-09T14:00:00Z</published>
<updated>2025-05-30T00:46:41.6398725Z</updated>
<author>
<name>michelle.obrien@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/changes-to-enterprise" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-06/changes-to-enterprise/additions_and_improvements_to_enterprise_offering_2025_1500x800.jpg" alt="People in front of a building with icons around them representing security and data." /></p>
<p>This quarter, we challenged ourselves to make small but impactful changes to our enterprise offering. In Octopus Server 2025.2, we added:</p>
<ul>
<li>Global deployment freezes</li>
<li>Priority deployments</li>
<li>ITSM for runbooks </li>
</ul>
<p>We also added new capabilities to the Deployment Freeze and Priority Deployments features.</p>
<p>In this post, I take you through the changes to our Enterprise tier.</p>
<h2 id="deployment-freezes">Deployment freezes</h2>
<p>From Octopus Server 2025.2, all enterprise customers have access to both global freezes and our new project-level freezes.</p>
<p>Project freezes provide an entry level to deployment freezes with lower permission requirements. They empower your teams to create their own freezes for projects without needing administrator permissions. <a href="https://octopus.com/docs/deployments/deployment-freezes/project-deployment-freezes">Read more about project freezes in our docs</a>.</p>
<p>Recent enhancements to our Deployment Freeze feature include:</p>
<ul>
<li>Recurring deployment freezes—so you can create maintenance windows.</li>
<li>Freeze by tenant—for more granular freezes.</li>
</ul>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-06/changes-to-enterprise/global-freeze.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-06/changes-to-enterprise/global-freeze.png' class="img-fluid center" alt='Create Deployment Freeze window showing new functionality of recurring freezes' /></a></p>
<h2 id="priority-deployments">Priority deployments</h2>
<p>Our Priority Deployments feature provides 2 ways to automate deployment priority:</p>
<ol>
<li>Prioritize the deployment when creating a new deployment.</li>
<li>Prioritize an environment in a lifecycle phase. This prioritizes all deployments to the environments in the lifecycle.</li>
</ol>
<p>In 2025.2, we expanded priority deployments to runbooks. This makes it easier to proactively manage your task queue. Individual runbooks inherit the lifecycle priority, or you can prioritize individuals runs on an adhoc basis.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-06/changes-to-enterprise/priority-runbooks.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-06/changes-to-enterprise/priority-runbooks.png' class="img-fluid center" alt='New Runbook run window showing new functionality of Priority Deployments for Runbooks' /></a></p>
<h2 id="itsm-for-runbooks">ITSM for runbooks</h2>
<p>You can now create ITSM change requests from your runbooks. This is particularly useful if you use runbooks to provision infrastructure and need to attach change requests to progress through the relevant approvals. You can choose which runbooks you'd like to be change-controlled in your ITSM settings.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-06/changes-to-enterprise/itsm-runbooks.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-06/changes-to-enterprise/itsm-runbooks.png' class="img-fluid center" alt='ITSM settings window showing new functionality of ITSM for Runbooks' /></a></p>
<h2 id="whats-next">What's next?</h2>
<p>We also have more exciting changes coming soon to our Enterprise tier.</p>
<h3 id="standardized-reusable-and-flexible-deployment-processes-with-process-templates">Standardized, reusable, and flexible deployment processes with Process Templates</h3>
<p>Process Templates will soon be available as an early access preview (EAP) for enterprise customers. This gives teams reusable blocks of steps to use as blueprints to reduce process duplication and standardize best practices across pipelines.</p>
<p>Platform teams can update and roll out changes to these templates from a new area in Octopus, the Platform Hub, making them easier to maintain in the long term. Some steps will also be flexible, so teams have the freedom to diverge without sacrificing quality or compliance.</p>
<p>This is the first feature from our Blueprints and Guardrails set of capabilities, letting you automate compliance and standardize best practices across your organization's deployment processes. Keep an eye on <a href="https://roadmap.octopus.com/tabs/2-planned" rel="nofollow">our roadmap</a> for what else the team has planned, including:</p>
<ul>
<li>Deployment Policies</li>
<li>Project Templates</li>
</ul>
<h2 id="interested-in-upgrading-to-the-enterprise-tier">Interested in upgrading to the Enterprise tier?</h2>
<p>Please contact our helpful <a href="mailto:sales@octopus.com" rel="nofollow">Sales team</a>.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/octopus-datadog-integration</id>
<title type="text">Introducing the Octopus Datadog integration</title>
<published>2025-06-08T14:00:00Z</published>
<updated>2025-06-10T00:17:27.6392689Z</updated>
<author>
<name>tegan.ali@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/octopus-datadog-integration" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-06/octopus-datadog-integration/img-blog-datadog-octopus-integration-2025.png" alt="Octopus and Datadog logos connected by plugs with little stars around the connection." /></p>
<p>Octopus is a best-of-breed platform that provides Continuous Delivery at scale and integrates with all your tools across the software delivery pipeline. Datadog is the best-of-breed monitoring platform that monitors, secures, and provides alerts for all the tools in your DevOps stack. This includes infrastructure monitoring, application performance, and software delivery pipelines.</p>
<p>Now, with the Octopus Datadog integration, it's even easier to use Octopus and Datadog together.</p>
<p>The Octopus Datadog integration monitors Octopus deployments through the Datadog Agent. This gives customers using Datadog and Octopus visibility across their entire CI/CD pipeline, helping you correlate data, to find and solve issues faster.</p>
<p>In this post, we introduce the Octopus Datadog integration. We explain how it helps orchestrate the insights from all your tools and connect the dots when something goes wrong.</p>
<h2 id="the-need-for-better-observability-across-your-entire-pipeline">The need for better observability across your entire pipeline</h2>
<p>Without robust monitoring in place, it’s challenging to get visibility across your entire CI/CD pipeline and connect problems with the issues that caused them. Sometimes you don’t even have access to all the systems in your stack.</p>
<p>For teams using Kubernetes, you might get an alert when an issue arises, but often you won’t have access to the Kubernetes cluster. You're left making guesses and assumptions based on what changed.</p>
<p>If you’re using legacy systems, it’s a struggle to debug your systems when few, if any, people on the team have in-depth knowledge about them anymore. Plugins fall out of date, and performance and reliability begin to wane, so issues arise more often. It can take days to find and fix problems. This has flow-on effects for other work, like urgent security patches, and slows down releases, affecting due dates.</p>
<p>Modern tools and practices are better designed to prevent issues from occurring and make troubleshooting easier, but it’s still difficult to get visibility across your entire CI/CD pipeline without an observability tool. We also know that many organizations are modernizing over time, so they rely on a mix of modern and heritage technologies. Luckily, both Datadog and Octopus provide best-of-breed solutions for monitoring and delivering software at scale, regardless of technology.</p>
<h2 id="monitoring-and-observability-in-octopus">Monitoring and observability in Octopus</h2>
<p>Octopus already provides great visibility into all your deployments on our dashboards. You can see the stage, environment, and state of each deployment across multiple repositories in one place. You can also dive into the details of your projects and releases from the bird's-eye view of your dashboard.</p>
<p>This year, we strengthened our observability and monitoring with <a href="https://octopus.com/blog/kubernetes-live-object-status">Kubernetes Live Object Status</a>, which gives you real-time updates about the state of your applications running on Kubernetes. You can:</p>
<ul>
<li>Get the live status of your applications on the main and project dashboards.</li>
<li>Get the list of all deployed objects and their live status.</li>
<li>Review object events, logs, and manifests running in a cluster.</li>
<li>Compare the applied (desired) and live (currently running) manifests for any Kubernetes object.</li>
</ul>
<p>Octopus's <a href="https://octopus.com/docs/insights">DevOps Insights</a> uses DORA metrics to tell you exactly how you're performing, so you can find areas for improvement in your deployment processes.</p>
<h2 id="why-use-octopus-and-datadog-together">Why use Octopus and Datadog together?</h2>
<p>While Octopus provides visibility and monitoring for your deployments at scale, it can be hard to correlate data across the entirety of your CI/CD pipeline when things happen in systems outside your deployment pipeline.</p>
<p>That’s where Datadog helps. It monitors everything in your stack, covering all infrastructure, systems, apps, and services in one place.</p>
<p>Used together, Octopus and Datadog become part of your world-class pipeline, with both tools supporting software at scale and integrating with any technology. You get a single pane of glass for monitoring, making it easier to track, visualize, and improve key metrics across all projects.</p>
<h2 id="better-observability-and-faster-recovery">Better observability and faster recovery</h2>
<p>The new Octopus Datadog integration makes it easy for Datadog to collect metrics from Octopus so you can centralize your monitoring.</p>
<p>For DevOps and platform engineers, you can track the performance of your teams’ pipelines and visualize key metrics across all projects in one place.</p>
<p>For site reliability engineers (SREs) and operations folks, the Octopus Datadog integration lets you monitor your applications running in production. You can see logs, detect issues fast, and debug issues with critical context to resolve them quickly.</p>
<p>If you’re deploying to Kubernetes but don’t have access to the Kubernetes cluster, you can check the status in Octopus using Kubernetes Live Object Status. Using both Octopus and Datadog, you can see what’s broken, then easily redeploy in Octopus using <a href="https://octopus.com/docs/runbooks">runbooks</a> to roll back or forward.</p>
<p>If you’re using heritage systems, Datadog monitors those, too, and provides alerts so you can find issues fast. You can easily redeploy in Octopus to fix configuration values that teams sometimes change directly. Octopus also lets you restart web servers quickly and reliably with runbooks.</p>
<h2 id="how-the-integration-works">How the integration works</h2>
<p>The Octopus Datadog integration monitors Octopus deployments through the Datadog Agent.</p>
<p>The Datadog Agent collects:</p>
<ul>
<li>Metrics used for performance monitoring, like average deployment time per environment, and deployment failure rate for a project.</li>
<li>Deployment logs, which are useful for debugging failed deployments.</li>
<li>Server logs, which provide diagnostic information about the Octopus server.</li>
</ul>
<p>After the integration is set up to send data to Datadog, you can use out-of-the-box dashboards to get an overview of each deployment by project. Build monitors alert you of notable events, like a failed deployment, so you can take action promptly. Octopus's <a href="https://octopus.com/docs/security/users-and-teams/auditing/audit-stream#configure-audit-stream">audit log stream</a> can further enrich this data, which you can combine within Datadog for more insights.</p>
<h2 id="see-the-integration-in-action">See the integration in action</h2>
<iframe width="560" height="315" src="https://www.youtube.com/embed/3Ct0Kuvj6NI?si=Zvt1bcSi60mSdtpd" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
<h2 id="who-can-use-the-integration">Who can use the integration</h2>
<p>The integration is available to any Octopus and Datadog customers with <a href="https://www.datadoghq.com/dg/enterprise/it-infrastructure-monitoring/" rel="nofollow">Datadog’s Infrastructure Monitoring</a>.</p>
<p>The metrics sent from the integration, the dashboard, and the monitors, are all standard as part of the integration. (Logs collected from the integration are subject to <a href="https://docs.datadoghq.com/account_management/billing/pricing/#log-management" rel="nofollow">logs pricing with Datadog</a>.)</p>
<p>To set up the Octopus Datadog integration, <a href="https://docs.datadoghq.com/integrations/octopus_deploy/" rel="nofollow">follow the simple instructions provided by Datadog</a>.</p>
<h2 id="conclusion">Conclusion</h2>
<p>Datadog is a best-of-breed monitoring and observability platform, letting you see inside any stack, any app, at any scale, anywhere. When integrated with Octopus as a best-of-breed Continuous Delivery platform, you get world-class observability and CD that let you find problems fast, recover rapidly, and deliver software quickly and reliably at scale.</p>
<p>If you're already using both Octopus and Datadog, you can set up the integration by following the <a href="https://docs.datadoghq.com/integrations/octopus_deploy/" rel="nofollow">instructions in Datadog's docs</a>.</p>
<p>If you're a Datadog customer interested in using 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>.</p>
<p>You can also see the Octopus Datadog integration in action by visiting us at DASH, Datadog’s annual observability conference, in New York City, June 10–11, 2025. We’ll be at booth S-7.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/terraform-provider-release</id>
<title type="text">V1.0 release of the Octopus Deploy Terraform Provider</title>
<published>2025-06-04T14:00:00Z</published>
<updated>2025-06-02T08:05:04.7310873Z</updated>
<author>
<name>venkatesh.vasudevan@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/terraform-provider-release" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-06/terraform-provider-release/img-terraform-provider-2025.png" alt="Terraform branded crane lifting an Octopus branded box." /></p>
<p>The Octopus Deploy Terraform Provider has officially reached version 1.0. This release introduces expanded capabilities, fixes long-standing bugs, and provides improved documentation.</p>
<p>In this post, I take you through the key updates and features included in this release.</p>
<h2 id="expanded-terraform-provider-capabilities">Expanded Terraform Provider capabilities</h2>
<p>Version 1.0 brings substantial improvements to managing Octopus Deploy resources through Terraform. Earlier versions of the Provider lacked support for creating all resource types available in the Octopus UI. We addressed this limitation, enabling comprehensive resource management directly from Terraform. While we support most resources now, there are still a few exclusions. These are intentional and thoroughly <a href="https://registry.terraform.io/providers/OctopusDeploy/octopusdeploy/latest/docs" rel="nofollow">documented</a> for transparency.</p>
<h2 id="clearer-documentation-with-practical-examples">Clearer documentation with practical examples</h2>
<p>For a better user experience, we updated the <a href="https://registry.terraform.io/providers/OctopusDeploy/octopusdeploy/latest/docs" rel="nofollow">documentation</a> to include detailed examples and best practices for using the Terraform Provider effectively. We outlined 5 key scenarios to guide you. The documentation found at <a href="https://registry.terraform.io/providers/OctopusDeploy/octopusdeploy/latest/docs" rel="nofollow">the Terraform registry</a> now also has examples for all data sources and resources.</p>
<h2 id="bug-fixes-and-improvements">Bug fixes and improvements</h2>
<p>We resolved several long-standing bugs in this release. This improves the Provider and ensures a more stable and reliable experience.</p>
<ul>
<li>New deployment process resource: We made it easier to define and manage deployment processes by making each step its own resource. We also introduced a step order resource so you can easily manage the deployment process step order. You can find out more info on how it works in the <a href="https://registry.terraform.io/providers/OctopusDeploy/octopusdeploy/latest/docs" rel="nofollow">official docs</a>.</li>
<li>Migration to Terraform framework: Transitioning from the Terraform SDK to the framework has improved safety, reliability, and adaptability for future updates.</li>
<li>Adoption of semantic versioning (SemVer): The Provider now adheres strictly to SemVer principles. This helps you manage version changes more predictably.</li>
</ul>
<h2 id="migration-guidance">Migration guidance</h2>
<p>As this is a major version release, some breaking changes may require updates to existing configurations. To help with this transition, we have a <a href="https://registry.terraform.io/providers/OctopusDeploy/octopusdeploy/latest/docs" rel="nofollow">comprehensive migration guide</a>. Please review it carefully before upgrading your environments.</p>
<h3 id="provider-migrated-to-octopus-deploy-repository">Provider migrated to Octopus Deploy repository</h3>
<p>The Terraform Provider has always lived in our OctopusDeployLabs repository, which signalled that it was an experimental integration. We decided to move it to our <a href="https://github.com/octopusdeploy" rel="nofollow">official repository</a>, elevating it as a core integration.</p>
<h2 id="version-controlled-projects-and-the-terraform-provider">Version-controlled projects and the Terraform Provider</h2>
<p>We observed customers using Terraform and version control together to manage their projects and runbooks. While they're both powerful tools, combining them led to unexpected behaviours that can break instances.</p>
<p>To ensure stability, we’re taking a clear stance: from version 1.0 onwards, you can manage your Octopus projects or runbooks using <em>either</em> version control or Terraform—but not both.</p>
<p>If you try to manage a version-controlled project or runbook with Terraform, the Provider will return an error. We designed this change to protect your instance and ensure predictable behavior when managing your Octopus instance.</p>
<h2 id="conclusion">Conclusion</h2>
<p>The v1.0 release solidifies the Octopus Deploy Terraform Provider as a robust tool for managing your Octopus instance as code. By simplifying resource management and improving documentation, teams can work more efficiently with the Terraform provider</p>
<p>For detailed information on all changes and enhancements, please <a href="https://registry.terraform.io/providers/OctopusDeploy/octopusdeploy/latest/docs" rel="nofollow">read the docs</a> or visit the Terraform registry page for the Provider.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/new-leadership-code</id>
<title type="text">Our new leadership code</title>
<published>2025-05-28T14:00:00Z</published>
<updated>2025-05-27T01:41:21.1030452Z</updated>
<author>
<name>orli.remez@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/new-leadership-code" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-05/new-leadership-code/img-blog-leadership-code-2025.png" alt="Stylized image of people scaling a rock in the clouds, helping each other up, with 2 people at the top" /></p>
<p>Octopus has changed a lot in the past few years. We’ve grown to over 300 people, now spread across 17 countries and time zones. A year ago, we joined forces with Codefresh, and we’re still finding our rhythm as we bring together different ways of working, cultures, and perspectives.</p>
<p>Our managers reflect this diversity—different backgrounds, different strengths, and different approaches. And while that makes us stronger, it also makes leadership more complex. We’re moving fast, navigating change daily, and building the plane as we fly it.</p>
<p>In the midst of this momentum, we realized something important: to stay grounded in who we are and focused on where we’re headed, we needed a shared foundation. A way to align on what great leadership looks like <em>here</em>, <em>now</em>, at Octopus.</p>
<p>Enter: the Leadership CODE.</p>
<p>Octopus was founded with a philosophy of creating a working environment where employees can <a href="https://octopus.com/company/careers">do the best work of their lives</a>, and our leaders are key in maintaining and strengthening this culture in the face of our growth and development. As time went by, we understood we were missing a framework to help them do that, so we put our heads together to come up with our new Leadership CODE. The process of its creation was much more meaningful than I had expected, so we're excited to share its story with you.</p>
<h2 id="the-leadership-code-concept">The Leadership CODE concept</h2>
<p>There are countless leadership behaviors and skills out there, and just like with values, none are inherently wrong. But part of leading well is knowing how to focus. As we grow and evolve as a company, we recognize the need to align on the <em>core</em> leadership principles that matter most right now, at this particular stage in our journey.</p>
<p>That’s what inspired the Leadership CODE. Our idea was to create a simple, concrete, and actionable guide to help leaders at Octopus balance delivering on ambitious goals while staying deeply committed to their people and to our values.</p>
<p>The CODE isn’t meant to capture every great leadership trait—it’s a purposeful selection of the principles we believe leaders should <strong>embrace and model today</strong>, to help us scale thoughtfully, collaborate effectively, and stay true to what makes Octopus special.</p>
<p>In essence, the CODE serves as a shared leadership language. It helps us set clear expectations, strengthen consistency across teams, and support each other as we tackle tough challenges. It’s also a way to reflect our values in how we lead every day—intentionally, and together.</p>
<h2 id="how-we-built-it">How we built it</h2>
<p>Creating the Leadership CODE was as meaningful as the outcome itself. We started by gathering insights from across the organization—through surveys and interviews with all managers and senior leaders—to uncover what makes leadership successful at Octopus. Leading themes we found were humility, trust, and clear communication, alongside the need to foster contagious energy and leadership by example.</p>
<p>After we analyzed the data, we focused on defining principles that could act as a shared leadership vocabulary to promote the themes we discovered. These practices focused on effective communication, aligning on priorities, and modeling the behaviors we want to see across the organization. This shared language, our CODE, is the basis for building trust, breaking down silos, and enabling collaboration.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-05/new-leadership-code/code-process.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-05/new-leadership-code/code-process.png' class="img-fluid center" alt='Leadership code process' /></a></p>
<h2 id="the-code">The CODE</h2>
<p>Our CODE relies on 5 guiding principles:</p>
<ul>
<li>Be humble and stay curious</li>
<li>Level up the team</li>
<li>Communicate directly, and with anyone</li>
<li>Aim for the greater good</li>
<li>Make it happen</li>
</ul>
<p>Each principle is more than just a statement—it’s a call to action. When we set out to define these, we didn’t just want to say <em>what good leadership looks like</em>. We also felt it was equally important to clarify <em>what it doesn’t look like</em>.</p>
<p>This was intentional. In fast-moving environments like ours, ambiguity can lead to misalignment. So we wanted to provide more clarity, not in the form of rigid rules, but as <strong>guidance leaders can interpret thoughtfully for themselves</strong>. These are starting points, not the full story. We trust our leaders to bring their own judgment and experience to the table.</p>
<h3 id="be-humble-and-stay-curious">Be humble and stay curious</h3>
<p>Leadership means staying open—open to learning, to being wrong, and to hearing perspectives different from your own. It’s about listening thoughtfully, admitting when you don’t have all the answers, and being willing to adapt.</p>
<p>What it means:</p>
<ul>
<li>You actively listen and ask thoughtful questions.</li>
<li>You admit when you don’t know something and seek help.</li>
<li>You embrace change and adapt as you learn.</li>
</ul>
<p>What it doesn’t mean:</p>
<ul>
<li>Getting stuck in endless exploration without making progress.</li>
<li>Using curiosity as a shield to avoid decisions.</li>
<li>Blindly accepting others’ ideas without critical thinking.</li>
</ul>
<h3 id="level-up-the-team">Level up the team</h3>
<p>At Octopus, great leaders grow great people. It’s about empowering others, building their confidence, and setting them up to thrive. You lead by example, support experimentation, and share in the team’s success.</p>
<p>What it means:</p>
<ul>
<li>You care about your team’s growth—both personally and professionally.</li>
<li>You walk the talk by modeling the standards you expect from others.</li>
<li>You trust your team to own their work and support them in their endeavors.</li>
</ul>
<p>What it doesn’t mean:</p>
<ul>
<li>Micromanaging or stepping in unnecessarily.</li>
<li>Abandoning your team under the guise of trust.</li>
<li>Needing to have all the answers yourself.</li>
</ul>
<h3 id="communicate-directly-and-with-anyone">Communicate directly, and with anyone</h3>
<p>We believe communication is a leadership superpower. It’s not just about speaking clearly—it’s about creating space for honest dialogue, listening with intent, and maintaining transparency at every level.</p>
<p>What it means:</p>
<ul>
<li>You speak and listen openly, clearly, and respectfully.</li>
<li>You ask for and give honest feedback on a regular basis.</li>
<li>You’re transparent about challenges and work collaboratively to address them.</li>
</ul>
<p>What it doesn’t mean:</p>
<ul>
<li>Being harsh or blunt under the guise of honesty.</li>
<li>Using feedback to criticize instead of constructively build.</li>
<li>Tuning out opinions you disagree with.</li>
</ul>
<h3 id="aim-for-the-greater-good">Aim for the greater good</h3>
<p>Leadership isn’t about ego—it’s about making an impact that benefits everyone. We lead in service of our team, our customers, and our overall mission. Great leaders look beyond personal accolades and focus on the bigger picture.</p>
<p>What it means:</p>
<ul>
<li>You prioritize the collective success of the team and company over personal recognition.</li>
<li>You collaborate effectively toward shared goals.</li>
<li>You act with unwavering integrity at all times.</li>
</ul>
<p>What it doesn’t mean:</p>
<ul>
<li>Burning yourself out for the team.</li>
<li>Ignoring the value of personal wins.</li>
<li>Dismissing the importance of small progress—it all counts.</li>
</ul>
<h3 id="make-it-happen">Make it happen</h3>
<p>Leaders at Octopus drive real impact. We don’t just talk about ideas—we turn plans into action. Our approach is about taking ownership, making decisive choices, and moving with purpose to deliver results.</p>
<p>What it means:</p>
<ul>
<li>You own your outcomes and see your initiatives through to completion.</li>
<li>You make smart, timely decisions that align with our company goals.</li>
<li>You bring enthusiasm and focus to tackle challenges head-on.</li>
</ul>
<p>What it doesn’t mean:</p>
<ul>
<li>Rushing into decisions without a clear plan.</li>
<li>Taking on too much and risking burnout.</li>
<li>Engaging in busy work that lacks tangible impact.</li>
</ul>
<h2 id="whats-next">What’s next?</h2>
<p>Creating the CODE was only the beginning. We now have a lot of work to embed these principles into daily leadership practices. This includes:</p>
<ul>
<li>Mentor and provide feedback to the company leaders on following the CODE.</li>
<li>When assessing potential new leaders, understand if they can embrace the CODE and embody its principles.</li>
<li>Challenging ourselves as leaders by regularly reflecting on our actions and identifying ways to better support our people and the company.</li>
<li>Fostering a culture of accountability, where feedback is a two-way conversation and leaders at all levels strive to improve continuously.</li>
</ul>
<p>By making the CODE central to how we hire, develop, and assess leaders, we aim to build a leadership culture that supports our people and drives Octopus toward its long-term goals.</p>
<h2 id="reflections">Reflections</h2>
<p>This journey reinforced my belief that leadership is a collaborative effort. By defining and sharing our expectations, we set our leaders up for success and create a culture where everyone can thrive.</p>
<p>Whether you’re a leader yourself or aspire to become one, my advice is simple: take the time to define what leadership means to you personally. It’s one of the most impactful ways to ensure alignment, growth, and success.</p>
<p>If you’re curious to learn more about Octopus and how we’re building our future, stay tuned for more stories from our People team.</p>
<h2 id="watch-our-leadership-code-video">Watch our Leadership CODE video</h2>
<p>Watch our Leadership CODE video with Octopus's leaders, below. You'll also find a section on the <a href="https://handbook.octopus.com/getting-oriented/leadership-code" rel="nofollow">Leadership CODE in our public handbook</a>.</p>
<iframe width="560" height="315" src="https://www.youtube.com/embed/eZ4COGt5Gwk?si=1TDQyGyH0dE2TZ7y" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/what-gitops-changes-about-elevated-access</id>
<title type="text">What GitOps changes about elevated access</title>
<published>2025-05-26T14:00:00Z</published>
<updated>2025-05-26T02:25:26.6478411Z</updated>
<author>
<name>matthew.allford@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/what-gitops-changes-about-elevated-access" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-05/what-gitops-changes-about-elevated-access/blogimage-whatisgitops-2025.png" alt="Person holds magnifying glass over GitOps logo, surrounded by icons for declarative, versioned and immutable, pulled automatically, and continuously reconciled." /></p>
<p>Recently, we surveyed the industry to gain insights into the adoption and challenges of real-world GitOps, with the results forming the <a href="https://octopus.com/publications/state-of-gitops-report">State of GitOps report</a>. While reviewing the trends and results, the data around one key finding jumped out at me:</p>
<blockquote class="blockquote">
<p>GitOps reduces elevated access</p>
</blockquote>
<p>Overall, 66% of respondents agreed. Among organizations with higher GitOps maturity, agreement rose to 77%, but interestingly, there was also a slight increase in disagreement among the highest performers.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-05/what-gitops-changes-about-elevated-access/gitops-reduces-elevated-access.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-05/what-gitops-changes-about-elevated-access/gitops-reduces-elevated-access.png' class="img-fluid center" alt='Bar chart showing responses to ‘GitOps reduces elevated access’ across groups with different GitOps maturity scores.' /></a></p>
<p>So, does GitOps change or reduce the need for elevated environment access, and should it?</p>
<h2 id="how-gitops-shifts-access-away-from-infrastructure">How GitOps shifts access away from infrastructure</h2>
<p>The 4 GitOps principles encourage you to avoid manually logging into environments and performing tasks. The goal is to manage system state declaratively through version-controlled configuration and apply those states automatically using reconciliation agents.</p>
<p>If fully embraced, GitOps agents continuously observe the system state, correcting any drift by reapplying the desired state defined in version control. Continuous reconciliation discourages manual changes and automatically reverses them if they occur.</p>
<p>In traditional operations teams, access to systems with SSH or tools like kubectl is common, but operating in a mature GitOps model should make these break-glass exceptions.</p>
<p>Most survey respondents agree that GitOps should reduce the need for privileged production access by replacing hands-on changes with declarative, auditable workflows.</p>
<h2 id="rethinking-what-elevated-access-means-with-gitops">Rethinking what elevated access means with GitOps</h2>
<p>So why might some respondents to the survey disagree that embracing GitOps reduces elevated access?</p>
<p>At lower maturity levels, teams may treat Git as a safe, developer-focused system. But as Git becomes the source of truth for managing production infrastructure and applications, a key question emerges:</p>
<blockquote class="blockquote">
<p>If a developer can change a manifest in Git for a production environment, does that emulate elevated access?</p>
</blockquote>
<p>In a GitOps model, Git becomes the control plane, meaning write access to a production configuration in Git, especially with automatic reconciliation, becomes a form of production access.</p>
<p>High performers likely consider GitOps secure when configuring repositories well and implementing mature environment promotion workflows. However, Git isn't the only sensitive surface in GitOps architecture. You must also secure the reconciliation controller and supporting workflow or promotion tooling with the same level of rigor. Together, these systems form the modern delivery pipeline and deserve the same access scrutiny once reserved for direct infrastructure.</p>
<p>High performers likely aren't ignoring or rejecting GitOps' security benefits, but instead acknowledge that you must treat Git itself as a sensitive operational boundary now more than ever. It's now one of several critical control points in the delivery process that need strict governance.</p>
<p>Interestingly, these same high performers agreed that GitOps reduces overall elevated access. So, the takeaway isn't contradiction; it's maturity. High-performing teams see GitOps as secure only when Git, the reconciliation controller, and supporting environment progression tooling are all treated as critical access points, with the appropriate controls in place.</p>
<h2 id="handling-exceptions-to-the-gitops-model">Handling exceptions to the GitOps model</h2>
<p>In the early stages of adopting GitOps, it's common for DevOps engineers, platform engineers, and even developers to rely on familiar tools like <code>kubectl</code> to inspect or tweak clusters and applications directly. Especially in learning environments and environments early in the deployment process, like dev, this is precisely what they'll do. This approach lets them rely on familiar tools while gaining confidence in GitOps practices.</p>
<p>The ultimate goal is for nobody to have direct access to production environments, even if read-only.</p>
<p>In the <a href="https://octopus.com/publications/state-of-gitops-report">State of GitOps report</a>, we surfaced 6 core practices of GitOps:</p>
<ul>
<li>Declarative desired state</li>
<li>Human-readable format</li>
<li>Responsive code review</li>
<li>Version control</li>
<li>Automatic pull</li>
<li>Continuous reconciliation</li>
</ul>
<p>You won't embrace all of these GitOps practices on day one, and that's ok. As we learned from the DevOps movement, embracing a GitOps infrastructure and application delivery approach involves continuous improvement, learning, tweaking, and time.</p>
<p>With that said, even at high maturity levels with GitOps where you implement many or all of the practices, there may still be valid scenarios where folks need elevated access. For example, emergency responses (break-glass scenarios) or debugging complex or unreproducible issues.</p>
<p>In these cases, it's crucial to have:</p>
<ul>
<li>Break-glass procedures. Documented steps for requesting, granting, and revoking temporary access. These should include automated expiration, require multi-party approval, and be used only in exceptional circumstances.</li>
<li>Audit trails. You must log every access event, recording who accessed and changed what, when, and why.</li>
<li>Controlled suspension of reconciliation. Sometimes, you must temporarily disable the GitOps agent to prevent it from overwriting a manual change made during incident response. You should log and time-bound this suspension, and include procedures to reconcile safely afterward.</li>
<li>Post-incident recovery. After manual intervention, have a defined process for reconciling the system back to the desired state, committing required changes to Git, and re-enabling automatic reconciliation.</li>
</ul>
<p>These situations should be rare. Ideally, releases have already passed through multiple environments that closely mirror production in both infrastructure and configuration. If you experience an issue where you find your developers or engineers need to access environments directly, after the issue gets resolved, question why. Could they have achieved the same outcome by using other systems and tooling? Is there an element of education and training required? Is there a need to implement supplementary tooling or processes to help troubleshoot and resolve issues that surface after deployment? Work on fixing it, and implementing that fix in your process so it doesn't occur again.</p>
<p>Releasing to production shouldn't be a production.</p>
<h2 id="the-evolving-access-conversation">The evolving access conversation</h2>
<p>GitOps won't immediately eliminate the need for you to have a process for elevated production access, but it should help make it an exception rather than a routine operation. You must treat Git and GitOps tooling with the same care and control as production infrastructure. The fundamentals still apply; they apply in more places and different places than you're used to.</p>
<p>As you mature your GitOps adoption, the conversation shifts from &quot;do we still need access?&quot; to &quot;are we securing the new access surface and tooling?&quot;.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/design-journey-kubernetes-live-status</id>
<title type="text">The surprising design journey behind Kubernetes Live Object Status</title>
<published>2025-05-21T14:00:00Z</published>
<updated>2025-05-20T06:36:23.3548478Z</updated>
<author>
<name>kirsten.schwarzer@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/design-journey-kubernetes-live-status" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/img-blog-design-journey-kubernetes-live-status.png" alt="Stylized image of a designer thinking about the Kubernetes live status interface." /></p>
<p>For the past 2 years, we've been talking to customers about their biggest headaches when deploying to Kubernetes.</p>
<p>A recurring theme has been the challenge of knowing what’s actually happening with your applications at any given moment.</p>
<p>With Kubernetes, things can change unexpectedly. A Pod might go down, your cluster could run out of resources, or something might break even though your deployment was successful. When this happens, our users would need to look for information in other tools or use commands like <code>kubectl logs</code> to diagnose what went wrong.</p>
<p>But most developers aren't Kubernetes experts and don't feel confident using <code>kubectl</code>. They often have to wait for a platform team with specialized Kubernetes knowledge, leading to frustrating delays. Platform teams can get stuck in firefighting mode and lose valuable time for more strategic projects.</p>
<p>With these challenges in mind, we aimed to create a tool for developers to troubleshoot their Kubernetes applications.</p>
<p>Here’s how we designed Kubernetes Live Object Status and how a few unexpected discoveries shaped our choices.</p>
<h2 id="integrating-versus-separating-live-status">Integrating versus separating live status</h2>
<p>The first big choice was whether to create separate dashboards for live status or integrate it into our existing dashboards. We used low-fidelity wireframes to explore both options and get early feedback from Octopus leaders.</p>
<p>Ultimately, we didn't want to create a separate space for Kubernetes. Our users often have many different applications they want to see on a single screen.</p>
<p>We decided to let you toggle between live and deployment status on your main Octopus dashboard. To improve usability, your preference gets saved in the browser for your next visit.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-status-main-dashboard.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-status-main-dashboard.png' class="img-fluid center" alt='Octopus main dashboard' /></a></p>
<p>Integrating live status into existing dashboards lets us extend it to other types of applications in future. While that's not currently on our roadmap, we'd love to hear if it’s something you'd find useful.</p>
<h2 id="using-established-status-indicators">Using established status indicators</h2>
<p>Instead of creating new status indicators, we started with existing statuses from Argo CD, a popular open-source Kubernetes tool. We knew that we had an upcoming project to integrate with Argo CD and leveraging its statuses would let us integrate more seamlessly.</p>
<p>However, we had to make a few modifications to fit the Octopus model. Our team added extra statuses for applications because Octopus deployments determine the Kubernetes desired state. After a successful deployment, we compare the desired state with the live status to determine if an application is out of sync.</p>
<p>We also decided to combine the Argo CD sync and health status to simplify it for users.</p>
<p>We ended up with 2 sets of live statuses, one for applications and one for Kubernetes objects.</p>
<h2 id="evolving-with-user-feedback">Evolving with user feedback</h2>
<p>During the first few weeks of EAP, we encountered an issue where customers saw out-of-sync more often than they expected. It turns out that resources can regularly be out of sync for reasons that aren't actually important.</p>
<p>We quickly realised that we needed to separate sync status from health status instead of combining them.</p>
<p>Our first instinct was to simplify the experience, but that's the reality of building real software—once it's out in the wild and customers start using it, you realize there's complexity for a reason.</p>
<p>Our team did a quick pivot to separate health status from sync status for both applications and objects.</p>
<p>You can <a href="https://octopus.com/docs/kubernetes/live-object-status#application-status">read our documentation</a> to explore the updated status model.</p>
<p>We also introduced a setting that prioritizes health status on the dashboards as a default. We’re planning extra work in this space to give users more granular control and better visibility of both statuses.</p>
<p>This surprising lesson is a great example of why we try to ship early and get customer feedback as soon as possible. It’s something you can’t easily test or replicate with a prototype and a usability study.</p>
<h2 id="adding-a-new-live-status-page">Adding a new live status page</h2>
<p>In addition to the dashboards, we created a dedicated live status page for each project, environment, and tenant combination. This gives you an easily shareable link for a specific application that you can bookmark or share with your team.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-status-sync-health-status.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-status-sync-health-status.png' class="img-fluid center" alt='Live status page with sync and health status' /></a></p>
<h2 id="choosing-the-object-visualization">Choosing the object visualization</h2>
<p>We considered multiple ways to visualize your Kubernetes objects and key information about them.</p>
<p>Some tools use flow-style diagrams to show the hierarchy and relationships between objects. But this approach, while visually appealing in demos, can get very messy and hard to read at scale. It was important to consider what this would look like with hundreds or even thousands of objects.</p>
<p>That's why we opted for a tree grid, which gives us the best of both worlds. It lets us show information with high density, so even if you have many objects, it's still easy to scan. You can also use the advanced filters panel to reduce the list to objects with specific states and kinds. And it still shows the relationship between objects through hierarchical expanders.</p>
<h2 id="diagnosing-object-issues">Diagnosing object issues</h2>
<p>The key to creating a single place to troubleshoot is to provide enough information to find the cause without needing to switch between tools.</p>
<p>During a usability study for this feature, we asked users to troubleshoot an application, starting from the main dashboard. Those were the only instructions they received.</p>
<p>Users immediately navigated to the live status page and looked for events and logs without any extra prompting. This was surprising to a few of us, but not to our team’s Senior Cloud Engineer, who had spent years debugging Kubernetes issues himself.</p>
<p>The usability study made us realize that events and logs were key capabilities we needed to deliver on this feature's promise.</p>
<p>When viewing the live status page, you can now click on an object’s name to get more details. This action opens a drawer with 4 tabs:</p>
<ul>
<li>Summary</li>
<li>Events</li>
<li>Logs</li>
<li>Manifest</li>
</ul>
<h2 id="interacting-with-kubernetes-logs-and-events">Interacting with Kubernetes logs and events</h2>
<p>Kubernetes events can be quite verbose, so we wanted to make it easy to find the issue you're looking for. It was important to add filters based on the type of event, especially if you're only looking for warnings.</p>
<p>The event row shows a snippet of the message to make it easily scannable. But we also have an expandable element that lets you read the full message and see the first and last seen dates.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-kubernetes-events.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-kubernetes-events.png' class="img-fluid center" alt='Kubernetes events drawer' /></a></p>
<p>The engineers on our team felt strongly that it was important to deliver a great experience interacting with logs. We added a few nice touches, like highlighting a row when you hover over it and including toggles for:</p>
<ul>
<li>Showing the previous container</li>
<li>Timestamp visibility</li>
<li>Line wrapping</li>
</ul>
<p>We opted to keep things simple for refresh behaviour and give users more granular control.</p>
<p>Because the logs are live, we didn't want things to move and scroll while you were looking at them. We decided to provide a refresh button you can use to update the logs without unexpected behaviour.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-kubernetes-logs.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-kubernetes-logs.png' class="img-fluid center" alt='Kubernetes logs drawer' /></a></p>
<p>A small but significant design choice, championed by the engineers on our team, was using a monospace font. This differentiates the actual machine output from the rest of the Octopus interface.</p>
<p>We wanted users to know that this was the raw output from their cluster and that they could trust it.</p>
<h2 id="inspecting-and-comparing-manifests">Inspecting and comparing manifests</h2>
<p>On the Manifest tab, you can see the YAML currently running in your cluster and compare it to your last deployment.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-manifest-diff.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/live-manifest-diff.png' class="img-fluid center" alt='Kubernetes live manifest diff' /></a></p>
<p>You’ll notice the diff view looks quite similar to other developer tools you've used before. That's on purpose.</p>
<p>The fourth heuristic of <a href="https://www.nngroup.com/articles/consistency-and-standards/" rel="nofollow">Jakob Nielsen’s ten usability heuristics</a> is to maintain consistency and adhere to standards. We worked from the assumption that our users spend more time in other tools than they spend using Octopus.</p>
<p>This means there are conventions from other tools that our users have already gotten used to. Instead of making you learn a new way to do things, we tried to incorporate existing patterns from popular tools you interact with daily.</p>
<p>That's exactly what we did with the design for diffs.</p>
<h2 id="a-surprisingly-useful-addition-the-deployment-timeline">A surprisingly useful addition: The deployment timeline</h2>
<p>We originally created the deployment timeline to simplify navigation between Octopus deployments and the live status page.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/deployment-timeline.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-05/design-journey-kubernetes-live-status/deployment-timeline.png' class="img-fluid center" alt='Deployment timeline' /></a></p>
<p>After sharing a mockup in our internal Slack, Paul Stovell, our CEO, commented that we should add a redeploy button to it. That would let you quickly roll back to a previous successful release if you see an issue with the live status. That’s how we (accidentally) designed a feature that helps close the loop from diagnosing an issue to actually fixing it.</p>
<p>This project had many interesting twists and turns, but my favorite has to be the surprising usefulness of the deployment timeline.</p>
<p>Being able to diagnose an issue is helpful, but redeploying and seeing your application running again takes it a step further. Empowering developers to fix their own apps is exactly why we built Kubernetes Live Object Status.</p>
<h2 id="conclusion">Conclusion</h2>
<p>I hope this post has given you a fun behind-the-scenes look at how we design new features at Octopus.</p>
<p>We talk to customers, try out different solutions, test them, and release small iterations so we can get feedback quickly.</p>
<p>Sometimes, we learn unexpected lessons when our features get used in the real world, and sometimes, serendipity leads to a great idea.</p>
<h3 id="how-to-get-kubernetes-live-object-status">How to get Kubernetes live object status</h3>
<p>If you’ve used the feature and have feedback to share, please send us a message in the #kubernetes channel in our <a href="https://oc.to/CommunitySlack" rel="nofollow">Community Slack</a>. We’d love to hear from you.</p>
<p>If you haven't tried it out yet, you can install the latest version of the Kubernetes agent. It includes the Octopus Kubernetes monitor, which gets live status from the cluster.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/automatic-rollbacks-last-resort</id>
<title type="text">Automatic rollbacks are a last resort</title>
<published>2025-05-15T14:00:00Z</published>
<updated>2025-05-15T08:29:01.8123494Z</updated>
<author>
<name>steve.fenton@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/automatic-rollbacks-last-resort" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-05/automatic-rollbacks-last-resort/blogimage-modernrollbackstratgies-2023.png" alt="4 release boxes labelled 1.1 to 1.4, the 3rd with a green tick, 4th on fire with a red cross. A rocket travels back from 1.4 to 1.3." /></p>
<p>People often say they want the ability to roll back software automatically when something goes wrong. This sounds simple enough, but there aren't many scenarios where an automatic rollback is desirable.</p>
<p>Many causes of deployment failures will also prevent a rollback. For example, if a credential has expired preventing part of the deployment, this will also fail during the rollback process. Someone may also need to make decisions based on what operations succeeded before the deployment stopped, like changes to database state.</p>
<p>There are 3 insights from modern software delivery that all contribute to the fall from grace of automatic rollbacks:</p>
<ul>
<li>We have a better understanding of resilience in our sociotechnical systems</li>
<li>Continuous Delivery makes it easier to roll forward</li>
<li>Progressive delivery provides better mechanisms</li>
</ul>
<h2 id="the-role-of-resilience">The role of resilience</h2>
<p>One of the crucial ideas from the Lean movement is that automation is improved if there are mechanisms to halt operation and ask for human intervention, instead of continuing automatic operation. This was termed <em>autonomation</em>, or automation with a human touch.</p>
<p>Although automatic rollbacks sound like something that would make your software more reliable, this is a situation where resilience is needed. Resilience is something humans excel in.</p>
<p>To put it another way, you can plan-in a certain level of robustness to your deployment process. For example, you could test credentials before starting the deployment. Each time you discover a new kind of failure, you can learn from it and improve how it's handled. For all the things you haven't thought of, resilience is required.</p>
<p>Human-driven resilience provides the crucial knowledge needed to improve robustness. Organizations that flag the problem to a human end up with an appropriate resolution to the issue at hand, and knowledge of how to make the system more robust. Automatically rolling back removes this opportunity to learn, as conditions for observing the problem may have been lost.</p>
<h2 id="continuous-delivery-fewer-bugs-and-faster-recovery">Continuous Delivery: Fewer bugs and faster recovery</h2>
<p>If rollbacks are a priority in your organization, it's likely a signal that you're missing crucial technical practices. Working in small batches is made possible by frequently committing changes to the main branch so they can be automatically validated. This increases confidence that the new software version is deployable.</p>
<p>The longer you practice Continuous Delivery, the more robust your deployment pipeline becomes. Additionally, if something does slip through, you can quickly roll forward to a new software version that has a fix (and some new tests that stop it from happening again). This is very different from using an expedited process for an urgent fix. Continuous Delivery lets you use the standard process for all changes, because it's already swift.</p>
<p>Most bugs you encounter in a Continuous Delivery process aren't critical. There may be an edge case you missed, some scenario that you might not decide to support, or cosmetic issues. Normal feedback cycles can handle these. When a change is more urgent, you can still resolve it by deploying a new software version.</p>
<p>Continuous Delivery progresses the same build artifact through each environment, and it includes validation steps to make sure the software works to the extent you have defined tests. The deployment process itself is being tested at least as often as the software, because you're using the same automated process to deploy to pre-production environments.</p>
<p>This means the kind of problems you encounter will be transient issues or unexpected events. Let's get those to an expert.</p>
<h2 id="progressive-delivery-provides-better-strategies">Progressive delivery provides better strategies</h2>
<p>Progressive delivery techniques include deployment strategies, like blue/green and canary deployments, and feature flags.</p>
<p>Deployment strategies include mechanisms to verify the software. Blue/green deployments provide a failback option, and canary deployments let you pause the rollout to limit the impact of an issue. Feature flags take this a step further by providing a runtime mechanism to switch features on and off, or swap feature implementations.</p>
<h2 id="the-last-resort">The last resort</h2>
<p>Rollbacks don't always return you to a previous system state. They can return you to a state you've never tested or operated before. The software version may have been tested, but not with your current database or other dependencies. What other software has moved forward that may no longer be compatible with the previous version?</p>
<p>Redeploying a previous software version should be a last resort, and it ought to have human supervision as there may be many other knock-on effects of moving in reverse. You may fix a bug only to re-open a security vulnerability, or revert to a software version that isn't compatible with the current database schema or some crucial API.</p>
<p>When you use modern software engineering practices like Continuous Delivery, modern deployment strategies, and feature flags, the appeal of automatic rollbacks is greatly diminished. Bringing human resilience to play results in the creation of increasingly robust systems for testing, deployment, and operation of software.</p>
<p>You can read more about this in the white paper, <a href="https://octopus.com/whitepapers/modern-deployment-and-rollback-strategies">Modern deployment and rollback strategies</a> by Bob Walker. It provides advice on the architectural patterns that support better deployments, the trade-offs of different approaches, and how to select the right approach.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/financial-industry-compliance</id>
<title type="text">Financial industry compliance, the DevOps way</title>
<published>2025-04-30T14:00:00Z</published>
<updated>2025-05-02T07:19:31.6340815Z</updated>
<author>
<name>steve.fenton@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/financial-industry-compliance" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-04/financial-industry-compliance/blog-img-fsi-2025-1500x800.png" alt="Building with three pillars and dollar symbol surrounded by icons that represent security and compliance." /></p>
<p>If you work in the financial industry, you know there can sometimes be a high burden of regulation. This is understandable when you consider the risk of financial loss and how it can impact people's lives. But if you don't take the right approach to compliance, it can become a time and energy leak that threatens your ability to compete in the market.</p>
<p>The best compliance teams look for ways to protect the organization and its customers from risk without overburdening teams with bureaucratic procedures. You want compliance set to maximum, and the ability to deliver high-quality, valuable software set to maximum. You don't want some compromise between the two.</p>
<h2 id="good-compliance-sounds-like-devops">Good compliance sounds like DevOps</h2>
<p>If you know DevOps, this will sound familiar. Traditional managers saw software delivery as a compromise between throughput (creating and improving software features) and stability (keeping everything working). They measured developers on throughput and ops teams on stability, then wondered why there was so much conflict between them.</p>
<p>Just as the solution to the software delivery problem was to align both teams to the shared goal of throughput and stability, you must do the same with other desirable system qualities, like security and compliance.</p>
<p>Rather than calling this DevSecOps or DevSecCompOps, we can call it DevOps because everything that relates to software fitness is part of DevOps.</p>
<p>The non-DevOps way is for stability to be an afterthought and compliance to be an ominous late reaction to an upcoming audit. The DevOps way is to make these part of the daily work, automate as much as possible, and deliver the outcome of compliance instead of the frantic output of audit theater.</p>
<p>It's about being safe and secure, not looking safe and secure.</p>
<h2 id="compliance-automation">Compliance automation</h2>
<p>You can approach compliance by copying what other organizations are doing. Most organizations have a spreadsheet with obliquely referenced requirements that developers are regularly asked to update and evidence. Who doesn't love an ORG-05.15-ACCESS-CONTROL line item in a spreadsheet?</p>
<p>However, the best compliance teams I've worked with took a different approach. They spent more time educating developers like me about the reasons for these requirements so we could find ways to satisfy them, collect evidence, and keep customers safe.</p>
<p>This meant we considered compliance needs when writing features, selecting tools, or changing our process. When we looked at tools for builds, deployments, and monitoring, ease of meeting compliance needs and automation of evidence collection were part of the buying decision.</p>
<p>This isn't just about making audits easy; it's about making compliance easy, and it's about making the desired outcomes of compliance more likely. Your toolchain can do much of the heavy lifting, leaving you to show and tell during an audit while listening out for opportunities to make things even better.</p>
<h2 id="how-octopus-supports-easy-compliance">How Octopus supports easy compliance</h2>
<p>Octopus has many features that ease your compliance burden and increase safety, from enterprise-grade access controls and audit trails to innovative automation. Let's take a quick tour of some crucial compliance features:</p>
<ul>
<li>Role-based access control</li>
<li>Extensive audit trails</li>
<li>IT service management integrations</li>
<li>Octolint</li>
<li>Runbooks</li>
</ul>
<h3 id="role-based-access-control">Role-based access control</h3>
<p>Octopus Deploy has fine-grained role-based access controls (RBAC) that integrate with single sign-on (SSO) providers. You can define roles and permissions to control who can change deployment processes, runbooks, and other configurations. You can also define who can access the automation for different projects and environments.</p>
<p>You can use RBAC to prevent unauthorized changes and enforce segregation of duties. You can also safely create self-service actions, like letting testers deploy to the test environment or clear a web cache to speed up their testing without giving them more extensive permissions.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/financial-industry-compliance/role-based-access.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/financial-industry-compliance/role-based-access.png' class="img-fluid center" alt='A list of built-in user roles.' /></a></p>
<h3 id="extensive-audit-trail">Extensive audit trail</h3>
<p>Octopus automatically captures a detailed audit log for all significant system events. This includes deployments, configuration changes, user access events, and more. Octopus records every action that changes a state, including who initiated it.</p>
<p>These tamper-resistant audit logs let you demonstrate the changes made to applications or infrastructure. When you need to delve into the audit trail, it's easy to filter actions by user or by a specific area in Octopus, like spaces, projects, environments, event types, and more.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/financial-industry-compliance/audit-trail.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/financial-industry-compliance/audit-trail.png' class="img-fluid center" alt='The audit trail screen shows recent changes, deployments, and runbook runs and has filters to easily find what you need.' /></a></p>
<h3 id="it-service-management-integrations">IT service management integrations</h3>
<p>Our integrations with ServiceNow and Jira Service Management remove manual hand-offs between Octopus and your IT service management (ITSM) platform. This makes it easy to ensure changes have the appropriate approval before progressing.</p>
<p>The integrations automatically create change requests associated with a deployment. You can block deployments until the change gets approved. This increases compliance, as no unapproved changes get deployed to production—but it does so without creating toil for the developers.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/financial-industry-compliance/approval-flow.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/financial-industry-compliance/approval-flow.png' class="img-fluid center" alt='When a protected environment is selected, the integration with ITSM tools is triggered and a change approval is created and linked. The deployment continues when the change is approved in the ITSM tool.' /></a></p>
<h3 id="octolint">Octolint</h3>
<p>Octolint is a tool that scans your Octopus instance and recommends improvements to your setup. It detects potential issues such as perpetual API keys, shared Git user names, and unused deployment targets.</p>
<p>Instead of manually auditing for good practices, Octolint can automatically scan and report on items that need your attention.</p>
<pre><code class="language-text">[OctoLintDefaultProjectGroupChildCount] The default project group contains 79 projects. You may want to organize these projects into additional project groups.
[OctoLintEmptyProject] The following projects have no runbooks and no deployment process: Azure Octopus test
[OctoLintTooManySteps] The following projects have 20 or more steps: K8s Yaml Import 2
</code></pre>
<h3 id="runbooks">Runbooks</h3>
<p>Financial institutions need good plans for both daily operations and emergencies. Octopus Runbooks help with this. You can turn routine and emergency operations tasks into reusable automations for things like:</p>
<ul>
<li>Database maintenance</li>
<li>Restarting systems</li>
<li>Applying urgent fixes</li>
<li>Recovering backed-up data</li>
</ul>
<p>Automated runbooks are safer and more reliable, reducing the need for broad distribution of elevated access. Runbooks in Octopus also log changes and runs to the standard Octopus audit trail. You can also use runbooks to automate compliance tasks like recovery testing, audit reporting, or probing firewall ports.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/financial-industry-compliance/operations-overview.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/financial-industry-compliance/operations-overview.png' class="img-fluid center" alt='A list of runbooks that have been triggered and whether they succeeded.' /></a></p>
<h2 id="octopus-loves-compliance">Octopus loves compliance</h2>
<p>Octopus has many features that reduce the compliance burden and help you build security, privacy, and compliance into your DevOps process. As an organization, Octopus also maintains compliance with ISO 27001:2013, SOC 2 Type II, and SOC 3 with regular third-party audits and technical assessments for security, safety, and privacy. You can find out more about this in our <a href="https://trust.octopus.com/" rel="nofollow">trust center</a>.</p>
<p>Tools that reduce the compliance burden are crucial to organizations in the financial industry or other regulated and safety-critical environments. Your toolchain can help maintain innovation and compliance just like it brings you throughput and stability.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/oidc-external-feeds</id>
<title type="text">OpenID Connect authentication for external feeds</title>
<published>2025-04-28T14:00:00Z</published>
<updated>2025-04-28T05:57:04.6523446Z</updated>
<author>
<name>grace.rehn@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/oidc-external-feeds" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-04/oidc-external-feeds/generic-oidc-banner-img.png" alt="Keys on a keychain above a recycling bin." /></p>
<p>We recently updated our external feeds to support OpenID Connect (OIDC) authentication.</p>
<p>Octopus can now use OAuth 2.0 to access your container feeds. This means you won’t have to manage or rotate credentials manually. This includes OIDC support for AWS, Azure, and Google Container Registries (GCR).</p>
<p>This is especially beneficial for AWS Elastic Container Registries (ECR), where authentication tokens expire after 12 hours. OIDC eliminates the need for stored access keys by generating fresh credentials at deployment time.</p>
<p>This feature is now available for our Cloud customers and will be available to our self-hosted customers in June in Octopus 2025.2.</p>
<p>In this post, I explain how OIDC external feeds work and how to set them up for each provider.</p>
<h2 id="why-use-oidc-external-feeds-in-octopus">Why use OIDC external feeds in Octopus?</h2>
<p>Using OIDC with external feeds removes the need to store and rotate credentials. During deployment, Octopus requests short-lived credentials to authenticate with your container registry. This improves security and simplifies credential management.</p>
<p>You can also customize the OIDC subject to include the space and feed. This helps enforce access control by ensuring tokens issued by Octopus are only valid for the intended feed and space. Here's an example subject claim: <code>space:default:feed:feed-name</code>.</p>
<p>For more information on generating subjects and OAuth flows, check out our <a href="https://octopus.com/docs/infrastructure/accounts/openid-connect">OpenID Connect docs</a>.</p>
<h2 id="aws-elastic-container-registry-ecr">AWS Elastic Container Registry (ECR)</h2>
<p>You can now select OpenID Connect as an authentication method when setting up an AWS ECR feed in Octopus. This is a great fit if you want to avoid managing access keys and use short-lived credentials instead.</p>
<p>To get started, create an IAM role with a trust policy that allows <code>sts:AssumeRoleWithWebIdentity</code>. When configuring your OIDC external feed, you need to provide the Role ARN and Audience. Octopus uses these values to request temporary ECR credentials at deployment time.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/oidc-external-feeds/aws-ecr-oidc-details.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/oidc-external-feeds/aws-ecr-oidc-details.png' class="img-fluid center" height="auto" width="500" alt='Screenshot of the AWS ECR OIDC Credentials form fields.' /></a></p>
<p>If you're new to this setup, take a look at our <a href="https://octopus.com/docs/packaging-applications/package-repositories/guides/container-registries/amazon-ec2-container-services#adding-an-aws-openid-connect-ecr-external-feed">AWS Elastic Container Registry docs</a>.</p>
<h2 id="azure-container-registry-acr">Azure Container Registry (ACR)</h2>
<p>OIDC is now supported for authentication with Azure Container Registry in Octopus. This removes the need for client secrets by using federated credentials instead.</p>
<p>To set it up, create an app registration in Azure and add a federated credential. To configure your feed in Octopus, make sure to add the Client ID, Tenant ID, and Audience from your identity provider. Octopus uses these to request a token from Azure. This ensures it can securely authenticate with your container registry.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/oidc-external-feeds/azure-oidc-details.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/oidc-external-feeds/azure-oidc-details.png' class="img-fluid center" height="auto" width="500" alt='Screenshot of the ACR OIDC Credentials form fields.' /></a></p>
<p>For full setup instructions, check out our <a href="https://octopus.com/docs/packaging-applications/package-repositories/guides/container-registries/azure-container-services#adding-an-azure-container-registry-with-openid-connect-as-an-octopus-external-feed">Azure Container Registry docs</a>.</p>
<h2 id="google-container-registry-gcr">Google Container Registry (GCR)</h2>
<p>Octopus now supports OIDC authentication for Google Container Registry via Workload Identity Federation. This means you no longer need to manage service account keys.</p>
<p>Start by configuring a Workload Identity Pool and an OIDC provider in Google Cloud. Then, create a trust configuration. This links the subject and audience from Octopus to a Google service account. In Octopus, set up a GCR external feed and provide the Audience and the registry URL. Octopus uses these to exchange its token for temporary credentials during deployment.</p>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/oidc-external-feeds/google-oidc-details.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/oidc-external-feeds/google-oidc-details.png' class="img-fluid center" height="auto" width="500" alt='Screenshot of the GCR OIDC Credentials form fields.' /></a></p>
<p>For more guidance, see our <a href="https://octopus.com/docs/packaging-applications/package-repositories/guides/container-registries/google-container-registry#adding-an-openid-connect-google-container-registry-to-octopus">Google Container Registry docs</a>.</p>
<h2 id="conclusion">Conclusion</h2>
<p>OIDC external feeds bring security and flexibility to your deployments by removing the need for static credentials. This method is consistent with modern cloud practices and gives you more control over your feeds. With support for AWS, Azure, and Google registries, Octopus makes it easy to integrate secure, token-based authentication into your pipelines.</p>
<p>We hope you give it a try, and let us know what you think. If you have any questions or feedback, we’d love to hear from you in the comments below.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/kubernetes-live-object-status</id>
<title type="text">Introducing Kubernetes Live Object Status</title>
<published>2025-04-16T14:00:00Z</published>
<updated>2025-04-16T08:32:15.1625697Z</updated>
<author>
<name>nick.josevski@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/kubernetes-live-object-status" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-04/kubernetes-live-object-status/kubernetes-live-object-status-2024-1500x800.png" alt="Stylized image of Kubernetes Live Object status in the Octopus UI showing a healthy status." /></p>
<p>Kubernetes is rapidly becoming the dominant platform for hosting and running applications.</p>
<p>At Octopus, we want to provide the best experience for deploying and monitoring your applications on Kubernetes.</p>
<p>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.</p>
<p>Kubernetes Live Object Stataus—our Kubernetes monitor—is the next major expansion of this deployment agent's capabilities.</p>
<h2 id="post-deployment-monitoring">Post-deployment monitoring</h2>
<p>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.</p>
<p>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.</p>
<p>We roll up the combined status for the objects in a given release, per environment, into a single live status.</p>
<p><figure><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/kubernetes-live-object-status/klos-project-view.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/kubernetes-live-object-status/klos-project-view.png' class="img-fluid" height="auto" width="500" alt='Project view with live status' /></a><figcaption>Project view with live status</figcaption></figure></p>
<h2 id="if-youre-already-using-the-kubernetes-agent">If you're already using the Kubernetes agent</h2>
<p>If you already use the Kubernetes agent, your upgrade path will be simple.</p>
<h3 id="upgrading-your-agents-to-the-version-containing-the-monitor">Upgrading your agents to the version containing the monitor</h3>
<p>We're working on a one-click upgrade process you can access in Octopus Deploy.</p>
<p>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>.</p>
<h2 id="new-to-using-octopus-for-kubernetes-deployments">New to using Octopus for Kubernetes deployments?</h2>
<p>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.</p>
<h3 id="installing-the-agent">Installing the agent</h3>
<p>The Kubernetes agent gets packaged and installed via a Helm chart. This makes managing the agent very simple and makes automated installation easy.</p>
<p>The Kubernetes monitoring component comes along for the ride. <a href="https://octopus.com/docs/kubernetes/live-object-status/installation#upgrading-an-existing-kubernetes-agent">See our docs for detailed instructions</a>.</p>
<p><figure><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/kubernetes-live-object-status/kubernetes-agent-wizard-config.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/kubernetes-live-object-status/kubernetes-agent-wizard-config.png' class="img-fluid" height="auto" width="500" alt='Kubernetes agent wizard configuration options' /></a><figcaption>Kubernetes agent configuration options</figcaption></figure></p>
<h2 id="new-to-octopus-deploy-entirely">New to Octopus Deploy entirely?</h2>
<p>How exciting! Welcome to scalable, simple, and safe Kubernetes CD with Octopus.</p>
<p>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.</p>
<p>We empower your teams to spend less time managing and troubleshooting Kubernetes deployments and more time shipping new features to improve your software.</p>
<p>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.</p>
<p>If you’re interested in trying it out, sign up for a <a href="https://octopus.com/start">free 30-day trial</a>.</p>
<h3 id="getting-started-with-the-agent-and-monitor">Getting started with the agent and monitor</h3>
<p>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.</p>
<p>Like the Octopus Tentacle, the Kubernetes agent is a small, lightweight application that's installed into the target Kubernetes cluster.</p>
<p>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>.</p>
<h3 id="when-can-i-use-it">When can I use it?</h3>
<p>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.</p>
<p>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>.</p>
<p><figure><a href='#' data-featherlight='https://i.octopus.com/blog/2025-04/kubernetes-live-object-status/kubernetes-agent-wizard-config.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-04/kubernetes-live-object-status/kubernetes-agent-wizard-config.png' class="img-fluid" height="auto" width="500" alt='Kubernetes agent as deployment targets' /></a><figcaption>Kubernetes agent as deployment targets</figcaption></figure></p>
<h2 id="how-we-built-kubernetes-live-object-status">How we built Kubernetes Live Object Status</h2>
<p>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.</p>
<p>The cluster-based monitoring capability uses two values to identify the incoming request:</p>
<ul>
<li>The client certificate thumbprint</li>
<li>An installation ID in the request headers</li>
</ul>
<p>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.</p>
<p>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/" rel="nofollow">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.</p>
<p>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.</p>
<p>As we also run Octopus Deploy in Kubernetes for our self-hosted 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" rel="nofollow">how we use Kubernetes for Octopus Cloud</a>.</p>
<h3 id="written-in-go">Written in Go</h3>
<p>This is the first large-scale feature our team has built in <a href="https://go.dev/" rel="nofollow">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.</p>
<p>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.</p>
<p>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.</p>
<h2 id="whats-coming-next">What's coming next</h2>
<p>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>. </p>
<ul>
<li>Terraform-based setup</li>
<li>Support Kubernetes API targets</li>
<li>Self-hosting (this feature is only available on Octopus Cloud)</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>
<p>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.</p>
<h2 id="let-us-know-your-thoughts">Let us know your thoughts</h2>
<p>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.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/measuring-cd-and-devops-measurement-types</id>
<title type="text">The 3 measurement types from Measuring Continuous Delivery and DevOps</title>
<published>2025-04-02T14:00:00Z</published>
<updated>2025-03-31T06:59:49.1639323Z</updated>
<author>
<name>steve.fenton@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/measuring-cd-and-devops-measurement-types" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-04/measuring-cd-and-devops-measurement-types/blog-generic-statistics-metrics-v2-2025-750x400-x2.jpg" alt="Person standing in front of floating rectangles that contain different metrics." /></p>
<p>Your continuous improvement process sits neatly between a system of measurements. You can use metrics to generate focus areas where you need to improve and use the metrics again to track your progress.</p>
<p>The perfect metrics would be real-world organization outcomes that update in real time as you try adjustments. The reality is that perfect metrics don't exist. The outcomes that are crucial to your organization tend to move slowly and imperceptibly in response to an improvement. Moving from monthly to weekly deployments won't immediately bring a rush of new customers, but delivering small batches regularly does help improve outcomes like this in the long run.</p>
<p>In the absence of perfect metrics, we can still create a helpful measurement system by finding small responsive numbers that predict changes for the big-ticket items. Industry research can help us with this, as many relationships have been found between software delivery and organizational success.</p>
<p>Our white paper, <a href="https://octopus.com/whitepapers/measuring-continuous-delivery-and-devops">Measuring Continuous Delivery and DevOps</a>, examines metric design and provides ways to power continuous improvement with numbers and techniques like statement-based assessments.</p>
<p>This post summarizes 3 types of measurement from the white paper:</p>
<ol>
<li>Leading versus lagging indicators</li>
<li>Instrumented versus perceptual data</li>
<li>System versus survey data</li>
</ol>
<h2 id="leading-versus-lagging-indicators">1. Leading versus lagging indicators</h2>
<p>Leading indicators help you predict future performance. You can use their early signals to predict changes in performance and take action to adjust the future outcome.</p>
<p>Lagging indicators tell you what happened in the past, but rather than being predictive, they're typically factual.</p>
<p>When you monitor a software system, leading indicators help you take action before a system becomes unavailable. For example, tracking CPU use lets us see when a feature uses too many resources and puts other features at risk. This lets you scale your resources or switch off the feature before the problem affects customers.</p>
<p>If you wait for a lagging indicator, like screen loading times, your users will notice the problem before you do. That doesn't mean you shouldn't measure lagging indicators, as these show the <em>system's real performance</em>. Leading indicators can alert you to a potential problem earlier, but they may change for reasons you don't expect.</p>
<p>This explains the importance of using leading and lagging indicators to measure software delivery capability. The leading indicators help you react earlier, but the lagging indicators tell you the actual state of the whole value stream.</p>
<p>The most important measurements to your organization are likely to be lagging indicators. For example, your organization cares about <em>revenue</em>. This measurement tells you about money that has (or hasn't) come into the business. A predictive indicator, like net promoter score (NPS), can help you spot problems that might affect future revenue, but the money that turns up is a cold, hard fact.</p>
<p>Leading indicators are often imperfect. We accept this because we value the ability to take action sooner. You should combine leading and lagging indicators to measure Continuous Delivery, DevOps, and software delivery performance.</p>
<h2 id="instrumented-versus-perceptual-data">2. Instrumented versus perceptual data</h2>
<p>Instrumented data is a measurement you can collect automatically, like temperature. Perceptual data covers the human experience, like if the temperature is comfortable for you.<br />
Instrumented data is popular because it's easy to get. However, perceptual data can capture complex relationships across many factors.</p>
<p>When you ask someone if a room temperature is comfortable, their answer goes beyond measurable temperature. The answer could include factors like:</p>
<ul>
<li>Humidity</li>
<li>Outdoor conditions</li>
<li>Their activity</li>
<li>Clothing</li>
<li>Personal preference</li>
</ul>
<p>If you ask employees if they feel energized or burned out, they report feeling burned out before their productivity drops.</p>
<p>Most organizations are good at collecting instrumented data. You should become just as good at collecting perceptual data as it often provides uniquely nuanced insights.</p>
<h2 id="system-versus-survey-data">3. System versus survey data</h2>
<p>If a team uses an internal tracking tool for features and a customer-facing tool to capture bugs, for example, you must collect data from both systems. If you only collect metrics from the internal tracking system, this work will get prioritized and optimized at the cost of customer-reported issues.</p>
<p>You must also ensure teams use tools as expected. In factories with time clocks, it was common for the first worker to clock their colleagues in to stop them from getting in trouble. According to the clock, worked hours would be far more than the actual hours, and any decisions based on this data were likely wrong.</p>
<p>In modern work tracking systems, users can mark work as complete before deploying it to production, which can lead to inaccurate lead times.</p>
<p>Survey data needs more effort, but it can capture a richness of information not available from a system. You can collect perceptual data from surveys and instrumented data you can't get from a system. For example, if you haven't installed tools to support deployment automation, you could use a survey to ask how often a team deploys to production.</p>
<p>When designing your surveys, consider the frequency and effort needed to respond. It helps if you coordinate your efforts to avoid flooding people with surveys from different parts of the organization.</p>
<p>You may need some statistical skills to account for bias and help establish significant relationships in the data.</p>
<p>For both system and survey data, if the organization isn't a safe space for honest feedback, the data will be what people believe to be the 'correct answer'.</p>
<p>People can manipulate system data as easily as survey data. Marking work as complete before it becomes overdue and then tracking the work outside the system to finish it, for example.</p>
<p>You can't measure a complex system (like the software delivery process) on system data alone. You should use both system and survey data in your measurement approach. Use the natural conflicts to discover and fix weaknesses in your measurement approach.</p>
<h2 id="its-all-about-improvement">It's all about improvement</h2>
<p>The techniques in the white paper, <a href="https://octopus.com/whitepapers/measuring-continuous-delivery-and-devops">Measuring Continuous Delivery and DevOps</a>, can help reveal improvement opportunities. They provide a mechanism to design your improvements deliberately and scientifically. If you make a change to increase deployment rates but instead deploy less, you know the change didn't have the intended effect and can try something else.</p>
<p>Over time, you need to respond to weaker signals rather than believing there are no further improvements to make. Teams and organizations that continuously improve will outperform those that think they're done.</p>
<p>You can <a href="https://octopus.com/whitepapers/measuring-continuous-delivery-and-devops">download the free white paper</a> to learn more.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/removing-sha1-tentacles</id>
<title type="text">Removing support for SHA-1 certificates in Octopus Tentacles</title>
<published>2025-03-26T14:00:00Z</published>
<updated>2025-03-25T04:09:01.1320879Z</updated>
<author>
<name>simon.canning@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/removing-sha1-tentacles" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-03/removing-sha1-tentacles/security.png" alt="Blue DevOps infinity diagram outlined in green with a green security shield over the right top-hand corner." /></p>
<p>In 2017, we <a href="https://octopus.com/blog/shattered">discussed</a> the implications of the <a href="https://shattered.io/" rel="nofollow">SHA-1 Shattered Collision</a> and what that meant for the Octopus Server to Tentacle communication channel. At the same time, we made <a href="https://octopus.com/docs/security/cve/shattered-and-octopus-deploy">product updates</a> to ensure that SHA-256 was used when new self-signed certificates were generated for versions of <a href="https://octopus.com/blog/octopus-release-3-14">Octopus 3.14</a>.</p>
<p>We've now decided to remove SHA-1 support. Fortunately, most customers use SHA-256 certificates, but some still use SHA-1 certificates.</p>
<p>In this post, I outline how this deprecation affects different customers. I also provide a timeline of what to expect and how to regenerate new SHA-256 certificates.</p>
<h2 id="understanding-communication-between-octopus-server-and-tentacles">Understanding communication between Octopus Server and Tentacles</h2>
<p>Security is paramount in modern software deployment environments. Octopus implements strong security measures for communication between the Octopus Server and its Tentacles.</p>
<p>Here’s a deep dive into how this communication is established, the role of TLS, and the rationale behind using self-signed certificates out of the box.</p>
<h3 id="secure-communication-via-tls">Secure communication via TLS</h3>
<p>When Octopus Server communicates with its Tentacles—the agents that handle deployment tasks—this interaction is always conducted over a secure Transport Layer Security (TLS) connection. TLS ensures the data exchanged between the 2 entities remains confidential and tamper-proof. Each server and Tentacle possess a unique public/private key pair crucial to establishing a secure and trusted link.</p>
<p>The Octopus Server’s thumbprint gets sent to the Tentacle during the configuration process. This thumbprint is a unique identifier for the Server's certificate, establishing a trusting relationship between the Server and the Tentacle. Conversely, the Tentacle informs the Octopus Server of its thumbprint. As a result, commands issued by the server get accepted exclusively by those Tentacles it recognizes and trusts, and vice versa.</p>
<p>This setup ensures that only legitimate entities can issue or accept commands, significantly enhancing the security of your deployment processes.</p>
<h3 id="the-use-of-self-signed-certificates">The use of self-signed certificates</h3>
<p>A common question about Octopus Deploy’s security model is why it defaults to using self-signed certificates instead of certificates issued by a Certificate Authority (CA). At first glance, using self-signed certificates may seem less secure, but there are several compelling reasons for this choice:</p>
<ol>
<li><em>Customized trust relationships</em>: The self-signed approach allows for precise trust management. When you set up a Tentacle, you manually input the Octopus Server's thumbprint. This process means that every connection is verified individually, ensuring authenticity. The connection is aborted if the server's identity cannot be confirmed through its thumbprint.</li>
<li><em>Operational efficiency</em>: Using self-signed certificates simplifies the installation and setup, particularly in automated environments. Instead of relying on a CA to generate certificates, which can introduce delays and complexities, Tentacles can quickly generate their certificates upon installation. Additionally, importing existing certificates can be streamlined, facilitating the automation of Tentacle installation.</li>
</ol>
<div class="alert alert-info"><p>We're <a href="https://roadmap.octopus.com/c/194-tentacle-certificate-management-improvements" class="alert-link" rel="nofollow">open to feedback</a> about how this decision affects your ability to manage your Octopus Server and Tentacles at scale. We're particularly interested in hearing from customers who'd like to discuss their current credential management and rotation practices.</p>
</div>
<h3 id="how-it-all-comes-together">How it all comes together</h3>
<p>When a Tentacle is registered with the Octopus Server, the 2 entities exchange their thumbprints, identifying their certificates. This process lays the foundation for a secure and trusted relationship. When the Octopus Server connects to a Tentacle, it checks that the Tentacle presents a valid certificate matching the expected thumbprint. This verification process is reciprocal; the Tentacle similarly checks that the connection originates from a trusted Octopus Server. If any discrepancies arise, the connection is immediately rejected.</p>
<p>This model mirrors principles in other secure communication protocols, like SSH, used in UNIX systems, providing a robust and familiar security framework.</p>
<h2 id="how-can-i-determine-if-im-affected">How can I determine if I’m affected?</h2>
<p>Below is an example command that will print out the machines (deployment target Tentacles) with sha1RSA set as their certificate signature algorithm. You'll need to replace the <code>instance-name</code> with your instance name or the full URL if you’re a self-host customer, <code>space-id</code> with a space ID (e.g., <code>Spaces-1</code>), and replace the API key with a key that has at least the MachineView permission.</p>
<pre><code>curl -H &quot;X-Octopus-Apikey: API-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&quot; -H &quot;Accept: application/json&quot; &quot;https://&lt;instance-name&gt;.octopus.app/api/&lt;space-id&gt;/machines&quot; | jq '.Items .[] | select(.Endpoint.CertificateSignatureAlgorithm==&quot;sha1RSA&quot;)'
</code></pre>
<p>For more detail, read about <a href="https://octopus.com/blog/api-bash-jq#using-the-octopus-api-with-bash-and-jq">using the Octopus API with Bash and jq</a>. Alternatively, you can <a href="https://octopus.com/blog/interacting-with-the-octopus-deploy-api-using-powershell">interact with the Octopus Deploy API using PowerShell</a>.</p>
<h2 id="do-i-have-to-wait-for-a-new-octopus-server-or-tentacle-version">Do I have to wait for a new Octopus Server or Tentacle version?</h2>
<p>No, you do not. You can take action now. Octopus has supported SHA-256 certificates for Server to Tentacle communications since the <a href="https://octopus.com/blog/octopus-release-3-14">3.14 release in June 2017</a>.</p>
<h2 id="what-do-i-need-to-do">What do I need to do?</h2>
<p>To configure a Tentacle to use a new certificate, ensure your Tentacle version is on the latest version and <a href="https://octopus.com/docs/security/octopus-tentacle-communication/regenerate-certificates-with-octopus-server-and-tentacle#ConfiguringATentacleToUseANewCertificate">follow the instructions in our docs</a>.</p>
<h2 id="what-is-the-deprecation-schedule">What is the deprecation schedule?</h2>
<p>Below are details of the deprecation schedule, depending on the Octopus product and operating system your server runs on.</p>
<h3 id="octopus-cloud-customers">Octopus Cloud customers</h3>
<p>We plan to start emailing affected customers about the deprecation on March 31, 2025, and give at least 60 days' notice before we switch off support for SHA-1 on June 1, 2025. After that point, any deployment target or worker still using SHA-1 Tentacle will no longer be able to connect to Octopus Cloud. We plan to give reminders regularly, including 30 days, 7 days, and a final warning. You can take action now.</p>
<h3 id="octopus-server-linux-container-customers">Octopus Server Linux container customers</h3>
<p>We plan to release an in-product configuration option to turn on/off the SHA-1 Tentacle support in Octopus Server 2025.2 and remove support for SHA-1 Tentacles in the subsequent Octopus Server 2025.3 release. These changes will impact Octopus Server Linux container customers only.</p>
<p>As a self-hosted customer, you control the update cycle of your Octopus Server and, therefore, have some flexibility around how and when to perform the appropriate updates. We recommend you take action as soon as possible.</p>
<h3 id="octopus-server-windows-customers">Octopus Server Windows customers</h3>
<p>There are no immediate required actions for Octopus Server Windows self-hosted customers. This is because we can continue to support SHA-1 certificates using supported operating systems and runtime environments for the time being.</p>
<p>As a self-hosted customer, you control the update cycle of your Octopus Server and, therefore, have some flexibility around how and when to perform updates. We still recommend you take action and move off SHA-1 certificates as soon as possible.</p>
<h3 id="future-work">Future work</h3>
<p>In the future, we expect to add features in Octopus Server to support automatically regenerating certificates on the Octopus Server and all Tentacles. We're currently in the discovery phase of this work. We're particularly interested in hearing from customers who would like to <a href="https://roadmap.octopus.com/c/194-tentacle-certificate-management-improvements" rel="nofollow">discuss their current credential management and rotation practices</a>.</p>
<h2 id="conclusion">Conclusion</h2>
<p>Removing support for SHA-1 certificates in Octopus Tentacles is part of our commitment to deliver secure software deployment environments. It enables us to continue to support modern operating systems and runtime environments. </p>
<p>While most customers have moved to the more secure SHA-256 certificates, it's crucial for those still using SHA-1 to understand the implications of this deprecation. The communication between Octopus Server and Tentacles relies on secure TLS connections and self-signed certificates, promoting customized trust relationships and operational efficiency. As the move towards stronger cryptographic algorithms continues, we encourage customers to regenerate their certificates to align with best practices. </p>
<p>We <a href="https://roadmap.octopus.com/c/194-tentacle-certificate-management-improvements" rel="nofollow">welcome feedback about credential management and practices</a> to ensure the Octopus platform meets your needs effectively. This transition bolsters security measures, further safeguarding the deployment processes critical to businesses.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/scoped-tenant-variables</id>
<title type="text">Scoped tenant variables</title>
<published>2025-03-24T14:00:00Z</published>
<updated>2025-03-21T03:18:14.6240937Z</updated>
<author>
<name>susan.pan@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/scoped-tenant-variables" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-03/scoped-tenant-variables/blogimage-variable-tenants-ui-dashboard-2024.png" alt="Graphic image of woman viewing scoped tenant variables page." /></p>
<p>We recently improved tenant variables by introducing scoped tenant variables.</p>
<p><a href="https://octopus.com/docs/tenants/tenant-variables">Common tenant variables</a> are great for managing variables within tenants. Assigning a common tenant variable means that every connected project has access to that variable. This is great for deploying and managing multi-tenanted deployments at scale, and simplifies deployments by using the same value for every connected environment. We wanted to create more flexibility by letting customers set different common variable values for each environment across all tenant projects. Scoped common tenant variables aim to solve this.</p>
<p>Assigning environment scopes to your common tenant variables will make variable management across tenant projects so much simpler.</p>
<p>In this post, I walk you through how to scope tenant variables and discuss the integration capabilities.</p>
<p>These updates are now available to our Cloud customers and will be available to self-hosted customers from v2025.2.</p>
<h2 id="why-should-i-scope-tenant-variables">Why should I scope tenant variables?</h2>
<p>Previously, there were both constraints and differences in how you managed tenant variables for environments. </p>
<ul>
<li>Tenant project variables required one value per project environment. </li>
<li>Tenant common variables were limited to one value across all environments connected to a tenant. </li>
</ul>
<p>Now, you can scope common variables to environments as needed. This means they can be unscoped (variable applies to all connected environments), singly-scoped, or multi-scoped. </p>
<p>The ability to assign scopes to tenant variables creates more simplicity and flexibility with variable management. For example, to assign different variable values for different environments across all tenant projects, you previously had to create a tenant for each environment. You could then set a common variable for each tenant. Now, you simply set multiple common variables with the appropriate environment scope. </p>
<p>This is particularly useful if your non-production environments all share one value, while production has a separate value. Maintaining variables becomes more straightforward as you only need to update values once.</p>
<h2 id="how-to-assign-scopes-to-your-tenant-variables">How to assign scopes to your tenant variables</h2>
<p>You can set tenant variables from the projects page and from the tenants page. To set tenant common variables from the project page, you need to create a tenant with a connected project and connected environments. Then you create a variable set with a variable template and connect it to the tenanted project.</p>
<ul>
<li>Select the <strong>Tenant Variables</strong> page from the sidebar and click on the <strong>Common Templates</strong> tab.</li>
</ul>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-03/scoped-tenant-variables/scoped-tenant-vars-view.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-03/scoped-tenant-variables/scoped-tenant-vars-view.png' class="img-fluid center" alt='Screenshot of common tenant variables tab on tenant variables page.' /></a></p>
<ul>
<li>To add a new tenant variable, select the overflow menu and click <strong>Add</strong>.</li>
<li>Type in a value and select the environments in the <strong>Scope</strong> column. Click <strong>Save</strong>.</li>
</ul>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-03/scoped-tenant-variables/scoped-tenant-vars-add-new.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-03/scoped-tenant-variables/scoped-tenant-vars-add-new.png' class="img-fluid center" alt='Screenshot of adding a new tenant variable on tenant variables page.' /></a></p>
<ul>
<li>The page should now show the new tenant variable values and scopes.</li>
</ul>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-03/scoped-tenant-variables/scoped-tenant-vars.png' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-03/scoped-tenant-variables/scoped-tenant-vars.png' class="img-fluid center" alt='Screenshot showing new scoped tenant variables on tenant variables page.' /></a></p>
<p>Unscoped variables apply to all environments with no explicitly scoped variables. <a href="https://octopus.com/docs/projects/variables/getting-started#scoping-variables">See our docs for more information on scoping variables</a>.</p>
<h3 id="migrating-existing-tenant-variables">Migrating existing tenant variables</h3>
<p>Existing tenant variables will automatically get migrated to the new scoped tenant variables when upgraded to 2025.2. The migration will scope tenant project variables to the previous single scope and common variables will be unscoped. This ensures your deployments can proceed without making any changes. After your instance detects scoped tenant variables in use, it will prevent the use of the old tenant variable endpoint. </p>
<div class="alert alert-warning"><p>We'll deprecate the endpoint <code>tenants/{tenantId}/tenantvariables</code> from 2026.2.</p>
</div>
<p>We introduced 2 new endpoints for GET/UPDATE requests for scoped tenant variables. These will replace the use of the endpoint above:</p>
<ul>
<li><code>tenants/{tenantId}/projectvariables</code></li>
<li><code>tenants/{tenantId}/commonvariables</code></li>
</ul>
<h2 id="automation-and-integration">Automation and integration</h2>
<p>Scoped tenant variables are now supported through our .NET, TypeScript, and Go clients. <a href="https://octopus.com/docs/octopus-rest-api/getting-started#api-clients">See our docs for more information on our API clients</a>.</p>
<p>Octopus CLI will also support the use of scoped tenant variables. As our CLI matches tenant variables on the variable's name and environment, the tenant variable update function currently doesn't support changing variable scopes of existing tenant variables. To select the correct tenant variable, you must specify the exact scope.</p>
<p>Our Terraform provider doesn't currently support the new scoped tenant variables. If you'd like this to be supported, please don't hesitate to <a href="https://octopus.com/support">get in contact</a> with us.</p>
<h2 id="conclusion">Conclusion</h2>
<p>Scoped tenant variables give you finer control of your tenant variables. Now, you can simply assign a scope to your tenant variables and watch the magic happen.</p>
<p>To get started or learn more, you can read our <a href="https://octopus.com/docs/tenants/tenant-variables">tenant variables documentation</a>.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/revamping-careers-page</id>
<title type="text">Revamping our careers page: More than just a makeover</title>
<published>2025-03-17T14:00:00Z</published>
<updated>2025-03-13T06:47:03.7470649Z</updated>
<author>
<name>stephanie.king@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/revamping-careers-page" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-03/revamping-careers-page/blog-revamp-careers-page-2025-750x400-x1.png" alt="Painters painting and revealing the careers webpage, with sticky notes around the image featuring photos of Octopus employees." /></p>
<p>If you’ve been through a website redesign, you know it’s a lot like refactoring old code. You start with confidence that it should be an easy fix, and before you know it, you’re knee-deep in overhaul and questioning how you got here.</p>
<p>Our <a href="https://octopus.com/company/careers">careers page</a> revamp was no different. Before the redesign, our page was fine. It was functional, informative, and technically accurate. But with the evolution of Octopus over the last few years, it wasn’t quite us anymore. So we did what many DevOps teams do when faced with legacy infrastructure—we rebuilt it.</p>
<h2 id="why-we-overhauled-the-page">Why we overhauled the page</h2>
<p>The careers page is part of a larger, strategic effort to strengthen our employer brand. It isn’t just a recruitment tool but an integral piece of our broader employer strategy. Just as we want customers to know and trust the Octopus brand, we want potential employees to have a clear sense of who we are and what it means to work here.</p>
<p>A talent team should think of their careers page as far more than just a list of open jobs and advertisement space. It’s the first (and sometimes only) impression, a handshake, and a small window into what it truly means to work at your company. From the content to the emotions visitors leave with, a careers page should tell a story. It should give potential candidates a real sense of the culture, values, and experience of being part of the team.</p>
<p>At Octopus, we aren’t just hiring people to fill roles. We’re inviting folks into our authentic, people-centric, and transparent culture, where we want them to do the best work of their lives. We think about the people joining our company like pieces of a much bigger puzzle, or individual threads in the organic, human fabric we’re intentionally weaving—each one adding depth, strength, and uniqueness to the whole. That feeling isn’t easy to capture with stock photos and generic content.</p>
<p>When I started at Octopus in 2022, I began advocating for more talent engagement, a revamped careers page, and deeper investment in employer branding. This year, I challenged our team to consider:</p>
<ul>
<li>Does our careers page reflect who we truly are?</li>
<li>Would we want to apply to Octopus based on what we see at first glance?</li>
<li>Is it easy (and exciting!) for people to picture themselves on our team?</li>
<li>Are we giving candidates a real feel for our culture, or just listing jobs?</li>
<li>Does every word, image, and detail make people want to be part of this journey?</li>
</ul>
<p>With each question, it became clear that we'd barely scratched the surface of what was possible. So, we set out to build something that not only showcases our opportunities but also captures the spirit of working at Octopus.</p>
<h2 id="whats-changed">What’s changed?</h2>
<ul>
<li>A more human touch - You’ll see more real Octonauts sharing their experiences because culture isn’t something you describe; it’s something you show.</li>
<li>Remote work, represented - As a remote-first company, we made it clear how we work, collaborate, and keep things fun across multiple timezones.</li>
<li>A careers page with personality - No corporate jargon or fluff. It's just an authentic, engaging, and maybe even slightly quirky look at life at Octopus.</li>
<li>More than just jobs - We’re shining a light on what it truly means to work at Octopus, from career growth to the perks that matter, with more transparency than ever.</li>
</ul>
<h3 id="the-partnerships-that-made-this-possible">The partnerships that made this possible</h3>
<p>This wasn’t just a talent team project. It was a multi-threaded, strategic effort with collaboration across teams and partners.</p>
<ul>
<li>Our marketing team and Octonaut volunteers - From content creation to branding, many Octonauts generously gave their time to shape how we tell our story. Their insights, feedback, and participation helped make our careers page a true reflection of life at Octopus. Our marketing team dove in heads first to make this a seamless experience and were invaluable in the making of our careers page.</li>
<li>Adam Marsh from Moment2Moment - Our incredible on-set videographer in Australia, who captured the heart of Octopus through film. His keen eye and ability to bring our genuine, unscripted moments made all the difference in our careers video.</li>
<li>Yoram Pollack from Visual Trigger - A true visionary behind the storytelling, video editing, and overall concept execution. Yoram took our initial ideas and let us share our stories with him so he could transform them into something beyond what we imagined, making our dream careers page a reality.</li>
</ul>
<p>We're grateful to everyone who played a part. We built an experience that reflects who Octonauts are and why people should be excited to join us.</p>
<h2 id="explore-life-at-octopus">Explore life at Octopus</h2>
<p>Our new <a href="https://octopus.com/company/careers">careers page</a> isn’t just about listing jobs. It’s about showing what makes Octopus a special place to work. Whether you’re an engineer, a sales pro, a marketer, or just curious about our culture, we invite you to explore, get to know our team, and see if Octopus feels like a great fit for you to do the best work of your life.</p>
<p>We’d love to hear what you think. If you’ve crafted your own careers page, what was your strategy? If you have feedback as a job seeker, send it our way. If you’re thinking about joining us, what are you waiting for? <a href="https://octopus.com/company/careers">Dive on in!</a> And if you’re as excited as we are, maybe start practicing your best “I just landed my dream job” happy dance!</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/trust-security-customer-protection</id>
<title type="text">Building trust through security—our commitment to customer protection</title>
<published>2025-03-10T14:00:00Z</published>
<updated>2025-03-07T04:49:58.3967164Z</updated>
<author>
<name>simon.canning@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/trust-security-customer-protection" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-03/trust-security-customer-protection/security.png" alt="A stylized Octopus and shield icon." /></p>
<p>Our top priority at Octopus Deploy is ensuring our customers can deploy safely and securely. We're proud that 4000+ customers <a href="https://octopus.com/company/trust">trust us</a> and our products to deliver their changes into production. We take that responsibility seriously, and our <a href="https://octopus.com/security/disclosure">security guiding principles</a> prioritize our customers' security interests over ours.</p>
<p>In this post, I walk you through our most recent product security updates.</p>
<h2 id="product-security-enhancements">Product security enhancements</h2>
<p>We’re happy to announce improvements to the Octopus Server in 2025.1, which have already rolled out to Octopus Cloud customers. We made changes to our encryption support across data at rest and in transit. These changes provide you with enhanced security, lower network latency, and the potential for improved operational efficiency.</p>
<p>The changes include:</p>
<ul>
<li>Using AES-256 by default for Master Key encryption of sensitive data in the Octopus database for all new server instances.</li>
<li>Adding TLS 1.3 support to Octopus Server and Octopus Cloud for the Octopus Tentacle communication channel.</li>
</ul>
<h2 id="security-and-compliance-programs">Security and compliance programs</h2>
<p>We're dedicated to maintaining and continuously improving our security and compliance programs alongside <a href="https://roadmap.octopus.com" rel="nofollow">continued product improvements</a>. We undergo regular third-party audits and technical assessments of our data security to ensure privacy and safety.</p>
<p>Our security credentials include:</p>
<ul>
<li>SOC 2 Type II: This demonstrates the robustness of our controls around security, privacy, availability, and confidentiality in Octopus. It reflects our commitment to earning and maintaining customer trust in our product and service.</li>
<li>ISO 27001:2013: This certifies that Octopus’s information security management system meets industry-standard requirements for protecting customers’ information.</li>
</ul>
<h2 id="conclusion">Conclusion</h2>
<p>At Octopus, security is everybody's business. We're continuously making product improvements to meet the security needs of our customers. We're also dedicated to security and compliance programs. We pride ourselves on making Octopus a secure product for our customers.</p>
<p>Happy deployments!</p>
</content>
</entry>
<entry>
<id>https://octopus.com/blog/config-as-code-runbooks</id>
<title type="text">Configuration as Code for Runbooks</title>
<published>2025-03-03T14:00:00Z</published>
<updated>2025-02-20T04:17:48.0779407Z</updated>
<author>
<name>harriet.alexander@octopus.com, Octopus Deploy</name>
</author>
<link href="https://octopus.com/blog/config-as-code-runbooks" />
<content type="html"><p><img src="https://i.octopus.com/blog/2025-03/config-as-code-runbooks/img-configascode-runbooks-2024.png" alt="Graphic of a woman sitting on a large stack of books while working on laptop, surrounded by large, three-dimensional curly braces." /></p>
<p>Config as Code for Runbooks is officially landing as part of Octopus 2025.1. This feature gives you a seamless, version-controlled way to manage your runbooks.</p>
<p>You can run, create, and track your runbooks in your chosen Git repository, bringing your runbooks together with your deployment process. This means fewer places to make changes and provides more control over your workflows.</p>
<h2 id="why-config-as-code-for-runbooks">Why Config as Code for Runbooks?</h2>
<p><a href="https://octopus.com/docs/runbooks">Octopus Runbooks</a> automates routine and emergency operations tasks. Storing your runbooks in your Git repo with your application code, deployment process, and non-sensitive variables unlocks the full power of version control.</p>
<ul>
<li>Store your runbooks in your Git repo to stay in sync. You can make and test changes alongside your app code, so your code and operational processes never get out of sync.</li>
<li>Store your runbooks in Git to version-control your operational tasks. This way, you can manage versions with minimal effort. If you need to roll back or retrieve an earlier configuration, you can run the runbook for a specific commit or tag.</li>
<li>Access the complete history for auditability. You can review all changes via pull requests, providing a full history of all changes to your runbooks.</li>
<li>Rollback easily. Mistakes happen! But with version control in place, it's easier than ever to revert to a previous version of your runbooks. The complete history lets you track and manage past configurations.</li>
</ul>
<h2 id="how-to-use-config-as-code-for-runbooks">How to use Config as Code for Runbooks</h2>
<p>Version control is a requirement for Config as Code for Runbooks.</p>
<ul>
<li>If your projects are version-controlled, the setup and migration is quick and easy. You'll also find using Config as Code for Runbooks natural. Following Git principles will make the process straightforward.</li>
<li>If you're not using version control yet, you can enable it and start using Config as Code for Runbooks. <a href="https://octopus.com/docs/projects/version-control/converting">See our docs for a guide on enabling version control for your project</a>.</li>
</ul>
<h3 id="migrating-existing-runbooks">Migrating existing runbooks</h3>
<p>If you use Octopus Runbooks, we have a tool to help you migrate to Config as Code for Runbooks.</p>
<ul>
<li>Migration process: When you start the migration, Octopus moves your published runbooks to a new folder, <code>/runbooks</code>, in your chosen repository. This folder stores the published snapshot and configuration from the runbook.</li>
<li>Octopus migrates any draft versions of your runbook to a separate sub-folder <code>/runbooks/migrated-draft</code>. You won't see these in the UI, but you can access them by moving them into the main runbooks folder using a pull request (PR).</li>
<li>History retention: You don't need to worry about losing your history. The UI will still show your existing runbook runs.</li>
</ul>
<p><a href='#' data-featherlight='https://i.octopus.com/blog/2025-03/config-as-code-runbooks/configascode.gif' class='zoom' data-title=''><img src='https://i.octopus.com/blog/2025-03/config-as-code-runbooks/configascode.gif' class="img-fluid center" alt='GIF of Runbooks migration process. Starting on the Runbook list, user opens the wizard, reviews changes, creates new branch, uses default commit message, reviews the migration, and completes it. Next, the Runbooks list screen automatically refreshes showing a branch selector and alert with unmigrated drafts.' /></a></p>
<h2 id="new-in-config-as-code-for-runbooks">New in Config as Code for Runbooks</h2>
<p>There are a few tweaks to how Runbooks work in the Config as Code setup. We made these adjustments to improve functionality and streamline your workflow. If you're curious about these changes, <a href="https://octopus.com/blog/introducing-config-as-code-runbooks">read our post, Introducing Config as Code for Runbooks</a>.</p>
<div class="alert alert-info"><p>These changes apply exclusively to Config as Code for Runbooks. If you're not using version control, they won't impact your runbooks.</p>
</div>
<h2 id="conclusion">Conclusion</h2>
<p>Config as Code for Runbooks has been one of our most highly requested features. Our community wanted it, and we're excited to deliver it.</p>
<p>Putting runbooks in your Git repos with your app code simplifies DevOps workflow management. It ensures everything is version-controlled and fully auditable. To see it in action, you can <a href="https://www.youtube.com/watch?v=oRWKDUzYBYA" rel="nofollow">watch our webinar</a>.</p>
<p>Config as Code for Runbooks has rolled out to Cloud customers and will be available soon for self-hosted customers in the 2025.1 release. We can't wait for you to try it out and experience the benefits for yourself.</p>
<p>Happy deployments!</p>
</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):
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