How Your Local Account Works

The self-hosted appliance and the Glassy cloud are two separate systems. They share your account email and the self-host token that anchors the appliance to that account. This lesson explains exactly what happens at boot, at login, and offline.

What the cloud sees

The appliance sends your email and the self-host token you control to the configured verification instance (app.glassy.fyi, or clear.glassy.fyi for Clear accounts). The cloud checks that the email owns a Glassy account and that the token matches, then replies with a simple yes/no. Any account tier qualifies, Free included. That is the whole cloud relationship.

• No passwords exchanged
• No note content, bookmarks, or captures sent
• No usage telemetry

The verification lifecycle

First boot

1. The appliance starts, seeds the local owner account from GLASSY_MEMBER_EMAIL, and generates a one-time local password.
2. It reads GLASSY_SELFHOST_TOKEN and checks the email/token relationship with GLASSY_VERIFY_CLOUD_URL.
3. A successful check records membershipState: verified; a failed or unavailable check records degraded and logs the reason.
4. In both cases the local workspace is available. Cloud connectivity changes the status notice, never ownership of your local database.

Every 30 days

The account check repeats about every 30 days. Between checks, the cached result is trusted. This means:

• You can go offline for up to 30 days without changing status
• After 30 days, the appliance tries the cloud once to re-verify
• If verification fails (network issue, rotated token, unavailable cloud), the appliance shows a degraded notice but doesn’t delete your data or block local login

Every login after first boot

100% local. The appliance authenticates you against its own SQLite database using a JWT signed with your JWT_SECRET. No cloud call happens during login — the cloud only confirmed your membership at boot.

Your email → Cloud: "membership active?" → Yes (cached 30 days)
                                                  ↓
First boot → Create local admin (random password, printed once)
                                                  ↓
Every login → Local JWT auth → No network, no phone-home

Registration is permanently disabled

The appliance enforces registration lockdown at multiple layers — this is not a setting you can toggle off:

• server/index.js forces allowNewAccounts=false on every boot
• /api/admin/allow-registration hardcodes false
• /api/auth/settings hardcodes false
• /api/auth/register returns a hard 403 REGISTRATION_DISABLED as its first check, before any other gate

This is defense-in-depth. Even if the database drifts, the server re-enforces lockdown on every boot. Only the seeded admin account can sign in.

Working offline

Within the 30-day verification window, the appliance works fully offline:

• Notes, captures, and search — all local, no network needed
• Browser WebGPU AI — runs in your browser, offline
• Ollama — runs on your server, offline
• Companion captures — the extension connects to your local instance

The only thing that uses the cloud is the periodic account re-verification. If you know you’ll be offline for more than 30 days, re-verify before disconnecting if you want the status to stay verified.

What’s next?

Learn about configuration and multi-device access — environment variables, ports, CORS, and accessing Glassy from your phone via Tailscale.