ntwire

Operators

Deploy only the pieces you need.

Most deployments begin with ntwire-server: it owns authentication, grants, local target policy, TLS, and the userspace WireGuard device. Add ntwire-relay only when clients need to reach a server that is behind NAT or otherwise cannot accept direct public connections.

Terminal recording of ntwire-relay printing a sample config and starting, showing its public, agents, and domain listeners
ntwire-relay from a printed sample config to listening.

Choose a path

These choices affect how clients arrive, not the need for narrow grants and destination policy. Official WireGuard peers are static cryptographic peers; ntwire clients add session authentication, expiry, and revocation.

Terminal recording of ntwire-server printing a sample config, then starting and listening for HTTPS and WireGuard connections
ntwire-server from a printed sample config to listening.

Deployment options

  • Release binaries: download the server or relay archive matching the host operating system and architecture.
  • Docker Compose: use the repository’s runnable example to start a server and test fixed and SOCKS tunnels.
  • Kubernetes manifests: deploy the provided server example and use tightly scoped RBAC and NetworkPolicies when relay discovery is enabled.
  • Helm: add the ntwire Helm repository and deploy a server, relay, or persistent client connection from one chart. Its selected values map becomes the corresponding ntwire configuration file, while keys and certificates stay in Kubernetes Secrets.

Helm on Kubernetes

Add the chart repository with helm repo add ntwire https://ntwire.io/charts, then use helm upgrade --install ntwire-server ntwire/ntwire to retrieve the newest published chart. Add --version <chart-version> for a controlled upgrade. The chart selects server, relay, or client. Configure the matching server.config, relay.config, or client.config section as normal ntwire YAML settings, then mount keys and certificates from Secrets. Relay Service discovery remains opt-in and needs deliberately scoped Kubernetes RBAC.

Production checklist

  • Use a stable, CA-trusted server certificate and hostname where possible — configured on the origin server itself even behind a relay, since a relay never terminates client TLS.
  • Store private keys and administrator tokens outside source control.
  • Grant narrowly, bind sensitive listeners conservatively, and test reload behaviour.
  • Run the documented release gate before publishing a new version.

Continue with the canonical Deployment guide, relay guide, configuration reference, and deployment examples. For a real certificate on a server or relay, see the Let's Encrypt guide.