VPN

DeployOS can run a private OpenVPN server on any server you already manage — a VPN for yourself, your team, or anything else you'd normally pay a separate provider for. One VPN per server. Nothing about this reaches DeployOS's own servers: traffic goes from your device, through the tunnel, to wherever that server can reach — never through us.

Deploying it

1. Open VPN and pick a server — only servers already connected in DeployOS can be used.
2. Preflight runs automatically the moment you pick one: OS, architecture, Docker, the TUN device, IPv4 forwarding, free disk, sudo access, and whether the port is already in use. Each check is either a hard blocker or a warning, shown separately.
3. Review what deploying would change — the exact container, its capabilities, the port, the directories it creates, the forwarding and NAT rules, and the one firewall rule it adds. This is the complete list; nothing else is touched, and it's the same list that runs when you approve it.
4. Click Deploy VPN. DeployOS generates the server configuration, initializes a certificate authority on the server, and starts the container.

How it protects the rest of the server

• No --privileged, and nothing close to it. The container runs with every capability dropped except the four it specifically needs — two for networking, two so OpenVPN can drop from root to an unprivileged user after it opens the tunnel device.
• Its own isolated network. Host networking is never used, and no existing firewall rule on the server is ever removed or flushed — only the one port this VPN needs gets opened.
• A resource cap, so it can't grow unbounded on a server you might also be using for other things, including Client Hosting Mode.

Checking it's actually working

A running container is not proof that a VPN works, so Health reports three separate signals instead of one green light:

• Is the container actually running
• Is IPv4 forwarding enabled (without it, traffic arrives through the tunnel but has nowhere to go)
• Has a device actually connected

All three have to be true for the VPN to be reported healthy. Recent OpenVPN logs are available underneath if something's off.

Adding a device

Each device — your laptop, your phone, a teammate's machine — gets its own certificate.

1. Under Devices, type a name (e.g. "Work laptop") and click Add device.
2. Click Export next to it. A native save dialog opens — pick where to save the .ovpn profile. The private key is written straight to that file; it never passes through DeployOS's own interface, and is never visible to an AI assistant even if you have one connected.
3. Import that .ovpn file into a standard OpenVPN client — Tunnelblick or the official OpenVPN Connect app both work — and connect.

Revoking a device is permanent. Once you click Revoke, that certificate can never reconnect, even if you export the same device again later — a fresh device gets a fresh certificate instead.

Transport and tunnel mode

• UDP (the default, port 1194) is faster; some restrictive networks block it. TCP works wherever UDP is blocked, at some cost to throughput.
• Full tunnel routes all of a connected device's traffic through the server. Split tunnel only routes the subnets you choose.

Removing it

Uninstalling removes exactly what DeployOS created — the container, the bridge network, the one firewall rule — and deliberately leaves the certificate authority in place. Deleting it would invalidate every device already issued, so that's a separate, explicit step if you're sure you won't need to revoke anything later.

AI assistant access

If you use AI Assistant Access (MCP), the VPN has its own set of tools under the same rules as everything else there: read-only tools (list devices, check health) are always available once MCP is on; anything that changes something (deploy, create a device, revoke, uninstall) needs its own toggle and your confirmation first. An assistant can never see a device's private key or exported profile — those only ever reach the save dialog you picked yourself.