Octopus Deploy is a continuous delivery platform for releasing applications and automating operations after a build system produces the software. It provides a browser portal and API, with vendor hosting through Octopus Cloud or self-hosting on Windows Server and Linux containers. A usage-limited Free tier accompanies paid Professional and Enterprise subscriptions. Free licenses cover ten projects, ten tenants, ten machines and ten users within one space.
Projects and release snapshots
A project holds the deployment process, variables, releases and runbooks for an application, service or database. Build servers publish application packages to Octopus’s built-in repository or external feeds. These can include NuGet, ZIP and Java packages, container images or Helm charts.
Creating a release captures the process, scripts, package-version references and project variables at that point. Octopus can deploy that release repeatedly across environments without adopting later process edits. Its API also lets CI pipelines create releases and initiate deployments.
Actions in a deployment
Users assemble steps from templates or supply scripts. Each step defines an action, its execution location and conditions, such as an environment or previous result. Steps can run in sequence or parallel, while rolling deployments limit how many targets receive an update simultaneously.
A manual intervention step presents instructions to a responsible team member, who chooses Proceed or Abort. Subsequent steps follow their run conditions. For dependent applications, a Deploy Release step starts another project’s release, allowing a parent process to coordinate several components.
Targets and workers
Users assign deployment targets to environments and label their purpose with target tags in Octopus Deploy. A web-server step can therefore select suitable machines without naming each host inside the process. Connections can use Tentacle agents, SSH, command-line tools or web services.
Workers execute tasks that need no direct execution on an application target, including cloud-resource changes and database operations. They return logs and collected artifacts to the server. Self-hosted instances offer a built-in worker; Octopus Cloud supplies dynamic workers, and both can use external workers.
Configuration for each destination
Variables provide values, secrets and accounts for deployment steps. Users scope them to environments, targets, target tags, steps or channels. Shared variable sets supply settings across projects within a space.
The Structured Configuration Variables feature locates matching settings in JSON, YAML, XML and Properties files, then substitutes values for the deployment context. Users specify target files and structure expressions, including paths to nested settings.
For version-controlled projects, Octopus stores deployment resources in Git. Users choose a branch and edit through the portal or an external editor. Portal changes create commits; external changes appear after Octopus fetches the repository. Protected branches require portal edits to enter a new branch.
Promotion paths
Lifecycles arrange environments into phases and define the successful deployments necessary before a release can advance. Phases can require completion, allow omission or deploy automatically. Optional phases do not run automatic deployments.
Channels give one project different release strategies through lifecycle selection, package-version rules and Git resource restrictions. Ephemeral environment channels create temporary test environments on demand. These inherit configuration from a parent environment, while runbooks can provision and remove their infrastructure.
Tenant-specific delivery
Tenants represent customers, locations or regions that need separate application instances. Octopus Deploy reuses a project’s process while applying each tenant’s configuration and infrastructure connections. Tags group tenants and tailor deployments, and team scopes restrict access to particular tenants.
Tenant variables remain outside release snapshots. Their changes take effect immediately, and users can add another tenant without creating a new release.
Runbooks for operations
Runbooks apply process steps to tasks such as database backups, infrastructure provisioning and website failover. Users choose environments and target subsets, supply prompted values, then run immediately or schedule execution. Lifecycles do not govern these operations.
Database-backed runbooks have draft and published snapshots. Publishing captures the process, variables and package references while authors continue testing draft changes. Scheduled triggers use the published snapshot. Git-backed runbooks instead use branches, and their scheduled triggers run the latest default-branch commit. Schedule controls include weekdays, monthly dates and CRON expressions.
Kubernetes through GitOps
Octopus deploys Kubernetes resources from YAML or Helm charts and shows application status across environments. Its Argo CD integration maps Argo applications to Octopus projects. Deployment steps update the backing Git repositories, while Argo CD synchronizes manifests to clusters. Octopus then combines lifecycle promotion with dashboards showing application and resource status.
Runtime feature flags
Octopus Cloud offers Feature Flags as a preview, using OpenFeature in the client application. Users create a project flag, assign environment values and configure the Octopus provider with a client identifier. Applications request flag values for that context, allowing runtime feature changes without another deployment. Targeting can select tenants, percentages or user segments.
Governance across teams
Spaces partition projects, environments and infrastructure for separate teams. Role permissions control access, while audit history records configuration changes, deployment requests and their actors. Enterprise adds audit streaming, deployment freezes and IT service-management integration.
Enterprise Platform Hub keeps reusable process templates, project blueprints and policies in Git. Teams supply blueprint parameters while the template controls the deployment process. Platform administrators can share process templates across spaces and apply policies before or after deployments.
Deployment results and diagnosis
The project dashboard locates releases across environments, channels and tenants. Task logs show execution output. Guided failure pauses an unsuccessful step so users can retry, skip or fail it.
Insights summarizes deployment frequency, failure rate, lead time and recovery time, with filters and CSV export. Project reports serve all customers; Enterprise adds reports across a space.
The Early Access AI Assistant answers questions, generates projects from descriptions and examines deployment failures. The Recovery Agent separately analyzes failure causes and suggests recovery steps. It currently leaves execution of those proposed repairs to people.
