Octopus Deploy stores projects, environments, and deployment history in a Microsoft SQL Server Database.
SQL Server Database
Octopus works with a wide range of versions and editions of SQL Server, from a local SQL Server Express instance, all the way to an Enterprise Edition SQL Server Failover Cluster or SQL Server AlwaysOn Availability Group, or even one of the hosted database-as-a-service offerings.
The following versions of SQL Server Database are supported and automatically tested against every release of Octopus Server:
|Octopus Server||Minimum SQL Server version||Azure SQL|
|2020.2.x ➜ latest||SQL Server 2016+||Supported|
|3.0 ➜ 2019.13||SQL Server 2008+||Supported|
- Express (free)
- Microsoft Azure SQL Database
- AWS RDS SQL Database
Warning: Octopus does not support database mirroring or SQL Server replication. Having these features turned on may cause errors during configuration. More information.
Using SQL Server Express
The easiest and cheapest way to get started is with SQL Server Express and install the Octopus Server and SQL Server Express side-by-side on your server. This is a great way to test Octopus for a proof of concept. Depending on your needs, you might decide to use SQL Server Express, or upgrade to another supported edition.
Creating the database
The Octopus installation wizard can create the database for you (our recommended method), during the installation; however, you can also point Octopus to an existing database. Octopus works with both local and remote database servers, but it is worth considering the performance implications before making a decision.
If you are using a hosted database service you will need to create your own database and provide Octopus with the connection details.
Create your own database
If you don’t want Octopus to automatically create the database for you as part of the installation process, please note the following:
- The database must not be shared with any other application.
- The default schema must be dbo.
- The database must use a case-insensitive collation (a collation with a name containing “_CI_”).
- If you are using Integrated Authentication to connect to your database:
- The user account installing Octopus must be a member of the db_owner role for that database.
- The account the Octopus Deploy windows server process runs under (by default, the
Local Systemaccount) must be a member of the db_owner role for that database.
- If you are using SQL Authentication to connect to your database, the SQL user account defined in your connection string must be a member of the db_owner role for that database.
Changing the database collation
Learn more about changing the database collation after the initial Octopus installation.
Using SQL Server AlwaysOn
Octopus will work with any of the supported highly available SQL Server implementations.
Make sure the Octopus Server is connecting to the listener which will route database requests to the active SQL Server node and allow for automatic fail over. Learn about connecting to listeners and handling fail over.
A typical connection string for using a SQL Server AlwaysOn availability group looks like this:
Using Azure Active Directory (AAD) in Azure SQL
A typical connection string for using Azure Active Directory Authentication with a Managed Identity looks like this:
Server=localhost;Initial catalog=Octopus;authentication="Active Directory Managed Identity"
Database administration and maintenance
For more information about maintaining your Octopus database, please read our database administrators guide.
Help us continuously improve
Please let us know if you have any feedback about this page.
Page updated on Sunday, January 1, 2023