Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Document the settings surfaces that affect account security and third-party integrations.

​
Prerequisites

  • A signed-in account

​
Workflow

1
Use the Security tab for password changes, session review, and session revocation.
2
Use the Connections tab for GitHub installation state and connection management.
3
Follow the passkey release requirements below before enabling two-factor protection.

​
Passkey protection — awaiting release

Implemented locally; not yet deployed. After the matching release, open Settings → Security → Passkeys to add account-wide two-factor protection. Sign in again first if asked. Give the passkey a name, approve your device prompt, and save the ten recovery codes shown once. Password and Google/GitHub sign-in remain the first step. Enrolled accounts must then verify a passkey with device verification (for example Windows Hello, Touch ID or the device PIN), or use a one-time recovery code. Availability depends on the browser and authenticator. A compatible security key or phone can be chosen in the browser prompt. Biometrics and private keys are never sent to StackShift. The same account protection covers Hosting, Mail, Assets, Support and platform admin at ops.stackshift.cloud. Support and admin return through the shared account verification page to their original product. Browser-based CLI/MCP authorization is protected too. Previously issued API tokens and agent credentials retain their existing permissions; review and revoke them separately when responding to an account compromise.
  • Register up to ten passkeys. Add a backup before removing the last key; alternatively explicitly disable protection, which deletes all passkeys and recovery codes.
  • A recent verification (ten minutes) is required for security changes, provider linking/disconnection and agent-connection changes. Interrupted actions are not automatically submitted again; return and review the action.
  • Adding/removing passkeys, disabling protection, or using a recovery code signs out other browser sessions. Recovery codes are hashed, single-use and limited to five attempts per account in fifteen minutes. Replacing the set invalidates every old code.
  • Recovery codes are shown only after enrollment or replacement, with copy/download controls. Store them outside this account. Password resets do not disable passkeys; losing every passkey and recovery code cannot be bypassed through password reset or OAuth.
  • Account security changes are recorded in the existing security log and trigger security email notifications. Email delivery errors are logged; notification delivery is not the enforcement mechanism.

​
Release and origin requirements

Release migration 000582, the API, Hosting frontend (also serves Mail/Assets), Support frontend and admin frontend together. Do not permit enrollment while older API replicas still accept sessions without second-factor checks. No worker, CLI, SDK or node-agent release is needed for this feature. Production uses the stackshift.cloud relying-party ID. FRONTEND_URL and the explicit TRUSTED_BROWSER_ORIGINS allowlist must contain the intended HTTPS frontend origins; no wildcard origins are accepted. Cookies continue to use the existing secure shared-account configuration. Support/admin default to https://stackshift.cloud for verification; VITE_ACCOUNT_ORIGIN can select the local account frontend for development. Local deployments must use one consistent localhost host and cookie domain; do not mix localhost and 127.0.0.1. Do not change the relying-party domain after enrollment: existing credentials are scoped to it. Back up credential/settings/recovery tables with account data. Never roll back to API versions that bypass enforcement for enrolled accounts, or apply the down migration while protection is enabled.

​
Security tab behavior

  • Password changes are first-class and validated in-app.
  • Active sessions can be reviewed and revoked individually or globally.
  • Security log viewing is available; account passkey protection is implemented and awaiting coordinated release.

​
Connections tab behavior

  • GitHub connection state is tied to actual app installations, not just a token toggle.
  • Users can open the GitHub install/manage flow directly from settings.
  • Slack appears as a visible connection surface, but it is not yet at the same maturity as GitHub.

​
Expected result

Users know where to manage account security and integration state without hunting through unrelated product areas.

Connect GitHub

Link GitHub so project-style deployments can pull repositories and deployment metadata cleanly.