Documentation

Quickstart: three commands to a tailnet

Install the CLI, sign in, and your device joins the network with a stable address and a name. No config files to write, no certificates to babysit, no ports to open — the install script detects your platform and the rest is a browser login.

✓Same three commands on macOS, Linux, and Windows
✓Outbound-only — nothing exposed, nothing to harden
✓Ping any device by name the moment you're up

# install the CLI (macOS / Linux)

$ curl -fsSL https://www.openvlan.com/install.sh | sh

# sign in and join the network

$ openvlan up

# check your connection

$ openvlan status

# you're on the tailnet. ping any device by name:

$ ping my-other-device

Docs that match the version you downloaded

Every guide is versioned alongside the clients and reviewed each release cycle. If your admin console shows a toggle these pages never mention, that's a docs bug — file it and the PR usually lands within days.

docs coverage, current release

quickstartsinstall to first ping12CURRENT

topic guidesnetworking · security · automation38CURRENT

api endpointsreference + recipes13VERSIONED

cli commandsman pages included41VERSIONED

kb articlestroubleshooting first120+GROWING

Core concepts

Tailnet

Your private network: all your devices, one address space (100.64.0.0/10 by default), one DNS namespace.

Nodes

Anything joined to the tailnet — laptop, server, container, phone. Every node gets a stable identity.

ACLs

The rulebook of who may talk to what. Deny by default, expressed against users, groups, and tags.

MagicDNS

Every node is reachable by short name — ssh build-01 just works, no IP memorization.

Subnet routers

Advertise whole CIDRs into the tailnet so existing networks join without touching each host.

Guides by topic

Getting started

✓Install on Windows, macOS, Linux, iOS, Android
✓Add your first server with the CLI
✓Invite users and organize groups
✓Enable MagicDNS

Downloads →

Networking

✓Advertise a subnet from AWS / GCP / Azure
✓Exit nodes for internet-bound traffic
✓Connect on-prem ranges via pfSense / OPNsense
✓Split DNS for internal zones

Infra access →

Security

✓Write your first ACL file
✓Device posture checks
✓SSH sessions with per-user certs
✓Stream audit logs to your SIEM

Zero Trust →

Automation

✓Terraform provider quickstart
✓GitHub Actions ephemeral runners
✓Kubernetes operator
✓Auth keys: pre-authorized, scoped, expiring

API reference →

Feature deep dives

OpenVLAN SSH

SSO-authenticated sessions, recording, and check mode on servers.

Feature page →

Exit nodes

Advertise, approve, and route device traffic through trusted egress.

Feature page →

Kubernetes operator

Ingress, egress, and CRDs — clusters as first-class tailnet citizens.

Use case →

Funnel

Publish specific services to the public internet, TLS included.

Use case →

CLI cheat sheet

Command	What it does
openvlan up	Connect / re-authenticate this device
openvlan down	Disconnect
openvlan status	Show peers, routes, and connection state
openvlan ip	Print this node's tailnet address
openvlan up --advertise-routes=10.0.0.0/16	Become a subnet router
openvlan up --advertise-exit-node	Offer internet egress through this node
openvlan logout	Remove keys and leave the tailnet

Docs FAQs

I'm new here. What do I read first?

The quickstart above, then "Core concepts" — tailnet, nodes, ACLs, MagicDNS. Ten minutes total. After that, jump by task: the Guides-by-topic grid maps each card to the deep dive you actually need.

Do the docs cover self-hosted coordinators?

Yes — the Enterprise self-hosting guide covers install, sizing, upgrades, and data residency. It lives under "Security & architecture" in the topic guides.

Can I contribute fixes to the docs?

Yes. The docs source is in the public repo; one-paragraph PRs are celebrated and usually merged within days. Typos, dead links, and "this step didn't work on FreeBSD" reports are all fair game.

Where are the docs for older client versions?

Every page carries a version selector — the /v1.7 docs stay readable after 1.8 ships. API reference pages pin to /v1 explicitly, so integrations written against last year's endpoints keep working.

What's the difference between docs, the KB, and the blog?

Docs describe how things work. The knowledge base answers what goes wrong. The blog explains why we built it that way. When a blog post's "how" section goes stale, it links to the doc that stays current.