What problem will this feature address?
As of now, the only way to add environment variables is by copy/pasting them directly inside the Environment section. Which is kind of enough security consideration since you need access either to the environment directly nor access to the server in order to get theses sensitives data.
But when you have a lot of them to handle, that could be shared between multiple environment or multiple hosting solution, you have to manage them directly inside dokploy instead of getting them from one single source of trust.
Describe the solution you'd like
- Add a setting tab where you can configure the kind of secret hosting
- Add a templating variable like the syntax used to handle project environment
DATABASE_URL=${{project.DATABASE_URL}}, but for secrets.
DATABASE_URL=${{secret('vault', 'DATABASE_URL')
^ Name of the provider
^ variable to get, must be adapted from secret provider to secret provider.
- Maybe one step further for security, but I'm currently not sure about the limitation regarding docker swarm, add a panel where you could add a ro volume with the defined environment inside. (Link what is possible with k8s or other solutions)
Describe alternatives you've considered
As of now, you have to manage them directly inside the environment variable at the project level or the deployment level
Additional context
No response
Will you send a PR to implement it?
Maybe, need help
What problem will this feature address?
As of now, the only way to add environment variables is by copy/pasting them directly inside the Environment section. Which is kind of enough security consideration since you need access either to the environment directly nor access to the server in order to get theses sensitives data.
But when you have a lot of them to handle, that could be shared between multiple environment or multiple hosting solution, you have to manage them directly inside dokploy instead of getting them from one single source of trust.
Describe the solution you'd like
DATABASE_URL=${{project.DATABASE_URL}}, but for secrets.Describe alternatives you've considered
As of now, you have to manage them directly inside the environment variable at the project level or the deployment level
Additional context
No response
Will you send a PR to implement it?
Maybe, need help