SQL Server Database

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:

Supported editions:

• Express (free)
• Web
• Datacenter
• Standard
• Enterprise
• Microsoft Azure SQL Database
• AWS RDS SQL Database

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 can 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 deciding.

If you use a hosted database service, you must create your 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:

1. You must not share the database with any other application.
2. The default schema must be dbo.
3. The database must use a case-insensitive collation (a collation with a name containing “_CI_”).
4. 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 System account) must be a member of the db_owner role for that database.
5. 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 failover. Learn about connecting to listeners and handling failover.

A typical connection string for using a SQL Server AlwaysOn availability group looks like this:

Server=tcp:AGListener,1433;Database=Octopus;IntegratedSecurity=SSPI;MultiSubnetFailover=True

Using Azure Active Directory (AAD) in Azure SQL

Support for Azure Active Directory (AAD) authentication was added in Octopus 2021.1. This includes the ability to use a Managed Identity when connecting to your Octopus database hosted 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

Please read our database administrators guide for more information about maintaining your Octopus database.

Learn more

 - Octopus installation

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback

Page updated on Monday, July 15, 2024