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

When planning your Octopus installation, you will need to decide how to host your packages. Your continuous integration server should create your packages, and publish them to a package repository.

Supported package and repository types

Icon

The Octopus built-in repository supports several different types of packages. If you would like to use a package type other than NuGet (zip or tag.gz for example) you must use the Octopus built-in repository.

If you would like to use an external repository, the only external repository type supported are NuGet feeds (either HTTP or file-system based feeds). If you want to use an external repository, you must use NuGet packages.

On this page:

Your package repository will typically be:

Mix and match feeds

Icon
Octopus can consume packages from multiple feeds at once if necessary.

NuGet v3 feed support

Icon

Support for NuGet v3 external feeds was introduced in Octopus Deploy 3.4.

Earlier releases of Octopus Deploy only support external NuGet v2 feeds:

  • If you are using a MyGet external feed, please use the v2 API URL or upgrade to Octopus 3.4 (or later)

VSTS Package Feeds

Icon

If you are using VSTS Package Management, Octopus can consume either the v2 or v3 NuGet feeds.

Choosing the right repository

Icon

The Octopus built-in repository is generally the best choice for deployment packages because it offers better performance and most suitable retention policies.

Our recommendation is to use different repositories for different purposes, and each repository provides different benefits. A typical example is where you produce your own application library packages in addition to your own deployment packages:

  • For application library packages consider using the repository provided by your build server, a file-share, or something like MyGet or VSTS Package Management.
  • For deployment packages consider using the Octopus built-in repository (see below).

This configuration will make it easier to find the right packages for the right purpose, but the most important benefit of the built-in repository is that Octopus Deploy knows exactly which deployment packages are still required according to the retention policies you have configured, and which packages can be cleaned up. 

Using the built-in repository

Your Octopus server comes with a built-in repository which is the best choice for deployment packages. It offers better performance for your deployments and the most robust retention policy support for deployment packages.

Built-in feed can only be consumed by Octopus

Icon

It is important to understand that the Octopus server provides a write-only repository; intended for hosting deployment packages only. Packages that are pushed to the Octopus server can't be consumed by other NuGet clients like Visual Studio. If you need a NuGet feed for sharing libraries between your development projects, a separate NuGet repository is required.

Pushing packages to the built-in repository

We offer several ways to add packages to the built-in repository, so many that we built a new page: pushing packages to the built-in repository. Alternatively you can go to Library > Packages which describes some of the most convenient ways to push packages to the built-in repository.

Icon

To push packages to the built-in repository you will need an Octopus API key.

Security considerations

To add a new package to the built-in feed requires the BuiltInFeedPush permission. To delete a package, or replace an existing package requires the BuiltInFeedAdminister permission.

For your convenience Octopus Deploy provides a built-in role called Package Publisher that has been granted the BuiltInFeedPush permission.

Consider using a Service Account

Icon

Instead of using your own API key, consider using a Service Account to provide limited permissions since packages will normally be pushed by an automated service like your build server. Service Accounts are API-only accounts that cannot be used sign in to the Octopus Deploy web portal.

Using automatic release creation?

Icon
If you are using automatic release creation you will also require the permissions to create a release for all of the relevant projects in the required environments. To diagnose issues with pushing packages used for automatic release creation follow the troubleshooting guide on the automatic release creation page.

Moving the location of the built-in repository

In 3.0 you can now configure the directory that these packages are kept in. You will need to follow the steps below or you may lose some data.

  1. Stop your Octopus Server service
  2. Update the path location using the following command

  3. Move your files from the old path (default is:  C:\Octopus\Packages) to your new location
  4. Restart the Octopus Server service

The restart of the service will re-index the directory. If it is missing files, they will then go missing from the internal repository and again from your releases. So be sure that all files are moved.

Using external repositories

Only NuGet feeds are supported

Icon

The only external repository type supported is NuGet. If you wish to use an external repository, you must use NuGet packages.

NuGet v3 feed support

Icon

Support for NuGet v3 external feeds was introduced in Octopus Deploy 3.4.

Earlier releases of Octopus Deploy only support external NuGet v2 feeds:

  • If you are using a MyGet external feed, please use the v2 API URL or upgrade to Octopus 3.4 (or later)

If you're using an external NuGet feed, you can register it with Octopus and use them as part of your deployments. Go to Library > External feeds

You can add NuGet feeds by clicking the Add feed button. 

In the URL field, enter the HTTP/HTTPS URL to the feed, or the file share or local directory path. Then click Save and test

On the test page, you can check whether the feed is working by searching for packages: 

NuGet.Server performance

A popular external NuGet hosting option is NuGet.Server. However, be aware that it suffers from performance problems when dealing with large packages or large numbers of smaller packages. Users may report high CPU usage, timeouts when displaying package details, or memory issues. A great alternative that we recommend is NuGet.Lucene

The built-in NuGet server in Octopus stores metadata in SQL Server, and doesn't suffer from these performance issues.

Troubleshooting

  • For network file shares, keep in mind that Octopus and Tentacle run under system accounts by default, which may not have access to the file share
  • NuGet.Server only allows 30MB packages by default

 

  • No labels