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.
On this page:
Your package repository will typically be:
- The Octopus server's built-in repository
- A remote feed exposed over HTTP
- A local feed exposed as a File Share or local directory
- A JetBrains TeamCity server (version 7 and above)
- A MyGet server
- A VSTS Package Management feed (see note below)
Choosing the right repository
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.
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.
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
For your convenience Octopus Deploy provides a built-in role called Package Publisher that has been granted the
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.
- Stop your Octopus Server service
Update the path location using the following command
- Move your files from the old path (default is: C:\Octopus\Packages) to your new location
- 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
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:
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.
- 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