Skip main navigation

Hurry, only 6 days left to get one year of Unlimited learning for £249.99 £174.99. New subscribers only. T&Cs apply

Find out more

Configuring Octopus – The Environment


By now you should understand a great deal more about Octopus, its Architecture and how to install it. In this step, we’re going to learn how Octopus is configured. Let’s begin by discussing the Environment.

An environment represents a group of machines or cloud services for which a release will be deployed at the same time. For all purposes, an environment is a group that has machines or cloud services inside and it is where code will be deployed.

Not all cloud services will be visible inside an environment, but an environment is always needed for code to be deployed.

An environment has a name and an optional description. An environment can have deployment targets associated with it.

Environments have a defined order and the order of the environments affect how they are shown. This depends on the defined lifecycle of the order in which a version can be deployed, for example, if you can only deploy a release to a higher environment after it has been deployed to the lower environment.

graphical representation of environments on Octopus

By default, a project can be deployed to any environment. To limit the environments to which a project can be deployed, you must create a lifecycle.


Access to an environment can be restricted (view and edit permission) by granting access to environments to a team (and a role to the team). If no environments are assigned, then the team will have access to all environments.

Deployment Target

An environment can have one or more deployment targets. A deployment target represents a machine or target to which you want to deploy packages. The destination can be a Windows or Linux machine, a Windows share, or a cloud region.


An account represents a credential that can be used in steps or with deployment targets for authentication purposes.

Machine Policy

Machine policies allow you to define the behaviours that apply to Tentacle and SSH endpoints.

The following behaviours can be configured with a machine policy:

  • Customise the interval between health checks
  • Run custom health check scripts
  • Ignore machines that are unavailable during health checks
  • Configure how Calamari and a Tentacle are updated
  • Automatically delete machines.

Remember to engage with peers – share an experience, ask a question or leave a comment. When you are ready, click on Mark as complete to move on to the next step, Configuring Octopus – Machine Role and Lifecycle.

This article is from the free online

Microsoft Future Ready: Continuous Integration Implementation

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now