Security and your data

Midstream runs your application and replays a moment from your test suite, so it necessarily holds some of your things. This page says which things, where they live, and who can reach them. One part of it changes how you should write your tests, so it comes first.

Capturing a scene captures a real session

When a deploy runs your test, it stops at the scene and takes a copy of the browser at that moment: its cookies, its localStorage, its sessionStorage, and its IndexedDB. That copy is kept so it can be handed to whoever opens the instance. It is the whole trick behind landing on the checkout page already signed in, with a cart already full, rather than on a login screen.

It is also a real session. Whoever opens the instance is handed it, and inside that instance they are whoever the test was signed in as. If your app keeps an access token in localStorage, that token is copied and replayed too — and the same goes for a session in IndexedDB, which is where Firebase Auth, Supabase and most offline-first apps keep theirs.

So:

Do not mark scenes in tests that authenticate against real production data. Use test accounts and seeded data.

In practice that means:

• Point the test at data the deploy creates. A deploy is a fresh container holding your repository at one commit. If your install or start command brings up a local database and seeds it, everything the test touches is disposable by construction.
• Sign in as an account the test owns. One created by a seed script or by the test itself, holding nothing you would mind a colleague seeing.
• Use sandbox credentials for third-party services. A payment provider's test keys, not your live ones.
• Keep secrets out of the browser. Anything your app writes into the page's storage at the moment of the scene is captured. Anything it keeps on the server is not.

This is good practice for E2E tests anyway — a test that depends on production data is a flaky test. Midstream just makes the cost of ignoring it concrete.

The captured session belongs to the instance that replays it, and is re-created from scratch on every deploy: each deploy runs the test again and captures the moment again. It is not shared between instances, and it does not outlive them.

What CI stores

The scene calls in your test suite behave differently in CI. There, we record that the scene exists at a commit, and we store two artifacts:

• A screenshot of the page at that moment, as a PNG.
• An accessibility snapshot — a text outline of the page's structure and labels, which is how we tell whether a scene actually changed between two commits.

Alongside them we keep the scene's slug and name, the test file and the chain of test titles that reach it, the commit, and the branch label CI reported.

No session is captured in CI. No cookies, no localStorage, no sessionStorage, no IndexedDB. That only happens inside a deploy, on the container that will serve the instance.

Both artifacts are images and text of your own application's UI. If a scene's screenshot would show something sensitive, the answer is the same as above: mark the scene in a test that runs against seeded data.

Where your code runs

To open an instance we clone your repository at the capture's commit into a container, run your install and start commands, and run one test.

• The clone lives only for the life of that instance. We do not keep a copy of your source code.
• We read the repository with the access you granted the GitHub App, and we never write to it.
• Each instance gets its own container. Containers are never shared between two instances, and never between two workspaces.
• Opening a scene from the dashboard gives you your own instance, so one reviewer filling in a form does not disturb another's.

Because your install and start commands run as written, a deploy can do anything those commands can do. That is the same trust model as your own CI: you decide what runs.

Who can see what

• Instances. Opening one from the dashboard requires membership of the workspace that owns the project. Invite the reviewers, designers, and managers who need to look.
• An instance's own address is sensitive. It points at a live copy of your application carrying the captured session. Treat it like a link to a staging environment: fine to paste in your team's channel, not fine to post publicly.
• Build output. When a deploy fails, the raw output — your install command's errors, your app's crash log, your Playwright run — is shown to workspace members only. It is your own build output, on the same footing as a CI log. Someone who merely opened an instance link sees a one-line summary with no command output and no stack traces.
• Everything else — scenes, captures, comment threads, usage figures — is scoped to the workspace and visible to its members according to their role.

Deleting things

Use the folder's menu in the scene list to delete a folder. That deletes the folder, every folder under it, and every scene inside them — along with the instances built from those scenes, their deploy history, and any comment threads. It cannot be undone, and the dialog tells you how many scenes are about to go.

To remove a whole project or workspace, or to have every artifact we hold for you erased — stored screenshots included — email support@midstream.studio and we will do it.

For questions about personal data specifically — what we hold about you as a user, and your rights over it — see the privacy policy, or write to privacy@midstream.studio.