Persistent Sessions
A profile-backed runtime keeps its browser state across starts: cookies, logins, local storage - and the fingerprint identity, which matters just as much. A site that sees the same session cookie arrive from a brand-new fingerprint every day has a reason to challenge you.
🎬 Content TODO: a two-part GIF sells this instantly - left: human logs into a site through the takeover link; right: a restart minutes later landing straight on the logged-in dashboard.
Scripted logins work too - use vault credentials on the first start instead of a takeover link.
What persists, what doesn’t
The runtime itself is the long-term browser: its state lives and dies with it. Stop and restart the same runtime to resume; creating a new runtime always starts fresh. Stealth, fingerprint, and extensions are managed by the platform for the life of the profile, so the identity stays coherent across restarts - you can still change proxy, idleTimeoutMinutes, and network settings between starts.
Ephemeral runtimes (profile unset) discard everything on stop. Use them for one-shot jobs; use profile-backed runtimes for anything that returns to the same site as the same user.
Next
- Runtime configuration - profile-backed details
- Log In With Vault Credentials - script the first login
- Configure a Stealth Browser - why identity consistency matters

