Recording behind a login

Most products worth demoing are behind a sign-in. Demofy records them by holding a saved browser session — a connection — that you establish once and reuse across demos.

You establish one in either of two ways, and both end at the same place.

Connect in browser

Settings → Connections → Open live browser. A new tab opens a real Chromium running on our side, streamed to your screen; you drive it with your mouse and keyboard, sign into your own app, and press I'm logged in — Save connection.

Because a human is driving, everything that normally defeats automation works: two-factor codes, captchas, SSO redirects, OAuth popups. The browser is headed and presents an ordinary desktop identity, so the login page is not looking at an obvious robot.

Three things about that session, all deliberate:

• The tab is single-use. The link that opens it carries a ticket that is burned the moment it is presented, valid or not. If you lose the tab, you start over rather than reconnecting — a link you could reconnect with is a credential worth stealing.
• It ends. Ten minutes from claim, or two minutes after the tab goes away, whichever comes first. Every abandon path closes the browser.
• A failed save leaves it alive. If the label is taken or you were not actually signed in, you fix it and press Save again without redoing two-factor.

Exporting a session yourself

If you would rather not drive a hosted browser, export a Playwright storage state from your own browser session and register it. Same destination, same storage, same rules — it just skips the live tab.

Using one

The composer's Login control lists the connections you hold and defaults to "No login". Pick one and the demo — discovery and capture both — runs signed in as that session.

• Connections belong to a person, not to a workspace. Guests may hold them too, though a guest's library lasts only as long as their browser cookie does.
• You may hold 20 of them.
• A connection unused for 30 days is deleted, blob first and then the row. Using one refreshes that clock.

It stays signed in on its own

Apps rotate cookies as you use them. After a capture, the browser's updated session is written back over the stored one, re-sealed. A connection you use regularly therefore stays valid indefinitely without you touching it. If the write-back fails, the job is unaffected — it is best-effort by design, because a demo that rendered correctly must not fail over bookkeeping.

When the login has gone stale

Before a job runs, Demofy replays the signed-in leg and compares where it lands against where a logged-OUT visit landed when you saved the connection. If it lands exactly on the recorded logged-out URL, the job fails immediately with a clear reason rather than spending twenty minutes producing a video of a sign-in screen.

Anything ambiguous passes. The check may only turn a certain late failure into an early one; it may never invent a new reason to fail.

Who may use one

• Making a demo with a connection requires that you own it.
• Re-rendering or re-shooting a demo that was recorded with one is the author's alone. A colleague can watch it, share it, rename it and edit its narration, but they cannot spend a credential they do not hold.
• Deleting the connection while a job that names it is queued fails that job loudly at pickup, rather than running it signed out.

What is actually stored

This is the highest-sensitivity thing Demofy ever holds, and it has its own page: How a saved login is stored. The short version is that the session is encrypted in the web process before it goes anywhere, is never handed to a browser, is never written to storage in plaintext, and a one-shot session attached to a single job is destroyed outright after capture.