An exported file, a shared link and a full transfer all get someone else into your environment. They give up different amounts of control, and they behave differently when you change your mind - here is exactly what each one does.
Every row is something you can check against the product, not a marketing gloss - the full mechanics for each column are in the sharing docs.
| Export a file | Share a link | Transfer ownership | |
|---|---|---|---|
| Recipient can use it | Yes | Yes | Yes |
| You can take it back | No | Yes | No - permanent handover |
| Recipient can edit, delete or export it | Yes | No | Yes |
| Proxy | Not included | Yours, credentials never shown | Moves with it |
| Recipient needs to pay | No | No - a free account is enough | Yes, a paid plan with quota to spare |
The "credentials never shown" row is the common case: a managed proxy. If the environment runs on a proxy you added yourself, that proxy is not part of the link at all - the recipient needs a proxy of their own to browse through it.
A complete, standalone copy of the environment, saved to a file. There is nothing left to revoke - the recipient owns that copy outright and can edit or re-export it however they like. This is the option for a clean, one-time handoff with no ongoing relationship to the original.
The recipient signs in - a free account is enough - and the environment shows up in their client. They can open it and inspect its fingerprint. They cannot edit its settings, delete it, export it, or share it onward. You can revoke the link at any time.
A permanent handover. The recipient needs a paid plan with room in their profile quota, and if the environment uses a managed proxy, room in their proxy quota too - the proxy moves with the environment. If it runs on your own proxy instead, its credentials are copied to the recipient. Once it's done, the environment is gone from your account.
Once a link is accepted, owner and recipient are both working against the same cookies and login state, not two copies that quietly diverge. A cookie or a login written during your session is what the recipient's browser sees the next time they open it, and the same is true in reverse. We verified this with a real browser session, not just the sync logic in isolation.
Revoking a shared link stops it from being used to start a new session, and it stops the recipient's traffic from continuing to route through your proxy. Between sessions there is nothing of yours on their machine: when the recipient closes the browser, their local copy is removed once that session has been saved back to your archive. What revoking cannot do is reach onto their computer while they are using it - anything copied out of an open session is theirs to keep, and revoking does not erase it.
A proxy connection that was already open when you revoked can keep running for a short time before it is cut. New connections stop being accepted, but revoking is not a switch that guarantees an existing one ends the moment you click it. If that gap matters for what you're protecting, treat revocation as "the recipient can't come back in," not as "the recipient is offline right now."
How to generate a link, how long it lasts, what a recipient sees in their client, and exactly what transferring requires.