Recommended Octopus setup for multiple teams

We are working to provide Octopus Deploy as a centralized service to multiple development teams within our organization. Usage could scale up to as many as 20 teams with 3-5 environments each, 100 total users, 400 projects, and 200 agents.

We are considering the setup options below. Which would be recommended from a performance perspective? Is load-balancing the Octopus Server as described in options #3 and #4 possible with version 2.x?

  1. One server with one default Octopus instance using the embedded database. (Default configuration.)

  2. One server with multiple Octopus instances (one per team), each instance using a separate embedded database.

  3. Multiple servers with one default Octopus instance per server, all using the same external database.

  4. Multiple servers, each with multiple Octopus instances (one per team), with one external database per team. All instances for each team would use the same external team database.

Hi Adam,

Will there be much in common between the teams? Will they all be deploying to the same environments/servers, for example?

If so, option 1 would be the way to go. Otherwise, I’d look at option 2.

Option 3 and 4 should be possible - we’ve made it possible to run Octopus with an external RavenDB database, but it’s not a scenario we have tested for a while.

The good news is that migrating between options 2, 3 and 4 is pretty straightforward whatever you decide - perhaps start with 2 and scale out if needed?

Hope that helps,


Thanks Paul. We tried setting up an external RavenDB database, but we’ve run into an issue with creating new users. Any new user created in the external database gets an “Invalid username or password” error when attempting to log in. We can confirm that the users are being created successfully on the external server using Raven Studio, and that the usernames are correct.

We’ve noticed that if an existing embedded Octopus database is exported and imported into the external server, existing users can log in fine. Any new users created, however, will be unable to authenticate.

We’ve been able to repeat this a number of times and are stuck. Any idea what might be causing this issue?

Hi Adam,

We use a number of bundles - mainly the database encryption bundle and the unique constraints bundle - you may need to enable these on your RavenDB server before you create the Octopus database.


Paul, great to know. That didn’t occur to me. I’ve added those bundles and created a new database with those bundles installed. Do I need to tell Octopus what my RavenDB encryption key is for any reason? Does Octopus care what encryption algorithm I use on my external RavenDB server?

Hi Adam,

No, I don’t believe so - Raven manages the encryption itself and they don’t need to use the same key.


Installing the encryption and unique constraints bundles fixed the authentication issue. I can now setup an instance with an external database. However, when I create an identical instance on a second Octopus server and connect it to the same external database, the service shuts down shortly after startup and errors like the one below are recorded in the event log. Is there a certificate or key that I need to copy from the instance on server #1 to the instance on server #2?

2014-03-03 21:42:52.1946 ERROR Unable to load actor from %InstancePath%\OctopusServer\Actors\Clock.pfa; attempting to discard.
System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
at System.Security.Cryptography.CapiSymmetricAlgorithm.DepadBlock(Byte[] block, Int32 offset, Int32 count)
at System.Security.Cryptography.CapiSymmetricAlgorithm.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Security.Cryptography.CryptoStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at Octopus.Shared.Bcl.IO.StreamDisposalChain.Dispose(Boolean disposing) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Bcl\IO\StreamDisposalChain.cs:line 24
at System.IO.Stream.Close()
at System.IO.StreamReader.Dispose(Boolean disposing)
at System.IO.TextReader.Dispose()
at Pipefish.Persistence.Filesystem.ActorStateFile.Deserialize() in c:\TeamCity\buildAgent\work\cf0b1f41263b24b9\source\Pipefish\Persistence\Filesystem\ActorStateFile.cs:line 67
at Pipefish.Persistence.Filesystem.ActorStateFile…ctor(String path, IStorageStreamTransform sst) in c:\TeamCity\buildAgent\work\cf0b1f41263b24b9\source\Pipefish\Persistence\Filesystem\ActorStateFile.cs:line 23
at Pipefish.Persistence.Filesystem.DirectoryActorStorage.TryLoadActor(String pfaFile) in c:\TeamCity\buildAgent\work\cf0b1f41263b24b9\source\Pipefish\Persistence\Filesystem\DirectoryActorStorage.cs:line 45


You can’t connect more than one instance to the same RavenDB database - Octopus just isn’t designed to work that way. What you can do is create multiple RavenDB databases in the same RavenDB server, and connect an Octopus instance to each one.

Hope that helps,


Ah. Options 3 and 4 were meant to describe one instance on each server using the same external RavenDB database, effectively scaling those instances out to multiple servers. Sounds like that’s not supported after all.

Thanks for clarifying!