Skip to content

Signing in

NoCloud keeps the portal private behind the sign-in service configured for your instance. The portal never receives or stores your password or authenticator secret.

Normal sign-in

  1. Open your portal URL.
  2. Enter your account password.
  3. If the instance requires two-factor authentication, enter the current six-digit code from your authenticator.
  4. You return to the page you originally opened.

An expired session is normal. Open the portal again and repeat the same flow. Selecting the sign-in service's remembered-device option extends the session only on that browser/device.

Before a deploy

Run this from the NoCloud checkout:

nocloud auth

It verifies the unauthenticated handoff without needing your password: a protected page must redirect to this instance's login URL, preserve the return URL, and load the login UI. nocloud deploy runs the same check as part of its post-deploy smoke test.

The check deliberately cannot prove a person's second factor: that code stays in the authenticator and is never accepted by NoCloud's CLI or deployment process.

Recovery

If the password screen accepts your password but does not continue, complete the second-factor step. If the code is rejected, check that the device running the authenticator has automatic time enabled. A lost password or authenticator is not recovered from the portal — a NoCloud admin cannot fix it by changing portal data. It's recovered on the server itself; see Recovery & resilience for the exact commands.

Integrating a sign-in service

NoCloud's proxy contract is intentionally small:

  • /auth/ is public and serves the sign-in UI.
  • Protected routes redirect unauthenticated users to /auth/?rd=<original-url>.
  • The redirect target must stay on the same portal origin.
  • The login service writes the verified identity to Remote-User only after it has removed any client-supplied value.

Authelia is supported through this contract. Configure NOCLOUD_TRUST_PROXY_AUTH=1 only after the reverse proxy overwrites Remote-User on every native API route. The deploy smoke also checks those APIs with an authenticated loopback request.