Octopus Deploy

A deployment tool, not a build tool

Octopus Deploy starts where your CI server stops. Jenkins, GitHub Actions, TeamCity or Azure DevOps builds a package or container image, pushes it somewhere, and tells Octopus to create a release. Octopus then decides where that release goes, in what order, and who has to approve it. The vendor's own documentation says it assumes a CI system already exists. If you do not have one, you are buying half a pipeline.

That narrow scope is the product. Everything is organised around promoting one artifact through a series of environments rather than around running arbitrary jobs.

Lifecycles and the release snapshot

A lifecycle is a list of phases, each containing environments marked as automatic or manual. A release can be configured so it cannot reach Production until it has succeeded in Dev and Test, or until a minimum number of environments in a phase have succeeded. A release also snapshots its deployment process and variables at creation time, so redeploying release 4.2 to a new environment six weeks later runs the same steps it ran the first time, not whatever the process looks like today.

The snapshot is useful for audit and rollback. It is also a source of confusion: someone edits the process, expects the next deployment of an old release to pick it up, and it does not. You have to create a new release.

Runbooks for the work after deploy

Runbooks live inside a project and automate operational tasks such as restarting a pod, rotating a credential, failing over a database or provisioning a test environment. The practical gain is permissions. You can let a developer run the restart runbook against Production without giving them access to the cluster itself.

Multi-tenancy

Tenants let one project deploy to many customer-specific targets with per-tenant variables, so a SaaS vendor with 200 customer installations does not maintain 200 copies of a process. It does require upfront design. Modelling tenants, tags and scoped variables badly is hard to undo later.

What it costs, and where the bill grows

Free: 10 projects, 10 machines, 10 tenants, 1 space and 10 users, with community support and no expiry. A separate 30-day trial unlocks Enterprise features.

Self-hosted Octopus Server: Professional $2,080/year, Enterprise $15,600/year. Octopus Cloud: Professional $4,330/year, Enterprise $24,600/year. Professional starts at 20 projects and goes up to 100; Enterprise starts at 100 and goes up to 1,000.

Tenants and machines are add-ons at $770/year for the 10-unit tier, and the pricing page does not publish the larger tiers. Teams deploying to many targets cannot estimate cost from the page alone and will need a quote. Billing is annual only; there is no monthly option on either hosting model.

Enterprise adds Platform Hub, global deployment freezes, DORA metrics, SIEM audit log streaming and ITSM integration. Task concurrency is another lever: Cloud plans start at 5 concurrent tasks on Professional and 20 on Enterprise, with more available for a fee.

Fit

It earns its price where a release crosses several environments, needs sign-off, or goes to many customer installations. For one service deploying to one cluster from a single workflow file, the setup effort and the add-on pricing are hard to justify.