Is restored state enough, or must login readiness be verified?
A profile restores stored browser data. Managed authentication can check a connection and establish login when required. Choose based on whether the application must prove that the requested account is ready before work begins.
Website authentication crosses several boundaries: the user who authorizes access, the system that holds credentials, the browser that submits them, and any model or code driving the page. Reusing a login and collecting a new identity are separate workflows.
Notte
Vaults substitute credential placeholders in supported browser actions outside the model context. Managed Auth checks requested saved connections before automation. Personas supply an inbox and optional phone number for verification workflows.
Sources: docs.notte.cc ↗
Browserbase
The identity documentation covers website authentication and reuse of login state. Contexts and Function Secrets serve different roles: retained browser state versus values available to executing code.
Sources: docs.browserbase.com ↗
Kernel
Managed Auth handles website login and eligible connection recovery. Vault fill is a separate flow for applications that control navigation and form submission; the reviewed vault documentation labels that surface as preview.
Sources: kernel.sh ↗
Anchor Browser
Applications define the target website and authentication behavior. Identities attach managed sign-in to sessions. OmniConnect supplies an embeddable flow for end users to sign in from a product.
Sources: docs.anchorbrowser.io ↗
Evaluate the operational difference
Compare the concrete login path. A vault can fill a secret while your code controls the workflow; a managed connection may own more of the login process. Neither should be described as a universal guarantee that every website remains signed in.
For a customer-facing app, associate each stored connection with the correct application user before opening a browser. Reusing another user's profile can produce a technically successful run in the wrong account.
- Identify whether the task uses an existing account or creates an approved new identity.
- Separate profile restoration from credential fill and connection readiness.
- Document which component can access credential values and which only handles references.
- Verify the expected tenant and account after login.
- Provide a human handoff when the website requires user interaction.
Make the acceptance test explicit
Describe the work that must finish, the account it runs under, the state it needs to retain and the expected output. Select eligible product configurations before measuring latency or price.
Run the same workflow with each proposed architecture. Keep startup measurements separate from task execution, and distinguish provider failure from a configuration error or an unsupported website action.
Choose the responsibility you want to own
An external runner keeps deployment and queues in your application. A hosted execution layer moves part of that responsibility to the browser platform. Saved browser state reduces repeated setup, while managed website authentication may add readiness checks. Choose each part deliberately rather than treating a brand as one indivisible feature list.