Connect the app to your server

An account belongs to one server. A teammate who signs up on the managed instance by mistake gets an account and a vault there, and nobody notices until you cannot see them in Members, so the app asks which server before it takes a password.

On first run#

The sign-in dialog opens on "Where do your notes live?" with the managed service and Your own server. Choosing your own asks for the URL and checks GET <url>/health before going further, so a typo is one inline sentence rather than a failure three screens later. The sign-in form that follows names the server it is about to post to, with a Change link back.

Later, or on another device#

Account settings, Connection, with the same health check and the same rules. Changing the server is effectively a sign-out, because sessions are stored per server in the OS keychain, so the app lands on that server's session or signed out if it has none.

Send one link instead of dictating a URL#

Your server serves a connect page that is clickable in chat, which a bare app-scheme link is not. It bounces into the app and asks the person to confirm before connecting, because the link decides where a password gets posted and is therefore treated as untrusted input.

https://<your-server>/open/connect

Behind a reverse proxy with a path prefix, send the prefixed URL and have the proxy set X-Forwarded-Prefix. That header is the only way the server can learn the prefix. The page derives its address from the incoming request, honouring X-Forwarded-Proto and X-Forwarded-Host, and falls back to BETTER_AUTH_URL.

Which URLs are accepted#

• A bare host is given https://, never http://, which would send credentials in the clear.
• An explicit http:// is honoured for a LAN or localhost server.
• A path prefix is kept.