Logging in

/ui/login asks for a token, not a username and password — VectorStep doesn’t have accounts. The token you paste in is one of the named entries under auth.tokens in config; submitting a valid one sets a signed session cookie and gets you into the UI for up to 8 hours (see Security for the full token/role model and session details).

Check “Remember me for 30 days on this device” to skip re-pasting the token every few hours — it mints a longer-lived session instead of the 8-hour default (auth.session_max_age_remembered_seconds in config). Only check it on a device you trust: the cookie is still HttpOnly/SameSite=Lax, but a longer-lived one is a wider window if that device is ever compromised. Leave it unchecked on anything shared.

Where your token comes from

If you ran the installer yourself, it minted one for you: install.sh prints “VectorStep admin token (needed to log into the UI)” at the end of the run, and saves it to ~/.vectorstep/.env as VECTORSTEP_ADMIN_TOKEN in case you missed it:

grep VECTORSTEP_ADMIN_TOKEN ~/.vectorstep/.env

If someone else runs the deployment, you don’t generate your own token — whoever holds an admin token adds a new named entry to auth.tokens in config and gives you that value. Ask them for a token scoped to what you actually need: viewer if you just need to look at runs and insights, operator if you’ll be triggering or approving things, admin only if you need to edit pipeline/step config. See Security for what each role grants.

Lost or leaked a token

There’s no “reset password” flow — a token is a shared secret, so recovery is rotation. Whoever holds an admin token replaces the value on the affected entry in auth.tokens (keeping the same name) and restarts the service; the old value stops working immediately; and sessions minted from it are invalidated on that restart too, so there’s no separate logout step. If you’re the only admin and you’ve lost your own admin token, you’ll need direct access to the config file to rotate it yourself.