Adding an identity provider to self-hosted Hoppscotch: what happens to guest-mode collections?

Locking down a self-hosted instance after guest use

The goal is to restrict a self-hosted Hoppscotch Docker deployment so that collections and environments are not reachable by anyone who can open the instance URL, while preserving data a team member created while the instance ran in guest mode.

Self-hosted Hoppscotch moves request data server-side once accounts and workspaces exist, but a Docker install without a configured identity provider may leave the backend reachable to anyone who can open the URL unless access is restricted elsewhere. The transition from guest use to authenticated use is the uncertain part: whether browser local-storage collections migrate to the account, stay browser-only, or surface in a default workspace is not clearly settled and should be verified against the release notes for the version being deployed. This assumes a current self-hosted Docker distribution; exact defaults may differ between deployment layouts.

Open questions

• Does the backend reject unauthenticated API requests when no identity provider is configured, or must access be limited at the network layer?
• When authentication is enabled after guest use, are collections held in browser local storage migrated to the signed-in account, kept browser-only, or dropped?
• Can previously shared collection links be opened without a session once sign-in is enforced?