How do you compare OctopusDeploy with WebDeploy/MSDeploy?

Hi guys,

Recently I’ve been trying to persuade two teams in my company to utilize OctopusDeploy. However, it turns out that they’ve been planning on using WebDeploy and instruction documents to the internal IT department who would perform the actual deployments.

I plowed through the documentation and samples of WebDeploy and I already knew OctopusDeploy’s docs by heart, but I found it difficult to create an email with which to sell the idea of using OctopusDeploy.

So, my questions to you guys are, in your experience:

  1. What are the major benefits of using WebDeploy/MSDeploy rather than Octopus?
  2. What are the major disadvantages of using WebDeploy/MSDeploy rather than Octopus?

Thank you in advance!

Hi Bobby,

Thanks for getting in touch! The most significant things that come to mind here are:

Visibility - with Octopus, any project stakeholder can see at a glance which releases have been deployed to which environments, when, and by whom. Improving transparency this way makes life easier for everyone and reduces communication overhead across the team.

Repeatablility - using Octopus there’s much less room for human error because a lot more of the process is automated. If a deployment was made successfully to Test, then the same deployment to the Production environment is much more likely to succeed. The same is true between versions - with each release the exact same deployment process can be used, eliminating variations/omissions.

Time - less time reading, writing, revising and communicating documents; out-of-the-box support for many common deployment tasks, access to a growing online library of deployment scripts that others have written and bundled for use with Octopus.

And last but not least, Support - with Octopus you get prompt, personalized support from the people designing and building the product; we’re happy to help out not just fixing issues, but providing tips/advice/assistance to make sure things run smoothly (like this ticket, actually :)). The same is definitely not true for mass-market options like WebDeploy, where support is much less directly accessible.

Hope this helps; best of luck!


Hi Nick,

Thanks a lot for the reply.
As far as Repeatability goes, I was hoping to get some advice more along the lines of “WebDeploy can’t do X, but Octopus can”. A few feature-to-feature comparisons. “WebDeploy is known for problem/shortcoming Y”. I feel that if I don’t provide such concrete examples, they can dismiss my argument saying that with some tweaking WebDeploy can provide repeatability just as well.

Time is the point that I agree the most on. Cross-team communication is a valid concern.
The reusable components (step templates, PowerShell scripts and variable sets) are also a valid advantage.

The Support point is also debatable simply because of the fact that Microsoft are behind WebDeploy - there are technical documentation, blogs, forums and StackOverflow questions. Seeing as how Octopus has those as well, I’d say that the name Microsoft is the only trump card here. In my experience, that can mean a lot or absolutely nothing at all.


Here is a part of the email which I wrote to the team that need to assess if they are going to use OctopusDeploy for their projects:

Reasons why I think WebDeploy and the cross-team deployment instructions hand-off are not a viable solution:

1. As it stands, your proposed deployment scheme doesn’t rely on a continuous build, meaning that there is no clarity as to what version of the deliverables is being deployed to any of the sets of server.

2. Your proposed deployment scheme relies on the manual integration between your team and the internal IT, meaning that they will become a critical resource at a time when you need to perform investigations on problems of an already deployed deliverable.

3. The WebDeploy package and the instructions to the IT team are the places where the deployment details are stored.
How are we going to keep those details under source control in this case?
Are we going to rely on emails, instruction documents and verbal communication in order to keep track the intricacies of the deployment process – steps, changes to files, settings, registry, etc?

4. Using WebDeploy means that you are either relying on an UI for the creation of packages and doing the actual – the IIS Manager or Visual Studio or are using the webdeploy.exe directly.
In my opinion, the first option (UI) cannot be automated in a sensible way.
The second option is hard to keep track of under source control (WebDeploy can accept a very long list of parameters – that’s the only way of keeping track of the packaging details).

5. WebDeploy outcome: success or failure and log files are not visible to everyone taking the responsibility for the deliverable.
There is no “traffic light” quality control and monitoring. Only the output of the WebDeploy.exe or the servers’ Event Viewer.

Here’s other part of the email where I do my assessment on comments from the affected team and my experience with OctopusDeploy which I gained @ my previous company:

1. OctopusDeploy uses a lightweight packaging scheme – NuGet packages (.nuspec specification). They are not as comprehensive as the WebDeploy’s manifest XML files, but are very simple to understand and work with.

2. OctopusDeploy uses a versioning scheme (the same as NuGet’s) – you can only deploy packages which bear a version number.

3. The NuGet packages used for deployments can be saved in a variety of locations: a network folder (drop location), a NuGet server or OctopusDeploy’s built-in NuGet server.
Thus, we can always have a repository from which we can pick and choose versions of the product.
For instance, if the latest version of the website has a critical bug in it, we can take the previous version that was used on Production and deploy it instead.

4. One of the pivotal concepts of OctopusDeploy are the steps – you can have a very well separated deployment process for each set of servers (“dev”, “test”, “production”)

5. In OctopusDeploy, the deployment details are recorded in two “groups”: (projects and underlying steps) and (value changes). Value changes – using either XDT config file transformations, or using PowerShell scripts can easily be put under source control.

6. OctopusDeploy features a web UI where people can configure and monitor the deployment status of various applications on different servers.
There’s a live demo and video tutorials that I can recommend taking a look at.
Creating a deployable release requires the use of a command line tool, but doing the actual deployment to the “dev” server can be automated to be a part of the build process.
Furthermore, deploying to the other environments is done via the web UI and there is detailed logging and auditing available.
Thus, every stakeholder of the product can observe what is the deployment status of a given version on a given environment.

7. WebDeploy has extensive documentation and a dedicated blog. OctopusDeploy has both as well.

8. WebDeploy is free and while OctopusDeploy has a free Community edition, we might end up having to pay for a Professional or Team license, based on the number of deliverables we deploy and the number of servers we deploy to.

9. WebDeploy offers a wide variety of providers which tackle a lot of deployment situations. Octopus offers only a few built-in step templates, but there’s also a community-driven library of step templates.

10. WebDeploy has new versions with new features and bug fixes very rarely, whereas OctopusDeploy is following a clear roadmap and is releasing new versions at a regular pace, improving steadily upon their offering.

I hope that I can attract more attention to this topic in order to help other guys who are facing the bout WebDeploy Vs OctopusDeploy!


Hi Bobby,

Thanks for all the details, sounds like you’re well on top of it!

Regarding feature-by-feature comparisons, the two products are placed quite differently so this is hard to do. You might be be able to point out that Octopus orchestrates the entire deployment process, while WebDeploy is just one way of effecting communication with individual machines. As an illustration - Octopus can actually orchestrate WebDeploy deployments using a step template:!/step-template/actiontemplate-web-deploy-publish-website-(msdeploy)

Best regards,

You’ve got a point there, Nick - WebDeploy does seem to be geared towards creating “a differences package” from one source machine to another one, whereas with Octopus the general deployment orchestration is a primary principle.

The WebDeploy step template is all fine - I did look into it as a part of the investigation.

However, WebDeploy offers a whopping total of 38 providers ( which are akin to the Octopus step templates.
Good news is that some of those WebDeploy providers have equivalent step templates in the Community Library.
The Community Library is also a much more robust resource, because it’s driven by need and demand, so it can grow as quickly as possible to satisfy those.
The WebDeploy provider model IS extensible - another point of comparison - but it isn’t that easy to distribute among the users of the tool.
Here’s a tutorial from the MSBuild man himself - Sayed Ibrahim Hashimi:
"Web Deployment Tool (MSDeploy) Custom Provider Take 1",guid,BD37422C-41B7-450D-ADA5-122251483B53.aspx#0ba5f15c-e8c5-43d6-9104-8b8aa3fe8981

Beast regards,

PS: I still haven’t heard from my colleagues that are to make the call on WebDeploy or OctopusDeploy. Keep yer fingers crossed, lads!!