This page is for Octopus Deploy 3.0 and newer versions. You can view this page for Octopus 2.0

Skip to end of metadata
Go to start of metadata

Before you can deploy an application using Octopus, you will need to bundle all of the executables, DLL's, configuration files, installation scripts, and anything else the application needs to run into a package. 

See our supported package types.



Originally, Octopus Deploy supported only NuGet packages. In version 3.3, support was added for additional package types.

Some of our documentation may still refer to NuGet packages specifically.

Creating packages

How you create your packages depends on which package type you wish to create.


There are a few options for creating NuGet packages, detailed here.

.zip and .tar

.zip and .tar are widely supported formats.  They are supported natively on many operating-systems, and there are many third-party utilities available.  

Some Continuous-Integration servers have built-in support for creating .zip and/or .tar archives (e.g. TeamCity)

Hosting packages

Packages are kept in package repositories. A repository can be as simple as a file share, or it could be a dedicated server. For more information, see the section on choosing a package repository

What's in a package?

Octopus expects your NuGet package to contain all of the files needed to run the application when it is deployed (along with any scripts needed for deployment, and any configuration transformation files). 

An ASP.NET MVC application, packaged using NuGet for example, would look like this:

While a Windows Service application might look like this:

Note that in both examples:

  • Only binaries and files needed at runtime are included - C# source code files, for example, are not in the package
  • The binaries aren't just for the current application - they also include any other assemblies needed for the application to run



  • No labels