Add Per-User Sessions guide

[robertjamesprior]

Summary

Adds browsers/per-user-sessions — a guide for running one authenticated browser per end user when the customer's own application owns the credentials, rather than using Managed Auth.

The content it covers already exists and is good; what's missing is a path through it for developers who aren't using Managed Auth. auth/profiles sits inside the Auth group in the sidebar, and both it and the pools guide route the per-user pattern through Managed Auth — the profiles page frames per-user mapping as "attach all their accounts as auth connections," and the pools page says to use Managed Auth to populate profile state. A customer who has been told they don't need Managed Auth has a reason to skip the page explaining the primitive they most need.

This page sits alongside the Auth group at the same level and links out to the existing sections instead of restating them.

What it covers

• One profile per user per site, populated by your own login flow
• The one-writer rule, linking to the existing Prevent concurrent profile writes section, with the reminder that the check and the create are separate requests
• Pools created without a profile, attached after acquire, released with reuse: false
• Standby economics, including that timeout_seconds defaults to 60 and that GPU browsers don't support standby
• Per-user cost attribution with tags

New content worth a closer look

The Share a live view with your user section is the only part not already documented somewhere. browsers/live-view currently describes readOnly as "the view will be non-interactive" with nothing about it being a display option rather than a security control, and nothing about the URL granting control of the browser or remaining valid until the browser is deleted. For this audience the natural design is to pop a live view so the end user can enter their own password, so the caveat matters.

It's written as guidance ("treat the URL as a credential", "serve it from your own backend") rather than describing how the limitation is reached. Happy to soften or drop it if it's better handled alongside the scoped-live-view-token work.

Verification

• Every parameter checked against packages/api/openapi.yaml: tags (object, max 50 pairs), timeout_seconds (integer, default 60, max 259200), profile.save_changes
• Go Tags type confirmed as kernel.Tags (type Tags map[string]string) against the Go SDK, and TimeoutSeconds: kernel.Int(...) matches existing usage in browsers/termination and browsers/pools
• deleteByID / delete_by_id / DeleteByID match the idiom in auth/profiles
• TypeScript, Python and Go examples in both code groups, per the code example guide
• Not run: mintlify dev. Worth a preview check on the two cross-page anchors (/auth/profiles#prevent-concurrent-profile-writes and /browsers/pools#per-user-profiles-with-browser-pools) before merge. I avoided linking the numbered heading on auth/profiles because the one existing link to it in changelog.mdx retains a comma in the slug and I couldn't confirm which form resolves.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Kernel	🟢 Ready	View Preview	Sep 14, 2026, 5:40 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[robertjamesprior]

Closing — this is moving into the customer-facing best practices guide rather than the public docs. The live view docs gap stands on its own and is tracked as KERNEL-2219.