Migrate from Octopus Deploy

Octopus users will find Slipway’s deployment model familiar: that is deliberate. The work in a migration is converting deployment process steps and variables, and deciding what to do about your build server.

Concept map

Octopus	Slipway	Notes
Space	Organisation
Project group	Project	Group related services in a project
Project	Service (plus its deployment definition)
Environment	Environment	Order comes from the lifecycle
Lifecycle	Lifecycle	Phases with auto_promote, min_soak, optional phases
Channel	Channel	Version rules (semver, glob, regex) select the lifecycle
Release	Release	Immutable; artifacts by digest
Deployment	Deployment	With a strategy
Deployment process	Strategy plus deployer, or pipeline steps	Built-in strategies replace hand-built rolling and blue/green processes
Step templates	Registry steps, templates
Deployment targets	Infrastructure on an environment
Tentacle (listening or polling)	Runner (always outbound)
Worker pools	Runner pools
Target roles	Labels
Tenants	Tenant dimension on variables
Variables (scoped by environment, role, tenant, channel)	Variables (scoped by infrastructure, tenant, environment, channel, service)	Same precedence idea, most specific wins
Variable sets	Org-level variables
Sensitive variables	Secrets, or variables marked sensitive
Manual intervention	Manual gate / approval
Guided failure	Retry and rollback on the deployment
Runbook	Runbook	Parameters, steps, environments, approval
Deployment freeze	Freeze period
Library packages, feeds	Services’ artifact sources, registry integrations
Config transforms, .variables substitution	Variables and templated ${{ vars.X }}

Worked example: a rolling deployment

Octopus: a project with “Deploy Kubernetes containers” and a manual intervention step on Production, lifecycle Dev -> Staging -> Production.

Slipway:

1. Create service api (kind container, artifact source: your registry repository).
2. Create environments dev, staging, production with infrastructure pointing at each cluster and namespace, with the runner pool that can reach it.
3. Create a lifecycle standard: dev (auto-promote), staging (auto-promote, soak 30m), production.
4. Create a channel stable using it.
5. On production, set required_approvals: 1, approvers: role deployer. That replaces the manual intervention step, and it also covers runbooks and promotions.
6. Choose a strategy: rolling or canary with verification.

Deploy:

slipway release create api 1.4.0 --artifact image=ghcr.io/acme/api@sha256:abc
slipway deploy api 1.4.0 --env dev
# auto-promotion handles staging; production waits for approval
slipway approve dep_01H...

Variables

Export your Octopus variables (without sensitive values), then recreate them with the matching scope. Octopus scopes map as: environment to environment, channel to channel, deployment target to infrastructure, tenant to tenant. Re-enter sensitive values from your secret manager, or use external references. Use preview to compare resolved values per environment before you deploy.

Build

Octopus assumes an external CI tool that pushes packages and creates releases. You can keep it:

slipway release create api $VERSION --artifact image=$IMAGE@$DIGEST   # from any CI tool

or move builds into Slipway pipelines so build and deploy share one model and one audit trail.

Runbooks

Runbook steps are converted to pipeline-step syntax (run, uses). Parameters map to runbook parameters. Mark production-affecting runbooks requires_approval and bind permissions at the environment scope.

Order of operations

1. Model one service with all environments in Slipway; deploy to a non-production environment from both tools.
2. Compare variable resolution via preview.
3. Move production after a successful staging soak and an approval rehearsal.
4. Decommission Tentacles once their targets are reachable by runners.