> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vers.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Networking

> How Vers VMs are reachable from the internet, what ports are routable, how TLS works, and the gotchas around dual-stack binds.

Every Vers VM is reachable from the public internet at a predictable hostname, through a proxy that handles TLS, across a wide port range. You don't configure any of this — it's automatic the moment you `vers run`.

This page documents what the network looks like from the inside and outside of a VM.

## Hostnames

Every VM has a public hostname of the form:

```
{vm-id}.vm.vers.sh
```

Where `{vm-id}` is the ID returned by `vers run` (e.g. `vm-abc123`). The hostname resolves to the Vers edge proxy, which routes the connection to your VM.

There's no per-user setup. DNS for `*.vm.vers.sh` is managed by Vers; wildcard TLS certificates are issued automatically.

## Port range

Vers routes TCP traffic to ports **1024 through 10000** on your VM.

Any server you run on a port in that range is reachable at:

```
https://{vm-id}.vm.vers.sh:{port}
```

Ports below 1024 (privileged ports) and above 10000 are not routed from the public proxy. Bind your services to a port in the routed range.

## TLS is handled for you

The Vers proxy terminates TLS for every VM hostname. That means:

* Your VM serves plain HTTP.
* Browsers and clients see HTTPS.
* You do not need to configure a certificate, manage renewal, or run a TLS stack of your own.

A typical Node.js server looks like:

```javascript theme={"theme":{"light":"min-light","dark":"min-dark"}}
// Bind to all interfaces (see "IPv6 dual-stack" below)
server.listen(3000, "::");
// Reachable at https://{vm-id}.vm.vers.sh:3000
```

Your server speaks HTTP on port 3000. The proxy handles TLS on the public side. No certificates, no reverse proxy, no Let's Encrypt dance.

## IPv6 dual-stack (important)

The Vers edge proxy reaches your VM over IPv6. If your server binds only to IPv4 (`0.0.0.0` or `127.0.0.1`), the proxy can't connect and requests will fail.

**Bind to all interfaces, dual-stack:**

| Language / framework               | Dual-stack bind                                                          |
| ---------------------------------- | ------------------------------------------------------------------------ |
| Node.js (`net`, `http`, `express`) | `server.listen(PORT, "::")`                                              |
| Python (`http.server`, `flask`)    | `app.run(host="::", port=PORT)`                                          |
| Go (`net/http`)                    | `http.ListenAndServe(":PORT", handler)` — Go binds dual-stack by default |
| Rust (`tokio`, `axum`)             | Bind to `[::]:PORT`                                                      |
| Gunicorn / Uvicorn                 | `--bind [::]:PORT`                                                       |

If your framework defaults to `0.0.0.0` or `127.0.0.1`, override it explicitly. "It works locally but nobody else can reach it" is almost always a missing dual-stack bind.

<Warning>
  `0.0.0.0` binds only IPv4. `::` binds IPv6 and, on most systems, IPv4-mapped addresses — so a dual-stack bind catches both.
</Warning>

## SSH

SSH access is how `vers connect` works. It's layered a little differently from HTTP:

* SSH connects over port 443 (not the 1024–10000 range).
* The SSH connection is tunneled through TLS so corporate firewalls that only permit 443 outbound can still reach your VMs.
* You don't manage SSH keys manually. `vers connect` handles key provisioning, fingerprint verification, and connection setup automatically.

See [`vers connect`](/cli-reference/connect) for the CLI details and [VM access](/vm-access) for interactive and programmatic access patterns.

## Outbound connectivity

Your VM has unrestricted outbound internet access. DNS, package installs, API calls, cloud storage uploads — all work out of the box, no configuration.

Common things that work:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
# Package installation
apt-get update && apt-get install -y python3

# Language runtimes
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -

# API calls
curl https://api.example.com/resource

# Cloud storage
aws s3 cp file.bin s3://my-bucket/
```

No DNS override needed. No proxy configuration. No allow-listing.

## Multiple services on one VM

You can run any number of services on different ports in the routed range. Each is independently reachable:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
# Terminal 1 inside the VM
python3 -m http.server 8000 --bind ::

# Terminal 2 inside the VM
node server.js  # binds to :: on 3000
```

Public URLs:

* `https://{vm-id}.vm.vers.sh:8000` → the Python static-file server
* `https://{vm-id}.vm.vers.sh:3000` → your Node.js app

Each branch and each restored VM gets its own hostname, so you can have a tree of VMs all serving different things on the same ports without collision.

## Putting it together

A typical full-stack workflow looks like:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
# 1. Boot a VM
vers run --vm-alias web

# 2. Connect
vers connect

# 3. Inside the VM, install and run your app
apt-get install -y python3
cat > app.py << 'PY'
from flask import Flask
app = Flask(__name__)
@app.get("/")
def hi(): return "hello from vers\n"
app.run(host="::", port=5000)
PY
python3 app.py &

# 4. Exit back to your host
exit

# 5. Get the VM ID
vers status
# Your VM's hostname is https://{vm-id}.vm.vers.sh:5000
```

Hit that URL in a browser. Your app is live, HTTPS, no certificate setup.

## What's next

<CardGroup cols={2}>
  <Card title="VM access" icon="terminal" href="/vm-access">
    Interactive SSH, command execution, file transfer.
  </Card>

  <Card title="Agent swarms tutorial" icon="robot" href="/tutorials/agent-swarms">
    Running real services on branched VMs, including the "serve it" step.
  </Card>

  <Card title="vers connect" icon="right-to-bracket" href="/cli-reference/connect">
    CLI details for SSH access.
  </Card>

  <Card title="Architecture" icon="sitemap" href="/architecture">
    How VMs sit in the tree and what branching means for networking.
  </Card>
</CardGroup>