Under the hood
The site and the demos run on a VPS I administer. Here is the path of a request when you launch a demo, and the server’s state right now.
The server right now
Active demos
—
CPU load
—
Memory
—
Uptime
—
The path of a request
Browser
You
nginx
HTTPS · reverse proxy
Next.js
Front + API proxy, server-side secret
docker-backend
Express · quotas · 15 min TTL
Docker
Isolated demo container, no internet
Once the demo is ready, the iframe goes straight through nginx (/demo/<port>/) to the container, which is only published on Docker’s internal interface.
Demo isolation
Anyone can start a container on my server, so every demo is locked down and disposable.
- 01
No internet access
Each demo’s network is created without outbound NAT: the container stays reachable on its published port but cannot contact any outside server.
- 02
Capped resources
256 MB of RAM and half a CPU core per service (1.5 GB for Airflow), at most 256 processes, and no-new-privileges against privilege escalation.
- 03
Limited lifetime
15 minutes per session, extendable 3 times. When it expires, docker compose down -v removes containers and volumes.
- 04
Abuse quotas
5 launches per IP every 10 minutes and at most 3 demos at once. A second visitor joins the instance that is already running.
- 05
Backend never exposed
The backend drives Docker through its socket, which amounts to root access: it publishes no port, requires a shared secret and only the front end can reach it.
- 06
Internal ports only
Demos are published on Docker’s internal interface, never on 0.0.0.0: only nginx reaches them, under /demo/<port>/.
The site’s stack
- Front end
- Next.js 16React 19Tailwind CSS
- Demo API
- Node.jsExpressdocker compose (CLI)
- Hosting
- Linux VPSnginxDocker Compose
- CI
- GitHub Actionslint + buildbackend testscompose validation
Want to see it run?
Launch a demo, then come back here: it will show up under active demos.