Skip to main content
Most tests need to be logged in before they do anything useful. There are three ways to handle that. Reach for them in this order: stay with live login while it is fast enough, then add an authSave / authLoad state file, and only move to a cached auth module when you need it. Wrap your login steps in a module and call it from the before section of each test. It performs the login on every run, so each test starts with newly captured authentication state.
log-in.module.yaml
checkout.test.yaml
Move to one of the options below when logging in on every run is too slow or trips auth-provider rate limits.
Running the test from a step in the main body (a common thing to do while editing) skips the before section, so the login never runs and the first step lands on a logged-out page. Run the whole test to exercise the before section. See Before and after sections.

​
2. Save and restore a state file (authSave / authLoad)

The authSave and authLoad steps (the editor’s Save auth state / Load auth state) write and read the browser’s cookies, localStorage, and IndexedDB to a JSON file you manage yourself. This is the closest analog to Playwright’s storageState, so it is the natural next step if you are migrating from Playwright: log in once, save the state, and load it instead of logging in again.
checkout.test.yaml
The file can be generated in a setup step and reused by compatible tools. It contains authentication credentials; keep it out of version control and refresh it when the saved session expires.

​
3. Cached auth module

When you want the speed-up without managing a file, let Momentic cache the session for you. Mark the login module as an auth module and enable caching: the first run logs in for real, and later runs (and parallel tests sharing the same cache key) restore the saved browser state server-side and skip the login steps entirely.
log-in.module.yaml
Call it from the before section exactly like the live-login module. Momentic handles capture, storage, expiry, and per-key isolation. Tests sharing a cache key can reuse the saved session while it remains valid. See Cache authenticated sessions for the full walkthrough and Modules for every cache field.
Don’t combine authSave / authLoad with a cached auth module for the same session; both save and restore state, and doing both leads to stale or conflicting auth. Pick one.

​
Options and trade-offs

​
In CI

Live login works in CI with no extra setup; provide credentials as secrets (env.USERNAME, env.PASSWORD, OTP secrets) rather than committed values. If logging in every run is too slow, add an authSave / authLoad state file or a cached auth module; the module’s session is stored server-side alongside the step cache, so once one run logs in, other runs and shards can reuse it within the TTL.

​
SSO, 2FA, and provisioned inboxes

Avoid logging in through SSO providers (Google, Facebook, GitHub). They often block automated browsers.
For one-time codes and magic links, fetch the code in a JavaScript step and save it to the environment: