Octopus Deploy Documentation

Common Terms

Last updated

Self-Hosted Octopus

Installing the self-hosted Octopus Deploy server sets up the Octopus Web Portal and the Octopus REST API.

The installation documentation provides instructions for downloading, installing, and configuring your Octopus Deploy server.

Octopus Cloud

Octopus Cloud is the hosted version of Octopus Deploy. We designed Octopus Cloud and self-hosted Octopus to provide the same functionality; however, there are some minor differences, for instance, with Octopus Cloud, we're responsible for taking backups, upgrading the service, and maintaining and monitoring the underlying systems.

The Octopus Web Portal

Whether you're self-hosting the Octopus server, or using Octopus Cloud, the Octopus Web Portal is where you'll manage your infrastructure, projects, access the built-in repository, grant your team access to projects, and create your automated deployments.

Deployment Targets

Deployment Targets represent the servers, machines and cloud services where your software and services will be deployed.


Octopus organizes your deployment targets into groups called Environments so you can promote your software through your deployment pipeline. For instance, from Development to Test and finally into Production.

Target Roles

Target roles allow you to β€œtag” deployment targets with a specific keyword which can be used in your deployments.


Lifecycles give you control over the way releases are promoted between environments.


A Package is an archive (zip, tar, NuGet) that contains all the files needed to run your software. You can host Packages in external repositories or the built-in Octopus repository. The package will need to be named correctly with a package ID, version number and as a supported format, for Octopus to recognize it. For example MyPackage.1.0.1.zip


Projects let you manage multiple software projects from the Octopus Web Portal. For each project you have, you define a deployment process, configuration variables, and the environments the software will be deployed to.

Deployment Process

The deployment process is like a recipe for deploying your software. You define the recipe by adding steps and variables to a project. Each step contains a specific action (or set of actions) that is executed as part of the deployment process each time your software is deployed.


Octopus lets you define variables for configuration values that change, so you can have a different value for each Environment or Deployment Target

Creating a Release

A Release is a snapshot of your deployment process, configuration variables, and software packages. Releases are created from Projects and deployed via a Lifecycle to your Environments.

Deploying a Release

When you deploy a release, you are executing the deployment process with all the associated details, as they existed when the release was created. You can deploy a release as many times as you want to.


With Spaces you can give each team their own set of projects, environments, and infrastructure that is separate from the other teams. Users can be members of multiple teams and have access to multiple spaces, but the entities and infrastructure they work with will only be available in the space it is assigned to. If you're a large organization with lots of teams working in Octopus, from 2019.1 you can use the Spaces feature.

Welcome! We use cookies and data about how you use our website allow us to improve the website and your experience, and resolve technical errors. Our website uses cookies and shares some of your data with third party analytics companies for these purposes.

If you decline, we will respect your privacy. A single cookie will be used in your browser to remember your preference.