Support tenants as a third dimension to deployments
Currently, a deployment targets a project and an environment.
Some customers have applications that they host for many customers, with each customer having their own set of configuration options applied. Their application may not be designed to support multi-tenancy, and instead is deployed separately for each customer.
To handle this in Octopus currently, they either duplicate the project many times, or they duplicate environments many times.
We should build in the concept of a "Tenant" as a first class concept that can be enabled. Each Tenant will have a name and a set of associated variables. When deploying a project, you'll be able to choose the Tenants to deploy (since each Tenant might need to run different versions of the application).
It should be possible to handle scenarios where many Tenants run on the same set of machines, or where each Tenant has a different machine.

This feature has now been provided in Octopus Deploy 3.4.0 (https://octopus.com/downloads/3.4.0)
See docs http://docs.octopusdeploy.com/display/OD/Multi-tenant+deployment+guide
-
Anonymous commented
Any estimated release date per 3.4 version with Multi Tenant? Thanks in advance
-
Fernando commented
Any estimated release date per 3.4 version with Multi Tenant? Thanks in advance
-
SteveC commented
Does the RFC page accurately describe the set of features inside this future release? Do you have a release date more precise than Q1 of this year?
-
Michael Noonan commented
We have continued the design work on multi-tenant deployments with Octopus based on feedback to the original RFC. Please read and comment on the new RFC blog post proposing Tenant as a first-class concept!
-
Dipesh Mamtora commented
Do you guys do early releases or anything of that sort? I have several hundred projects/environments and managing those has become a pain in the neck! I am really hoping that this feature will be released soon!
-
Anonymous commented
Yes. We need this please.
-
Geert Wielens commented
@paul, the release of this new feature is delayed from the 3.2 to 3.3 release. Will it be finished by the end of this year?
-
Dipesh Mamtora commented
@Paul, Do you have a release date yet? I am really looking forward to this feature. Thanks.
-
Jake Rote commented
Have provided feedback looking forward to seeing some mockups.
-
Richard Simpson commented
Excellent! Feedback submitted! Can't wait to see what ya'll come up with!
-
Josh Kodroff commented
In case people wanted to know when it's coming: http://octopusdeploy.com/roadmap
-
Josh Kodroff commented
Bump again. This is making us have a real tough time modelling our business model.
-
Justin Coon commented
Where do we stand on this?
-
Richard Simpson commented
Bump now that 3.0 is out. This is the only real pain point using Octo for us!
-
Anonymous commented
We just pulled in Octopus Deploy thanks to the new offline support and this is the only major issue we have no that prevents us from using this everywhere. We have multiple clients, with multiple machines, whom we're delivering multiple products. Currently we're having to abuse variable sets and enviroments to siimulate this.
-
Patrik Potocki commented
This would be a great feature.
We have a few products that are deployed across lots of clients (with different machines etc) and separate test/uat/production for each client.
-
Jake Rote commented
Is there any plans on how this will be implemented will it be able to draw the tenants from a custom SQL database. Also will it be possible to release to a new tenant without having to release to everywhere? Also will you be able to detect in a powershell script if it is the first time the tenant has been deployed to? Thanks
-
Alex M commented
We really, really need this as well. Having close to a hundred customers who are all running in their own IIS process and own SQL database the tenant concept is critical. 99% of the configuration is the exact same, only IIS site name, custom directory and connection strings change.
-
Alexander Efimov commented
Maybe a "tenant" dimension should be added under "environment" dimension?
In my case we have several environments and several software installations on each of them with a separate set of variables/values. Now we have to create a separate environment for each of the installation (with the same hosts set) and add this environment to variables scope.
What I want is to be able to create a "tenant" inside a single environment for each installation. It will make environments equal to "real" environments and "tenants" equal to software installations. So we'll have an ability to add "tenants" without changing variables scope and have a new installation on the environment.Also it would be good to include tenant name and other possible parameters into system variables and include an ability to specify tenants as a part of scope to variables.
-
Dennis Velthuis commented
As discussed with Paul before, does this also solve our situation where:
- We have many different customers
- Each customer have custom DTAP street
- Some have an Acceptance environment, some not.
- Each customer has their own set of dedicated machines (webservers)
- We develop custom applications (web applications) for each customer (not shared)It would be great if we could at least create a custom DTAP environment per project.
I am not sure if this issue also solves our scenario?