[GH-ISSUE #5643] [feature]: Optional External Secret Storage for Self-Hosted Deployments #2187

New issue

Open

opened 2026-03-16 23:30:28 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 23:30:28 +03:00

Owner

Originally created by @roopepaajanen on GitHub (Dec 2, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5643

Is there an existing issue for this?

I have searched the existing issues

Summary

We would like to request support for storing environment variable secrets in an external database when running Hoppscotch in a self-hosted environment. Currently, secrets are stored only within the local client, which resets them whenever users switch between clients (e.g., browser → desktop app). This creates friction for teams who rely on multiple access points.

Problem Description

In the current design, Hoppscotch intentionally does not persist secrets outside the client to ensure security and prevent unintended data sharing. However, in self-hosted setups—where organizations fully control the infrastructure—this limitation results in:

Re-entering secrets whenever switching devices or clients
Decreased usability for teams working across different environments
Inconsistent user experience in enterprise workflows

For organizations with established secure storage practices, this becomes a significant usability obstacle.

Proposed Solution

Introduce an optional configuration for self-hosted Hoppscotch instances that allows secrets to be saved in an external, user-managed database. This could be implemented as:

A toggle in environment configuration (e.g., ENABLE_EXTERNAL_SECRET_STORAGE=true)
Support for storing encrypted secrets in a database controlled by the self-hosted deployment
Clear documentation outlining security implications and recommended setups

Originally raised in https://github.com/hoppscotch/hoppscotch/issues/5580

Why should this be worked on?

This feature would enable enterprises to balance usability and security according to their own internal policies.

Benefits

Improved user experience across browser and desktop clients
Consistent secret availability within the same self-hosted environment
Alignment with enterprise-grade workflow and infrastructure standards
Optional behavior—default security model remains unchanged

Originally created by @roopepaajanen on GitHub (Dec 2, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5643 ### Is there an existing issue for this? - [x] I have searched the existing issues ### Summary ## Summary We would like to request support for storing environment variable secrets in an external database when running Hoppscotch in a self-hosted environment. Currently, secrets are stored only within the local client, which resets them whenever users switch between clients (e.g., browser → desktop app). This creates friction for teams who rely on multiple access points. ## Problem Description In the current design, Hoppscotch intentionally does not persist secrets outside the client to ensure security and prevent unintended data sharing. However, in self-hosted setups—where organizations fully control the infrastructure—this limitation results in: - Re-entering secrets whenever switching devices or clients - Decreased usability for teams working across different environments - Inconsistent user experience in enterprise workflows For organizations with established secure storage practices, this becomes a significant usability obstacle. ## Proposed Solution Introduce an **optional** configuration for self-hosted Hoppscotch instances that allows secrets to be saved in an external, user-managed database. This could be implemented as: - A toggle in environment configuration (e.g., `ENABLE_EXTERNAL_SECRET_STORAGE=true`) - Support for storing encrypted secrets in a database controlled by the self-hosted deployment - Clear documentation outlining security implications and recommended setups Originally raised in https://github.com/hoppscotch/hoppscotch/issues/5580 ### Why should this be worked on? This feature would enable enterprises to balance usability and security according to their own internal policies. ## Benefits - Improved user experience across browser and desktop clients - Consistent secret availability within the same self-hosted environment - Alignment with enterprise-grade workflow and infrastructure standards - Optional behavior—default security model remains unchanged