A disposable browser is a web browser that runs on a server inside a container and streams to your screen, so the risky page never actually loads on your own device. You interact with it like a normal browser, but the JavaScript, the downloads, the tracking, and anything malicious execute on a throwaway machine — and when you close it, all of that is destroyed. This technique is called remote browser isolation, and this post explains when it is genuinely useful, what browsers are available, and how to run one on your own server.
The core idea: put distance between you and the page
When you open a link on your laptop, that page runs code on your laptop. Usually that is fine. Sometimes it is a phishing kit fingerprinting your machine, a malicious ad exploiting the browser, or a link from an email you are not sure about. Remote browser isolation adds a gap: the page runs in a browser on a server, and your device only receives a video-like stream of what that remote browser displays. The hostile code never touches your operating system, your files, or your real cookies.
It is the same streaming-workspace technology as browser-based desktops, narrowed to a single application: just the browser, nothing else.
When is this actually worth doing?
Not for everyday browsing — that would be slower for no benefit. The disposable browser earns its place in specific situations:
- Opening a link you do not trust. A suspicious email link, a shortened URL, a "your invoice is attached" message. Open it in the remote browser; if it is hostile, it attacks a container you are about to delete.
- Investigating without leaving footprints on your machine. Researchers, journalists, and security analysts who need to visit a site without their real browser fingerprint, cookies, or local history being involved.
- Separating identities cleanly. A fresh browser with no shared cookies is a clean session every time — useful for testing how a site behaves for a brand-new visitor, or keeping work and investigation contexts genuinely separate.
- Anonymity via Tor. A containerized Tor Browser routes through the Tor network from the server, keeping that traffic isolated from your normal connection.
What is available
The Docker app catalog includes isolated single-browser workspaces you can deploy in one click:
| Browser | Use it for |
|---|---|
| Chrome / Chromium | General isolated browsing, opening untrusted links |
| Firefox | Isolated browsing with a different engine and extension model |
| Brave | Isolated browsing with built-in blocking |
| Tor Browser | Anonymous browsing routed through the Tor network |
Each runs as its own container — a browser in a tab, backed by the server, deletable at will.
Deploying one on Panelica
- Deploy the browser workspace from the Docker app catalog.
- Set the access password. Required — an open remote browser on the internet would be an open proxy for anyone who found it.
- Allocate resources. A browser workspace wants around 2 GB of RAM, and — this one is important — a larger shared memory size. Chromium-based browsers crash tabs when
--shm-sizeis left at Docker's tiny default; the template exposes the setting, so raise it. - Access over HTTPS. Link a subdomain through the reverse proxy, and if the browser is just for you, restrict the domain to your own IP.
- Use it, then reset. For true disposability, delete the container (and any volume) after a risky session. Redeploy fresh next time — it takes seconds.
What isolation does and does not protect
Being precise here matters, because remote browser isolation is sometimes oversold:
It protects your device. Malicious page code runs on the server, not your machine. Drive-by exploits, browser vulnerabilities, and hostile scripts hit the container. Delete the container and they are gone.
It does not make you invincible. If you type your real password into a phishing page inside the remote browser, you still handed over your password — isolation stops code execution, not your own actions. Downloads you deliberately move from the container to your machine cross the gap on purpose. And the server itself is now the thing that touched the hostile page, so treat a browser used for genuinely dangerous work as a container to destroy, on a server you are willing to rebuild.
A sensible setup
- Strong access password, stored in a password manager, never blank.
- Reachable only over HTTPS, IP-restricted to you when possible.
- Shared memory raised so tabs do not crash mid-session.
- Resource limits set so a heavy page cannot starve the server (how).
- Destroy-and-redeploy after any session that touched something genuinely hostile.
Frequently asked questions
Is this the same as a VPN?
No. A VPN changes where your traffic appears to originate; the page still runs on your device. Remote browser isolation runs the page on a different machine entirely. They solve different problems and can be combined.
Can I download files through it?
Files download into the container. Moving them to your own machine is a deliberate step across the isolation gap — do it only for files you trust, ideally after scanning. The whole point is that nothing crosses automatically.
Will sites detect and block it?
Some sites block data-center IP ranges or unusual browser fingerprints, so a remote browser can hit more CAPTCHAs or blocks than your home connection. That is a trade-off of running from a server, not a flaw in the isolation.
Does the Tor Browser workspace really anonymize me?
It routes through the Tor network from the container, isolating that traffic. Anonymity still depends on your behavior inside the browser — logging into a personal account over Tor deanonymizes the session regardless of the plumbing.
The takeaway
A disposable browser puts a server between you and the pages you do not trust: hostile code runs on a container you delete, not on the device with your real life on it. It is a targeted tool — for suspicious links, footprint-free investigation, and clean sessions — not an everyday browser. On Panelica each isolated browser is a one-click container; remember to raise shared memory, lock it behind a password and HTTPS, and destroy it after the dangerous work is done.