v0.1.1 Free and MIT licensed Release notes

Private links
between your machines.

Through a relay you run yourself.

warren is one Rust binary. Your machines dial out to a relay you run and reach only the ports you share, end-to-end encrypted. No inbound ports, no kernel driver, no third-party account.

Download for macOS Quick start

Apple silicon, 4.8 MB. Also for Linux x86_64. Windows, iPhone and iPad are coming.

  1. laptop dials out

    One outbound connection to your relay, on 443 by default. No inbound ports, so it works behind NAT.

  2. The relay forwards it sealed

    It sees who talks to whom and when, never what.

  3. desktop decides

    Default deny: it checks its own share list for every stream.

iPhone and iPadcoming Not in v0.1, and not part of the recorded run.

06 / 09Forward before sharing: refused

Watch all nine scenes in the terminal

What your machines see

    Fig. 1Sheltered paths, drawn from the real run below. Each tunnel is one machine's outbound TLS connection to your relay; inside it, the stream between laptop and desktop is sealed end to end with Noise_IK_25519_ChaChaPoly_BLAKE2s. Packets are illustrative, and their timing follows the recording. iPhone and iPad are coming: not in v0.1, and not part of the run.TLS to your relaysealed end to endpublic: the relay reads itrefusedcoming: iPhone, iPad

    • 1

      binary

      The relay, the node daemon and the CLI are one file you can read, build and run yourself.

    • 0

      inbound ports on your machines

      Everything rides one outbound WebSocket on port 443, with default-deny shares checked at the destination.

    • 0.07ms

      added median round trip, on loopback*

      0.07 to 0.08 ms added, and 1.6 to 1.9 Gbit/s through a private link, both measured on loopback.

    Measured on loopback on an Apple M-series machine, relay and both nodes on one host, TLS and Noise on. Not measured over the internet; for that, see the field report below.

    Field report: a real product’s web hub, since October 2026

    The relay runs on a small Ubuntu server (1 GB of RAM) behind nginx, with a certificate from certbot; the hub runs on a Mac that publishes it through the relay. Until then the hub was reached through a hosted tunnel, which stays up as the fallback. The product’s web front end forwards every request over one of the two routes, so they can be compared like for like: in the 30 minutes after the switch, four kinds of request went through it 120 times each over warren and, at the same moments, over the hosted tunnel. Every request was a fresh connection from the same client, and every one succeeded.

    routerequestsp50p95
    warren relay480148 ms311 ms
    hosted tunnel480154 ms595 ms

    The medians are about the same; at the 95th percentile warren took about half as long. One client over half an hour on a busy evening, not a benchmark. The whole setup, with backups, health checks and how to remove it: docs/production-relay.md.

    01The run

    One real session, in nine scenes.

    Three shells on one Mac run the v0.1.0 release binary against a relay on 127.0.0.1. Commands and output are verbatim; captions, highlights and drawings are added to explain them.

    Real runwarren 0.1.0 release binary

    macOS, Apple siliconrecorded 2026-09-27

    01 / 09Download and start a relay

    The v0.1.0 release binary from GitHub, then a relay on 127.0.0.1 with a self-signed certificate.

    Playback is paced for reading; the run itself took 18 seconds. Run it yourself.

    02Security model

    The relay carries your traffic. It can't read it.

    Each machine keeps one outbound TLS connection to your relay. Inside it, the two machines run their own Noise_IK_25519_ChaChaPoly_BLAKE2s handshake, so a private stream crosses the relay sealed. Public names are the one exception, and warren says so every time you use one.

    Private link: laptop and desktop each hold their own TLS connection to the relay, and one Noise_IK stream runs end to end inside them, passing through the relay sealed. The relay sees who, which port, when and how many bytes. desktop checks its own share list before it opens 127.0.0.1:8000. Public name: any browser connects over HTTPS. TLS ends at the relay, which reads the HTTP and passes it to desktop inside desktop's own TLS connection.

    • Sealed end to end: only the two machines can read it
    • Readable by the relay
    • A machine's TLS connection to the relay
    Fig. 2One relay, two kinds of traffic. TLS to the relay protects both; only a private link stays sealed inside it. The full model, and the tests that check it: docs/security.md.

    The relay can see

    • which machines are enrolled and online
    • who opens streams to whom, on which port, and when
    • how many bytes flow
    • full HTTP for published names, because it terminates their TLS

    The relay cannot

    • read or modify a private stream: tampering fails authentication, and a truncated stream is detected
    • reach a port the destination hasn't shared, or reach it as a machine the share isn't for
    • impersonate a machine whose key you have pinned

    Keys stay home

    • each machine makes its own keys at warren join; files are 0600 in a 0700 directory
    • every connection proves the key with a fresh Ed25519 challenge bound to your relay
    • no telemetry and no update check

    03Commands

    Any TCP port, on your terms.

    A handful of verbs cover it. Every command also speaks --json, with documented exit codes.

    Relay certificates: ACME HTTP-01, your own --cert and --key, or --self-signed for a trial.

    share

    warren share 22 --to laptop

    Make a local port reachable, optionally only by named machines. Until you do, nothing is.

    forward

    warren forward 2222 desktop:22

    Listen on 127.0.0.1 and carry each connection to a port on another machine.

    ssh & nc

    warren ssh desktop

    ssh without a forward, or put warren nc %h 22 in your ssh config as a ProxyCommand.

    publish

    warren publish 3000 --name web

    Put a local port on https://web.<your relay>/, WebSockets and long polling included. TLS for it ends at the relay.

    revoke

    warren relay revoke laptop

    Disconnect a machine at once, even mid-handshake, and refuse it from then on.

    trust

    warren trust desktop --expect FP

    Keys are pinned. A changed key is refused until you check the new fingerprint.

    04Download

    Get warren. Free, one file, no account.

    macOS

    Apple silicon

    Download .tar.gz

    aarch64-apple-darwin4.8 MB

    Not notarized, so macOS quarantines a browser download: use the curl line in the quick start, or run xattr -d com.apple.quarantine warren once.

    Linux

    x86_64

    Download .tar.gz

    x86_64-unknown-linux-gnu5.4 MB

    Built and tested in CI on Linux. Not yet run on real Linux machines, so please report what you find.

    From source

    Rust 1.88+

    cargo install --locked --git https://github.com/willykeenan/warren

    cargo install warren installs an unrelated crate with the same name.

    comingWindows. A Windows build is in progress and will appear on the releases page.Watch the repository

    comingiPhone and iPad. Not in v0.1. The plan is an app that joins your warren by scanning a QR code.

    05Quick start

    Five minutes to a private link.

    The run above, on one machine, in three shells.

    1. Get the binary

      For Linux, use the x86_64-unknown-linux-gnu tarball instead.

      mkdir -p /tmp/warren-demo && cd /tmp/warren-democurl -fsSL https://github.com/willykeenan/warren/releases/download/v0.1.1/\warren-v0.1.1-aarch64-apple-darwin.tar.gz | tar xzexport PATH=$PWD:$PATH

    2. Start a relay on 127.0.0.1

      A self-signed certificate is fine for a trial. invite prints a one-time code and the certificate pin.

      warren relay --domain localhost --self-signed --listen 127.0.0.1:8443 --state relay &warren relay invite --state relay

    3. Enroll two machines

      In a second shell, as desktop. For laptop, run warren relay invite --state relay again for a fresh code, then repeat this in a third shell with WARREN_HOME=$PWD/laptop and --name laptop.

      cd /tmp/warren-demo && export PATH=$PWD:$PATH WARREN_HOME=$PWD/desktopwarren join CODE --relay https://localhost:8443 \--insecure-relay-cert-sha256 PIN --name desktopwarren up &

    4. Start a test service

      On desktop: a tiny web server that listens only on 127.0.0.1.

      mkdir site && echo "hello from desktop" > site/hello.txtpython3 -m http.server 8000 --bind 127.0.0.1 --directory site &

    5. Share it, then reach it

      desktop shares port 8000 with laptop only; laptop forwards a local port to it. Run the forward and curl before the share, and desktop refuses, as in the run.

      # desktopwarren share 8000 --to laptop# laptopwarren forward 9000 desktop:8000curl http://127.0.0.1:9000/hello.txt

    6. Publish, then revoke

      Optional. A public name (TLS ends at the relay; -k because the certificate is self-signed), then revoke laptop from the relay shell.

      # desktopwarren publish 8000 --name web# laptopcurl -sSk https://web.localhost:8443/hello.txt# relaywarren relay revoke laptop --state relay

    06Status and limits

    warren is new. Here is exactly what has been tested.

    Read this before relying on it. Full notes: Status and limitations in the README.

    • macOS

      used

      The relay, the node daemon and the login service have been used on macOS.

    • Linux

      relay in production

      A relay has run on an Ubuntu server in production since October 2026 (see the field report). Linux nodes are supported by the code and pass the test suite in CI, but none has run on a real machine yet.

    • Windows

      not yet

      Coming. There is no Windows build in v0.1.

    • iPhone and iPad

      not yet

      Coming. There is no phone or tablet build in v0.1; the plan is an app that enrolls by QR code.

    • Automatic certificates

      unit-tested

      The ACME pieces are tested, but the exchange with a live CA has not run end to end. Use staging first, or your own certificate.

    • Login service

      stand-in

      warren install is tested with a stand-in service manager; the real launchctl and systemctl calls are not run by the tests.

    • Trust on first use

      by design

      The first key a machine sees for a peer comes from the relay. Compare warren devices on both machines after enrolling.

    • Open shares

      by design

      warren share PORT without --to admits every enrolled machine, and whoever controls the relay can enroll one. Use --to for anything sensitive.

    • One relay, no direct paths

      by design

      All traffic goes through your relay. If it is down, nothing connects.

    • TCP only

      scope

      No UDP. The relay's default listeners are IPv4; IPv6 is covered in docs/relay.md.