Should /home/octopus be a volume mount?


I’m using the following linux volume mounts to persist octopus data across containers:

But what about the octopus home directory: /home/octopus? In the documentation it is mentioned several times to regularly backup this octopus home folder. So I wanted to persist this folder as well with volume mounts.

While this works to add a volume mount for /home/octopus, I get an error when upgrading octopus to a newer version stating that it is 'Unable to parse configuration key ‘Octopus.Storage.MasterKey’ as a ‘Byte[]’.

When I remove the /home/octopus volume mount, upgrading octopus is as easy as: docker-compose down, removing the stopped octopus container, update the octopus image tag to a newer version and docker-compose up. It migrates to the newer version succesfully.

But not so with the /home/octopus volume mount. Why is this, how should I persist the octopus home folder accross containers when I cannot volume mount this folder and upgrade octopus.

Hi @jsvandonk

Thanks for reaching out, and for the great question.

On a containerized install, you will generally want to just pass the data in as env variables, as opposed to having a static/persistent config file. As we encrypt things like the Master key in the config file with a machine-specific DPAPI encryption, it won’t allow decryption from a different machine (like when you pull a new version down) - this is the cause of the error you’re seeing about not being able to parse the configuration key.

For a regular install, it’s a good idea to have a backup of this file, so you can see things like your connection string, but if you have an env file, or that data in your provision script, there isn’t a great need to have it persist between sessions.

Please let me know if you have any further questions, I’ll be happy to help!

Hi Justin!

Just to be clear, you are talking about the Server.linux.config file right?

In my current, containerized, install I use a .env file alongside the docker-compose.yml file to pass in the Octopus parameters. db-connection string, masterkey, license, etc.

So therefor there is no need to persist the /home/octopus folder across containers?

What about the other files inside this folder then? Alongside the Server.linux.config file there are Logs, Telemetry, Tools, VersionControlStoreRepositories, Work folders. Those also doesn’t have to be persisted across containers when updating octopus?

That’s correct, nothing there is vital for persistence. It will all be recreated the next time your bring up your env.

Depending on how mission-critical your Octopus instance is, I could see a case for your logs folder, just in the event that you can’t get a shell on your Octopus server to check them, but as I mentioned, not vital by any means.

Tnx Justin for clearing that up!

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.