Multiple domains support, per organization

deekerman commented

2026-02-20 08:09:19 -05:00

Owner

Originally created by @arkady-marchenko on GitHub (Aug 15, 2022).

My use case is - i have single deployment of VW, but need support different domains (company1.com, company2.com etc) per organization

I configured VW when primary domain is used for organization 1, but organization 2 accounts are configured to use another 2nd level domain. Previously 1.21 or 1.22 it was working fine. After last upgrade 1.25 i cannot download attachments. According dev console in chrome it is restricted by CORS.

I understand security concern and why that's done. But i think use case has a valid point, so i would like to request support in config or admin panel - allow to specify different domains, either

just global list of allowed domains, e.g. comma separated: company1.com, company2.com
per organization in admin panel

I'm using docker-compose deployment.
VW version is latest at the moment 1.25.2 with web 2.28.1

Originally created by @arkady-marchenko on GitHub (Aug 15, 2022). My use case is - i have single deployment of VW, but need support different domains (company1.com, company2.com etc) per organization I configured VW when primary domain is used for organization 1, but organization 2 accounts are configured to use another 2nd level domain. Previously 1.21 or 1.22 it was working fine. After last upgrade 1.25 i cannot download attachments. According dev console in chrome it is restricted by CORS. I understand security concern and why that's done. But i think use case has a valid point, so i would like to request support in config or admin panel - allow to specify different domains, either - just global list of allowed domains, e.g. comma separated: company1.com, company2.com - per organization in admin panel I'm using docker-compose deployment. VW version is latest at the moment 1.25.2 with web 2.28.1

deekerman added the

enhancement

low priority

help wanted

labels

2026-02-20 08:09:19 -05:00

deekerman commented

2026-02-20 08:09:19 -05:00

Author

Owner

@BlackDex commented on GitHub (Aug 15, 2022):

What i think we should actually do here is have the attachments use the Host header sent by the client/reverse-proxy to be used to determine the actual domain. This would also help people accessing the vault internally with a different domain then externally for example. But i think that would solve your issue as well, since now it probably sends the link to go to the currently configured DOMAIN variable, instead of using the HOST header.

@BlackDex commented on GitHub (Aug 15, 2022): What i think we should actually do here is have the attachments use the `Host` header sent by the client/reverse-proxy to be used to determine the actual domain. This would also help people accessing the vault internally with a different domain then externally for example. But i think that would solve your issue as well, since now it probably sends the link to go to the currently configured DOMAIN variable, instead of using the HOST header.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@BlackDex commented on GitHub (Aug 21, 2022):

Hmm, it looks like there is some checking done already, but it always uses the configured domain by default.
Only if that domain isn't configured it will look for other ways to determine the host.

Not setting the DOMAIN variable would help for the attachments, but it will break all other items.
There is already a mentioning of this in the meta features requests: Make email and U2F use the same domain-guessing used by attachments. But looking at the code, that isn't quite right currently. Also, there could be some security implications regarding this, so having a list of allowed host's is probably something needed in this case.

Still need to work on this though, only looked at it.

@BlackDex commented on GitHub (Aug 21, 2022): Hmm, it looks like there is some checking done already, but it always uses the configured domain by default. Only if that domain isn't configured it will look for other ways to determine the host. Not setting the DOMAIN variable would help for the attachments, but it will break all other items. There is already a mentioning of this in the meta features requests: `Make email and U2F use the same domain-guessing used by attachments`. But looking at the code, that isn't quite right currently. Also, there could be some security implications regarding this, so having a list of allowed host's is probably something needed in this case. Still need to work on this though, only looked at it.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@arkadym commented on GitHub (May 11, 2023):

Just courious, any news. It is quite important for me support multiple domains.

@arkadym commented on GitHub (May 11, 2023): Just courious, any news. It is quite important for me support multiple domains.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@BlackDex commented on GitHub (May 11, 2023):

There is no actual work done on this. At least not by me or any other main contributor as far as i can tell (No PR's or something).
Also to be clear, per organization is not something which i think we will support. If someone wants to have domains per organization, then i suggest to run multiple Vaultwarden instance with different domain settings. It's not that Vaultwarden takes up that much resources.

Also, it makes it more secure in the sense that you split the date between the domains/organizations.
I don't think we will ever support built-in multi-tenancy within one environment, as i also do not see the benefits of this.

@BlackDex commented on GitHub (May 11, 2023): There is no actual work done on this. At least not by me or any other main contributor as far as i can tell (No PR's or something). Also to be clear, per organization is not something which i think we will support. If someone wants to have domains per organization, then i suggest to run multiple Vaultwarden instance with different domain settings. It's not that Vaultwarden takes up that much resources. Also, it makes it more secure in the sense that you split the date between the domains/organizations. I don't think we will ever support built-in multi-tenancy within one environment, as i also do not see the benefits of this.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@arkadym commented on GitHub (May 11, 2023):

Sure, but previously it was working fine. I mean there was no issue with attachments. So is there hope to at least allow it work again ? Something simple will work, e.g. list of domains instead of single fqdn name ?

@arkadym commented on GitHub (May 11, 2023): Sure, but previously it was working fine. I mean there was no issue with attachments. So is there hope to at least allow it work again ? Something simple will work, e.g. list of domains instead of single fqdn name ?

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@BlackDex commented on GitHub (May 11, 2023):

Well, a well written PR on this is always welcome.

@BlackDex commented on GitHub (May 11, 2023): Well, a well written PR on this is always welcome.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@arkadym commented on GitHub (May 11, 2023):

Heh, one day may be i could do that, little bit issue here - never write line of code in Rust... :)

@arkadym commented on GitHub (May 11, 2023): Heh, one day may be i could do that, little bit issue here - never write line of code in Rust... :)

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@Ramalama2 commented on GitHub (Jun 27, 2023):

There is no actual work done on this. At least not by me or any other main contributor as far as i can tell (No PR's or something). Also to be clear, per organization is not something which i think we will support. If someone wants to have domains per organization, then i suggest to run multiple Vaultwarden instance with different domain settings. It's not that Vaultwarden takes up that much resources.

Also, it makes it more secure in the sense that you split the date between the domains/organizations. I don't think we will ever support built-in multi-tenancy within one environment, as i also do not see the benefits of this.

Hey blackdex, first i wannt to thank the contributors for vaultwarden, you/dani/ and everyone else :-)

Second, you tell to use multiple vaultwarden instances, which is in my opinion not a big deal either, since vaultwarden doesn't consumes any ressources in my opinion.
But im asking because, did you wanted to point out, that we can share passwords with different people from different vw instances ?
If that's the case, then there is really no reason to not spin up vw multiple times.
If it's not the case, then that's what the op probably need/want/etc...

Cheers

@Ramalama2 commented on GitHub (Jun 27, 2023): > There is no actual work done on this. At least not by me or any other main contributor as far as i can tell (No PR's or something). Also to be clear, per organization is not something which i think we will support. If someone wants to have domains per organization, then i suggest to run multiple Vaultwarden instance with different domain settings. It's not that Vaultwarden takes up that much resources. > > Also, it makes it more secure in the sense that you split the date between the domains/organizations. I don't think we will ever support built-in multi-tenancy within one environment, as i also do not see the benefits of this. Hey blackdex, first i wannt to thank the contributors for vaultwarden, you/dani/ and everyone else :-) Second, you tell to use multiple vaultwarden instances, which is in my opinion not a big deal either, since vaultwarden doesn't consumes any ressources in my opinion. But im asking because, did you wanted to point out, that we can share passwords with different people from different vw instances ? If that's the case, then there is really no reason to not spin up vw multiple times. If it's not the case, then that's what the op probably need/want/etc... Cheers

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@Tacioandrade commented on GitHub (Nov 5, 2024):

But im asking because, did you wanted to point out, that we can share passwords with different people from different vw instances ?

I am also interested in the multiple domains option for this reason.

I currently have a Vaultwarden instance running with my personal domain, but I would like to use the domains of some clients, so that they can also register their passwords in my instance and that I can have access to these passwords in my Vaultwarden.

I would like this, because today I have 5 clients who have shown interest in using Vaultwarden to manage their IT passwords, but they do not want to use my domain, they would like to use their domain, so that their users have access, without knowing that I am managing them.

The idea is for IT to manage the passwords and share passwords and documentation of servers and services with me and share with users some passwords that they need to have access too, such as authentication of shared services among employees in a sector, but in a centralized way, making it easier if I need to change this password, everyone has access to the new password at the same time.

If it were possible to do something like Password Federation between multiple Vaultwarden instances, it would work, but in my opinion, this would be much more complex than supporting multiple domains in the same instance as is done in owncloud/nextcloud, where we define in the administrative panel or in the configuration file, all the domains that are allowed to access the application.

@Tacioandrade commented on GitHub (Nov 5, 2024): > But im asking because, did you wanted to point out, that we can share passwords with different people from different vw instances ? I am also interested in the multiple domains option for this reason. I currently have a Vaultwarden instance running with my personal domain, but I would like to use the domains of some clients, so that they can also register their passwords in my instance and that I can have access to these passwords in my Vaultwarden. I would like this, because today I have 5 clients who have shown interest in using Vaultwarden to manage their IT passwords, but they do not want to use my domain, they would like to use their domain, so that their users have access, without knowing that I am managing them. The idea is for IT to manage the passwords and share passwords and documentation of servers and services with me and share with users some passwords that they need to have access too, such as authentication of shared services among employees in a sector, but in a centralized way, making it easier if I need to change this password, everyone has access to the new password at the same time. If it were possible to do something like Password Federation between multiple Vaultwarden instances, it would work, but in my opinion, this would be much more complex than supporting multiple domains in the same instance as is done in owncloud/nextcloud, where we define in the administrative panel or in the configuration file, all the domains that are allowed to access the application.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@BlackDex commented on GitHub (Nov 5, 2024):

Your scenario has one major issue with mails send by the server in een automatic way. those mails currently will be sent by the main domain. For this to work we would need to somewhere register the last used domain visited/used by this user maybe.

But it will make it more complex.

@BlackDex commented on GitHub (Nov 5, 2024): Your scenario has one major issue with mails send by the server in een automatic way. those mails currently will be sent by the main domain. For this to work we would need to somewhere register the last used domain visited/used by this user maybe. But it will make it more complex.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@Tacioandrade commented on GitHub (Nov 5, 2024):

This wouldn't be a big problem if I used a generic email address if that's
the case. I would use an @gmail.com email address and not put anything that
would make it seem like it was from my company.

Em ter, 5 de nov de 2024 18:20, Mathijs van Veluw @.***>
escreveu:

Your scenario has one major issue with mails send by the server in een
automatic way. those mails currently will be sent by the main domain. For
this to work we would need to somewhere register the last used domain
visited/used by this user maybe.

But it will make it more complex.

—
Reply to this email directly, view it on GitHub
https://github.com/dani-garcia/vaultwarden/issues/2690#issuecomment-2458171578,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFILVFYV43PNOCSLYFBKHDZ7EZBDAVCNFSM6AAAAABRHN3GYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJYGE3TCNJXHA
.
You are receiving this because you commented.Message ID:
@.***>

@Tacioandrade commented on GitHub (Nov 5, 2024): This wouldn't be a big problem if I used a generic email address if that's the case. I would use an @gmail.com email address and not put anything that would make it seem like it was from my company. Em ter, 5 de nov de 2024 18:20, Mathijs van Veluw ***@***.***> escreveu: > Your scenario has one major issue with mails send by the server in een > automatic way. those mails currently will be sent by the main domain. For > this to work we would need to somewhere register the last used domain > visited/used by this user maybe. > > But it will make it more complex. > > — > Reply to this email directly, view it on GitHub > <https://github.com/dani-garcia/vaultwarden/issues/2690#issuecomment-2458171578>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAFILVFYV43PNOCSLYFBKHDZ7EZBDAVCNFSM6AAAAABRHN3GYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJYGE3TCNJXHA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@BlackDex commented on GitHub (Nov 6, 2024):

It isn't specifically the from address, but the domain used for links in the emails.

@BlackDex commented on GitHub (Nov 6, 2024): It isn't specifically the from address, but the domain used for links in the emails.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@Tacioandrade commented on GitHub (Nov 6, 2024):

It isn't specifically the from address, but the domain used for links in the emails.

Got it! I really hadn't thought of that, it really doesn't work that well, thank you very much for that explanation, you are right.

@Tacioandrade commented on GitHub (Nov 6, 2024): > It isn't specifically the from address, but the domain used for links in the emails. Got it! I really hadn't thought of that, it really doesn't work that well, thank you very much for that explanation, you are right.

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@Neustradamus commented on GitHub (Nov 20, 2024):

There is a PR here:

https://github.com/dani-garcia/vaultwarden/pull/3870

@Neustradamus commented on GitHub (Nov 20, 2024): There is a PR here: - https://github.com/dani-garcia/vaultwarden/pull/3870

deekerman commented

2026-02-20 08:09:20 -05:00

Author

Owner

@BlackDex commented on GitHub (Nov 20, 2024):

There is a PR here:

* [Multiple domains support #3870](https://github.com/dani-garcia/vaultwarden/pull/3870)

Which still doesn't solve the domain for the emails in this case.

@BlackDex commented on GitHub (Nov 20, 2024): > There is a PR here: > > * [Multiple domains support #3870](https://github.com/dani-garcia/vaultwarden/pull/3870) Which still doesn't solve the domain for the emails in this case.

Rows
Columns

Multiple domains support, per organization #1350