Introducing Octopus, my MicroISV

Octopus Deploy is now a 1.0, available from

A few weeks ago I posted some screenshots of an application I'm working on. A few people guessed, rightly, that it is a tool for automated deployment. Progress is going well, so I'd like to share some more details, and get your feedback.

Octopus is a automated deployment solution for .NET applications, powered by NuGet and designed for convention over configuration.

  • Deploy Web applications and Windows Services
  • Configure your applications automatically
  • Works inside your network or over the internet, securely
  • Track and report on how releases are promoted between environments

I'm working my way through the SecretGeek 25 things list, and writing plenty of code. My goal is to have Octopus ready for beta testing in a few weeks. If you'd be interested in taking Octopus for a spin, add your email address below. I promise to only send occasional updates as the beta program opens.

Subscribe to our mailing list

* indicates required

Where Octopus fits in

Imagine your development team has been charged with building an intranet web solution. The solution consists of:

  • An ASP.NET MVC web site
  • A SQL Server database
  • A Windows Service for performing some long-running tasks

The team are working iteratively. They check code into source control, and the build server picks up the code, compiles it, and produces artefacts ready to be deployed. Now, someone has to figure out how to deploy it.

Every application has different deployment needs, but they are usually pretty similar:

  1. The CI server builds the code and products artefacts (Zip files, WebDeploy packages, MSI's, etc.)
  2. The artifacts are copied and extracted on the target server(s)
  3. Web/App.config settings and connection strings are updated
  4. Performance counters and event log entries are created
  5. IIS web sites are configured
  6. Windows Services are installed and started

Ideally, these deployment steps would be automated. Unfortunately automating these deployments still takes a lot of manual work. Usually the solution is a cobbled together band-aid solution of PowerShell scripts, XPath queries, batch files and point-and-click tools.

Once you've cobbled together the PowerShell scripts and MSI packages for your application, zoom out, and look at the rest of your organization. How many other projects do you have? How many of them have automated deployment? How different is the deployment process for each application? Does it need to be this hard?

Octopus in action

Here's where Octopus fits in a typical organization:

Octopus in your enterprise

  1. Developers check code into source control
  2. The CI server (TeamCity, TFS, CCNet, whatever) compiles the code, and packages it into NuGet packages (I'll explain why below)
  3. The NuGet packages are exposed via a NuGet feed to Octopus
  4. A release manager commands Octopus to deploy a "release" of your application to an environment (staging, production, etc.)
  5. Octopus assembles all the NuGet packages, and pushes them to a "Tentacle", a small Windows Service that runs on your UAT/staging/production machines.
  6. The Tentacle agent deploys the NuGet package, and configures it (see below)


Octopus understands a few simple concepts:

  • Package: A NuGet package containing the smallest unit of deployment for part of your solution (for example, YourApp.Web, YourApp.Database)
  • Project: A group of packages and deployment steps, for example, YourApp
  • Release: A set of packages, with versions, for a project. For example, YourApp release 1.5 contains packages YourApp.Web 1.5.3 and YourApp.Database 1.5.1
  • Machine: A computer running the Tentacle service, that you intend to deploy packages to
  • Environment: A collection of computers, such as Staging or Production

Most of these concepts should be pretty intuitive from the UI - my goal is to make the release process pleasurable. Check out some of the screenshots to see where it's going.

Environment definition in Octopus

Convention over configuration

Octopus was inspired by AppHarbor, which performs automated deployment of .NET applications from Git/Mercurial check-ins. AppHarbor has a very clever system for dealing with deployment:

  • If your VS solution has a Web project, it deploys it to an IIS site
  • If your web.config file has AppSettings with names matching variables you declare in the UI, they are automatically replaced

The end result is you never need to write automated deployment scripts for AppHarbor applications - it's automatic, because most applications work the same way.

Octopus shamelessly steals "borrows" these ideas, making enterprise application deployment as easy as cloud deployment on AppHarbor.

Conventions in Octopus include:

  1. Replacing appSettings and configurationStrings entries
  2. Updating the path of IIS websites if your package contains a web.config
  3. Running any System.Configuration.Install.Installers (for performance counters, event logs and Windows Services)
  4. Invoking a "Deploy.ps1" PowerShell script, if your package contains one

The cool thing is that all of these steps are run locally on the target server; you don't need to mess around with configuring WinRM or PowerShell Remoting.

NuGet packages

Instead of MSI's, Zip files or WebDeploy packages, Octopus standardizes on the NuGet package format. There are a few reasons for this:

  1. Packaging files into a NuGet package is extremely easy
  2. NuGet packages can be consumed via a feed, so other applications can easily query the available packages
  3. CI tools like TFS and TeamCity will soon have support to make publishing NuGet packages easy

At first this might seem like a strange use of NuGet. Currently, NuGet is mostly used for packaging DLL's and other files, mostly for open source components. Why use NuGet for packaging complete web applications or Windows Services?

If you spend time in the world of Linux however, you can see that package managers (like NuGet) have evolved beyond libraries. If you want to install Apache or MySQL on Linux, you'll use a package manager. Shouldn't we be able to do the same on Windows?

An aspect of this idea that I think is really interesting is the concept of an internal "enterprise software inventory". Imagine if every version of every internal application you built was available from a NuGet feed, instead of a mix of File Shares, TFS Drops and TeamCity artifacts?

Reports and metrics

Since Octopus takes a pretty holistic view of your projects, environments and releases, it can be used to answer some interesting questions:

  1. How long on average does it take Project A to get from Staging to Production?
  2. How often do Staging releases fail user acceptance testing before going to Production?
  3. Which version of Project A is in UAT right now?
  4. What were the release notes of version 1.4 of Project A?

The business

I've spent a lot of time over the past few years working on open source projects. Open source projects are hard. Getting contributors is tricky, and even when you do, they usually focus on contributing "fun" features rather than bug fixing and documentation. Unless your project is large enough to have a lot of momentum, it's hard to attract committed contributors to do the not-so-fun things.

I think Octopus stands a much bigger chance of succeeding if it has people committed to doing the not-so-fun things, producing a very useful, very high-quality product that you can trust to reliably deploy your software. For this reason (plus, well, greed :-)) Octopus is going to be a commercial product, and my first MicroISV. Even if it's a colossal commercial failure, I'm looking forward to the experience of product development.


At this stage I expect Octopus will be priced using a TeamCity model - free enough that you can use it to deploy one project to your organization, but by the time you need to deploy your second project, you'll have gotten enough value from it that you won't mind sharing the love.

What do you think?

This is one of my longer blog posts, and I hope I've done a good job of explaining what Octopus is all about. I'd like feedback, good or bad, about the direction. Specifically:

  • What do you think about the conventions? Can you think of any others? I've documented them a little better on the knowledge base.
  • Is the system described above something that you could see yourself/your organization using?
  • How are automated releases currently done within your organization?
  • What additional reports/metrics would be useful?
A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool for .NET applications.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

06 Jun 2011

You are trying to solve one of the biggest problems in the .NET / Windows developer community. Wish you luck!

Lee Baker
Lee Baker
06 Jun 2011

Hey Paul,

This looks awesome. I have been meaning to write something very similar but haven't gotten off my arse yet.

I am really keen to try it out in my organisation.

Looking forward to it

06 Jun 2011

How does this compare to

Brad Leach
Brad Leach
06 Jun 2011

Hi Paul,

Can you envision your solution to be able to handle the following scenario: You have an Application (Project) that is deployed many times (one per customer). For each customer, you have multiple Environments (Staging, Production). Additionally, you would have at least one Dev/Test environments which are independent from any customer deployments.

Cheers, -Brad

06 Jun 2011

@Brad, I hope so. Do you deploy to each customer at different times, or do they just have different configuration data?

You would probably build single staging/prod environments for all customers, with different machines in the environment. E.g.,:

  • Staging
    • ClientAWeb01
    • ClientAWeb02
    • ClientBWeb01
    • ClientBWeb02
  • Production
    • ClientAWeb05
    • ClientAWeb06
    • ClientBWeb07
    • ClientBWeb08

Now, if you deploy the same code to all customers at the same time, you would just have one "project", and you'd release that project to all machines on the environment. The only differences would be each client would have different configuration variables, which you would set on a per-machine basis (e.g., ClientA uses SQL Server connection string A, ClientB uses B, etc.).

If you deploy different code to different customers at different times, you'd still have the one set of environments, but you would have multiple projects. So you'd have a "ClientA" project that deployed to ClientA machines, and a "ClientB" project for the other machines.

Alternatively, you could set up a different "environment" for each client. Then you could deploy your project into each client environment individually. Currently the UI might not look so nice for more than half a dozen environments, so I'll think about how to handle that case.

Lastly, you could just have multiple Octopus installations (I'll make sure there's no licensing disadvantages to this).

I know those are only vague details, but do they give you an idea how it could work?

06 Jun 2011

@Chris, reading the documentation suggests they have similar concepts (environments, machine roles, etc.) but the usage model is pretty different. It seems like you'd spend a lot of time scripting/coding with DropkicK, much as you used to do with CruiseControl.NET. I'm taking more of a TeamCity approach, by having a UI to make setting up projects and environments quicker, as well as for managing the release process. Of course that's just a feeling from reading the little documentation I could find. Are there specific features of DropkicK that you like?

Joseph Cooney
Joseph Cooney
06 Jun 2011

Congratulations Paul - shipping a product is a great accomplishment (which I'm yet to achieve). I'll see if I can convince the SDC to be come a customer...

Jimmy P
Jimmy P
07 Jun 2011

Finally! Thanks Paul, I've been waiting for this one. I really hope it's successful for all of our sakes!

A usage scenario I often see overlooked is funnily enough greenfield apps inside a large team or organisation. Specifically as part of rewrites, or the new better version of the current system type scenarios.

The kinds of things I'd be interested in seeing here are easy ways to cope with evolving environments and project complexity. So it's so easy to start using octopus with for "Hello World" you don't even need to tell management you're doing it. Then from there incrementally building a more mature and sophisticated auto deployment story has a few high friction points as possible.

07 Jun 2011

What we need is a capistrano for .NET maybe with powershell winrm or perhaps using chef and powershell.

Capistrano is an excellent DSL and any solution should check it out thoroughly.

07 Jun 2011

Congratulations Paul!

07 Jun 2011

I haven't used Dropkick yet, just curious your thoughts. Thx!

07 Jun 2011

Nice work, Paul. I really like the idea of using NuGet as the packaging format.

What would be really good is if you could persuade some of the hosting companies to support Octopus deployments.

Also, if you're looking to outsource any of your development, I'd be interested in helping you out.

Robert Vukovic
Robert Vukovic
07 Jun 2011

Go for it. I hope you will succeed.

08 Jun 2011

I'm using beyond compare to deploy over FTP. That way I know exactly what is changed and updated... -- John.

08 Jun 2011

I know that our web.config is dependent on the server IP. We use it in subject of the elmha message that gets sent out. Encription of the web.config after it is deployed would be cool to. What about creating app_offline.htm before install of webapp and deleting after install is done?

If you had two powershell script for pre/post processing of the delivery. It would be simple to accomplish the above activites.

I think with your layout you would be able to acomplish this too: Case 1 you bring a new server( NewBox) onto the farm. You load NewBox with octpus on it. Release Manager then tells octpus to load RequiredDlls project on NewBox Machine. Then Release Manager tells octpus to load MyWebApp project.

Case 2 you add new feature of reports to your webproject. This requries your farm to have a new dll. Update NuGet project for RequiredDlls. Then RepeaseManager tells Enviorment(staging) to refresh RequiredDlls project.

Would you be able to set the time delay as octpus updated each machine in the enviorment? Sometimes you would want the site down while you update everything. Sometimes the change is cosmetic and you would prefer only one machine down at a time.

Are you planning on supporting more than just staging and production enviorments? We have those plus Training, OneDayStale.

Amazing work.

Marcel Popescu
Marcel Popescu
08 Jun 2011

Can't wait for the beta to start...

08 Jun 2011

Hard problem to solve, you seem to understand it. I hope you will think about all the details... Here's a nice one to think about (if you haven't already):

What if v1 has a file that is a security risk and v1.1 deletes the file. There is no way for NuGet to express this change, you have to check the repository commit history for that. So NuGet isn't that smart (yet). And before you think that removing all files that aren't in the v1.1 package solves the problem, let me warn you that your software then will delete some random /upload folder and all its contents since that wasn't in the package either. Now you have to compare packages, harder problem, needs solving, ask money when you solve it, because I think it would be worth a lot!

Good luck, I'm following this project.

PS. Also be aware that some CMS-type applications (think SharePoint) have their own solution and it will probably never play nice with your system.

08 Jun 2011

Looks really good, can't wait to hear some more.

08 Jun 2011

You mention this as a scenario for this product:

What were the release notes of version 1.4 of Project A?

Can you please explain more about that?

09 Jun 2011

@Mike, @Pete,

The way I deal with NuGet packages is actually to deploy them side by side.

So after deploying 1.1 you'd have:


For web sites, if there's an IIS Web Site called "MyApp", I find it and change the Home directory to \MyApp.1.1. Then I IISRESET that site.

So you shouldn't need app.configs, and old files from 1.1 no longer exist.

Now, there's a problem here - what if your app allows people to upload files underneath your app, or relies on App_Data? My answer for v1 will probably just be "tough" - automated deployment has endless possibilities, so v1 will be pretty opinionated.

Dave Welling
Dave Welling
09 Jun 2011

Keenly interested. I'd definitely check it out for our web deploy needs. Interested in the rollback story.

09 Jun 2011

I run a couple of small sites and have found things like Team City and Cruise Control to do the job, but are far from simple and intuitive. If you can bring a new tool to the stack that is simple and intuitive then you'll have a customer in me.

09 Jun 2011

This sounds like exactly what my organization is missing ;-)

Good luck! Looking forward to playing with the beta.

Johannes Gustafsson
Johannes Gustafsson
09 Jun 2011

Very interesting. How about partial releases? For example, if i fix a bug in one web application then I'm only interested in deploying that specific component. Or, if I have many machines, I want to deploy one windows service to one machine first and make sure it works before I deploy it to the others.

09 Jun 2011

Sounds cool Paul! We are currently using the Tarantino deployment (pstrami) tools. It works fairly well, but this sounds much cleaner. Looking forward to seeing what you come up with.

Johannes Gustafsson
Johannes Gustafsson
09 Jun 2011

Very Interesting. Will it be possible to deploy individual components in a release? For example, I fix a bug in a web application and I want to only update that particular component because all others are unaffected. Or, I have a component distributed among many machines and want to deploy it to one machine first to make sure everything works before i deploy it to the other machines.

09 Jun 2011

Octopus looks awesome and definitely pretty sweet because it has quite a bit more convention so it can get you what you need without a lot of setup!

To the others on how DropkicK (dk) compares - dk has a phenomenal DSL (and is probably a lot closer to capistrano). If you need finer grained control over a deployment, then dk is probably closer to what you need versus octopus.

DK wiki shows that you can run a deploy reducing the roles using predefined settings: dk.exe execute /environment:LOCAL /roles:Web,Host

DK gives someone quite a bit more power over the actual deployment configuration (below is an actual deploy abbreviated for space - Full Gist here):

Define(settings =>
     s =>

    s =>

     s.Security(securityOptions =>
       securityOptions.ForPath(settings.WebsitePath, fileSecurityConfig => fileSecurityConfig.GrantRead(settings.WebUserName));
       securityOptions.ForPath(@"~\C$\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files", fs => fs.GrantReadWrite(settings.WebUserName));
       securityOptions.ForPath(@"~\C$\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files", fs => fs.GrantReadWrite(settings.WebUserName));
09 Jun 2011

Interesting -- we are currently using Inedo's BuildMaster, which already gives us this pretty easily. It doesn't packaging things in NuGet format... but I guess that's an implementation detail? Aside from that, how will this compare?

10 Jun 2011

Will this be a viable solution for non-web applications? Say a few TopShelf hosted services and xopy deployed wpf-applications? The .config file conventions looks very usable in this scenario too...

10 Jun 2011

@Peter, yes. I run any System.Configuration.Install.Installer classes, such as ServiceInstaller/ServiceProcessInstaller, EventLogInstaller and so on. You could also install the service using the Deploy.ps1 script.

For WPF applications it will work, but it depends how many clients you have, and how often they change. For ClickOnce applications your deployment might be to copy it to a file share/web folder, but it probably isn't suitable for pushing releases to a salesperson's work laptop.

Damian Powell
Damian Powell
12 Jun 2011

What a great idea. I look forward to taking it for a test drive.

S. Shawn Mehaffie
S. Shawn Mehaffie
13 Jun 2011

Looks very interesting.

1) I second the suggestion to have a place where pre and post script(s) can be run. These can just be PowerShell scripts that are saved in a particular directory. Would also be nice if parameters could be passed to scripts from application when ran. So you would have to have some way to identify parameter tags and what configuration data they map back to. Users should be able to pick 1 or more scripts to run.

2) To go with #1, have a way to create shared PoweShell scripts that can be used by all projects if needed.

3) Give option to delete files all files before deploying new files.

Look very promising and I like the fact that is uses Nuget to package the deployment files. I think Nuget is quickly becoming the standard for this on the .Net side.

30 Jun 2011

That octopus looks afraid! What's he running from?

28 Jul 2011


When can I buy it? I've been looking for something like this that works easily on the .net platform for quite some time.

The fact it works with NuGet packages is gravy.

Let me know when I can get a download package and test run it on a local server. Awesome idea.