Reference
Networking
NanoVM has no real TCP/IP stack. Outbound traffic is brokered through the host's fetch(); inbound traffic to in-VM servers is injected by a service worker.
Two directions, two bridges
- Outbound (guest → internet) — HTTP/HTTPS shims inside the VM route through the host's fetch() via a /dev/__net__ device.
- Inbound (browser → in-VM server) — a service worker injects browser requests into the VM's socket layer and streams the response back (see Virtual server).
What works today
- GET / POST to HTTP(S) endpoints from inside the VM.
- Downloading files and calling JSON APIs from scripts and Node code.
- npm install over HTTPS, when the registry/host allows it.
The CORS gotcha
Host fetch is subject to the browser's same-origin policy. The guest can reach any origin that returns permissive CORS headers — or anything behind a CORS proxy. Cross-origin requests to servers that send no CORS headers will fail. This is the single biggest practical limitation, and it is a browser constraint, not a NanoVM one.
If a request works in a normal browser fetch() from your origin, it will work from inside the VM. If it would be blocked by CORS in the browser, it is blocked in the VM too.
What's not there yet
- No raw TCP/UDP sockets — browsers don't expose them, so no direct ssh / nc.
- No ICMP — ping and traceroute are impossible in a browser sandbox.
- DNS only via DNS-over-HTTPS.
- A CORS-proxy tier (for git and CORS-blocked APIs) and a tunneled raw-socket tier are on the roadmap.
For serving — running a server inside the VM and previewing it in an iframe — see the Virtual server page.