Sign-in Sessions & Server Restarts

By default, restarting the Athena server signs out every logged-in operator — the next click lands them back on the login page. This is deliberate: for security, Athena generates a fresh token signing key each time it starts, which instantly invalidates all tokens issued by the previous run. This page explains that behaviour, how it differs from the ordinary token and idle-session timeouts, and how to change it if you would rather have sessions survive a restart.

Why everyone is signed out after a restart#

When you sign in, Athena issues you a session token. That token is cryptographically signed with a secret signing key held by the server, and every subsequent request is accepted only if its signature still verifies against that key. With signing-key rotation enabled (the default), the server generates a brand-new random key every time it starts. Tokens signed with the previous key no longer verify, so they are all rejected at once and their holders are returned to the login screen.

This is a security feature, not a fault. It guarantees that a token captured from one run of the server cannot be replayed against a later run, and that any restart — planned maintenance, an upgrade, a crash recovery — cleanly ends every session that was open beforehand. The trade-off is the visible one: an administrator who restarts the service should expect to sign in again, and to let colleagues know they will too.

The signing-key rotation setting#

The behaviour is controlled by a single server configuration key. It is a deliberate server-level security decision, so it lives in the server configuration file rather than the console UI:

With rotation enabled the key is generated in memory at startup and is never written to disk or configuration — there is nothing to manage. This is the recommended setting for production, and no further action is required to benefit from it.

Keeping sessions alive across restarts#

If frequent restarts make the sign-out disruptive — for example in a lab, during iterative configuration, or where an external load balancer restarts the service often — you can turn rotation off and pin a fixed signing key. Sessions then survive restarts and end only when their token expires or the operator is idle-timed-out (see below).

Set both keys in the server configuration file appsettings.json:

// appsettings.json
"Security": {
  "EnableJwtSecretRotation": false
},
"Jwt": {
  "Secret": "<a long random secret, at least 32 characters>"
}

Or with the equivalent environment variables (useful for container deployments):

Security__EnableJwtSecretRotation=false
Jwt__Secret=<a long random secret, at least 32 characters>

Restart the server for the change to take effect. From then on, sessions persist across restarts because every run signs and verifies tokens with the same key.

How this relates to token and idle timeouts#

Signing-key rotation is one of three independent controls that decide how long a console session lasts. They work together, and whichever fires first ends the session:

In short: Token Expiration and Session Timeout govern the length of a session while the server keeps running, and you tune both from the Security Settings screen. Signing-key rotation is the separate, restart-driven behaviour described here. Even with a very long token lifetime and the idle timeout disabled, a restart still signs everyone out while rotation is enabled — which is exactly why you change this setting, and not the timeouts, if you want sessions to survive restarts.

Restart checklist for admins#

• Expect to be signed out yourself after restarting the service; keep your credentials handy.
• Give other operators a heads-up before a planned restart or upgrade — they will need to sign in again.
• A sudden "everyone was logged out" is normal right after a restart; it is not a sign of a breach or a broken database.
• If restarts are frequent and the sign-outs are disruptive, consider pinning a fixed signing key — accepting that you give up automatic invalidate-on-restart in exchange.
• Unrelated to restarts, individual operators can still be signed out early by Token Expiration or the idle Session Timeout, and locked out by failed-login lockouts.