See our supported package types.
Originally, Octopus Deploy supported only NuGet packages but that is no longer the case. In version Octopus 3.3 we added support for zip packages, support was added for additional package types.Some and in Octopus 3.5 we added support for Docker images. We will be continuing to support other packaging concepts as they become relevant to the deployment ecosystem.
While some of our documentation may still refer to NuGet packages specifically, all packages are generally treated the same.
On this page:
|Table of Contents|
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)Octopus generally treats all packages the same, so choose the tooling and package type that is easiest for you to create. For example:
- ASP.NET apps (.NET Framework): use OctoPack
- Windows Services (.NET Framework): use OctoPack
- .NET Core apps: use
- Working with TeamCity: use our extension,
octo.exe packor even the built in tools for TeamCity
- Working with VSTS: use our extension and/or
- Just want to package up a folder as-is: use
octo.exe packor just zip it up!
As long as you can create one of our supported packages, you can deploy your application with Octopus Deploy!
When creating your packages you will need to choose a versioning scheme that is supported by Octopus Deploy and suits your needs. Learn about versioning in Octopus Deploy.
Packages are kept in package repositoriespackage repositories (or feeds). 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, etc).
An ASP.NET MVC application, packaged using NuGet for example, would look like this:
- 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