Access your home server from anywhere. Share services with friends. No cloud, no account, no SaaS dependency.

Shurli connects your devices through firewalls and CGNAT using encrypted P2P tunnels with SSH-style authentication. One binary, zero configuration servers, works behind any NAT.

Download the latest release for your platform from GitHub Releases.

Requirements: Go 1.26+

Linux - install the mDNS development library first:

# Debian / Ubuntu
sudo apt install libavahi-compat-libdnssd-dev

# Fedora / RHEL
sudo dnf install avahi-compat-libdns_sd-devel

# Arch
sudo pacman -S avahi

macOS - no additional dependencies (uses built-in mDNSResponder).

Then build:

git clone https://github.com/shurlinet/shurli.git
cd shurli
make build

# Or directly with Go:
# go build -o shurli ./cmd/shurli

Move the binary to your PATH:

sudo install -m 755 shurli /usr/local/bin/shurli

Or use make install to build, install, and set up a system service in one step.

# Short URL
curl -sSL get.shurli.io | sh

# Or use the full GitHub URL directly
curl -sSL https://raw.githubusercontent.com/shurlinet/shurli/dev/tools/install.sh | sh

The install script detects your OS and architecture, downloads a pre-built binary, verifies checksums, and walks you through setup. It handles peer nodes, relay servers, upgrades, and uninstall.

For pre-release builds, set the environment variable before sh:

curl -sSL <URL> | SHURLI_DEV=1 sh

# Linux (Debian/Ubuntu)
sudo apt install libavahi-compat-libdnssd-dev

git clone https://github.com/shurlinet/shurli.git
cd shurli
go build -ldflags="-s -w" -trimpath -o shurli ./cmd/shurli
sudo install -m 755 shurli /usr/local/bin/shurli

# Interactive install (prompts for method and role)
curl -sSL get.shurli.io | sh

# Latest dev build
curl -sSL get.shurli.io | SHURLI_DEV=1 sh

# Specific version
curl -sSL get.shurli.io | SHURLI_VERSION=v0.2.2-dev sh

# Non-interactive relay server deploy
curl -sSL get.shurli.io | SHURLI_DEV=1 SHURLI_METHOD=download SHURLI_ROLE=relay sh

# Non-interactive peer node install
curl -sSL get.shurli.io | SHURLI_DEV=1 SHURLI_METHOD=download SHURLI_ROLE=peer sh

# Non-interactive upgrade (replace binary, keep config, restart service)
curl -sSL get.shurli.io | SHURLI_YES=1 SHURLI_UPGRADE=upgrade SHURLI_METHOD=download sh

# Fully unattended binary install (AI agents and automation)
curl -sSL get.shurli.io | SHURLI_YES=1 SHURLI_DEV=1 SHURLI_METHOD=download SHURLI_ROLE=binary sh

# Non-interactive with flags (when running script directly)
sh install.sh --method download --role relay --yes

# Back up config only (no install)
curl -sSL get.shurli.io | SHURLI_BACKUP=1 sh

# Uninstall (interactive: choose keep config, backup, or full removal)
curl -sSL get.shurli.io | SHURLI_UNINSTALL=1 sh

Follow the docs/RELAY-SETUP.md to deploy your own relay on any VPS. One script, takes a few minutes. Your relay, your rules. No third party controls your network.

On the relay, generate an invite:

shurli relay invite create --ttl 24h
# Output includes: invite code, relay IP:PORT, and Peer ID

On your device, join with one command (it will prompt for the Peer ID):

shurli join <invite-code> --relay <IP:PORT>

That's it. Identity created, config written, relay connected, daemon started. On Linux it offers to install as a systemd service (starts on boot). Repeat on each device you want to connect.

shurli proxy home ssh 2222
ssh -p 2222 user@localhost

Set up config first, connect later:

# Step 1: Create identity and config (choose your relay or public seeds)
shurli init

# Step 2: On your relay, create an invite
shurli relay invite create --ttl 24h

# Step 3: On one device, generate the invite
shurli invite --as home

# Step 4: On the other device, join
shurli join <invite-code> --as laptop

# Step 5: Start the daemon
shurli daemon

For users who prefer full control without interactive prompts:

# 1. Create identity from seed phrase
shurli recover --dir /etc/shurli

# 2. Write config manually
cat > /etc/shurli/config.yaml << 'EOF'
version: 1
identity:
  key_file: "identity.key"
network:
  listen_addresses:
    - "/ip4/0.0.0.0/tcp/0"
    - "/ip4/0.0.0.0/udp/0/quic-v1"
relay:
  addresses:
    - "/ip4/203.0.113.50/tcp/7777/p2p/12D3KooW..."
  reservation_interval: "2m"
discovery:
  rendezvous: "shurli-default-network"
  bootstrap_peers: []
security:
  authorized_keys_file: "authorized_keys"
  enable_connection_gating: true
names: {}
EOF

# 3. Add authorized peers manually
echo "12D3KooW...  # relay" >> /etc/shurli/authorized_keys
echo "12D3KooW...  # home-node" >> /etc/shurli/authorized_keys

# 4. Start
shurli daemon

Shurli works with two machines and zero network effect - useful from day one.

┌──────────┐         ┌──────────────┐         ┌──────────────┐
│  Client   │───────▶│ Relay Server │◀────────│    Server    │
│  (Phone)  │ outbound    (VPS)   outbound   │  (Linux/Mac) │
└──────────┘         └──────────────┘         └──────────────┘
                           │
                     Both connect OUTBOUND
                     Relay bridges the connection
                     DCUtR upgrades to direct P2P

1. Server runs shurli daemon behind CGNAT, connects outbound to a relay
2. Client runs shurli proxy, connects outbound to the same relay and reaches the server
3. DCUtR attempts hole-punching. If successful, traffic flows directly without the relay

For the full architecture: docs/ARCHITECTURE.md

Shurli was created to solve one problem: reaching a service on a home server from outside the network without depending on anyone else's infrastructure.

Existing solutions require either a cloud account, a third-party VPN, or port forwarding - which CGNAT frequently makes impossible. They all share the same flaw: your connectivity depends on someone else's servers and their permission to keep it running.

Shurli uses a different model. Devices connect outbound to a lightweight relay for initial setup, then upgrade to direct peer-to-peer when possible. No accounts, no central identity server, no revocable subscriptions. Your keys stay on your machine, configuration lives in one YAML file, and you can run your own relay for zero external dependency.

Two layers of defense:

1. ConnectionGater (network level) - Blocks unauthorized peers during the connection handshake, before any data is exchanged
2. Protocol handler (application level) - Secondary authorization check before processing requests

Fail-safe defaults:

• Connection gating enabled + no authorized_keys file -> refuses to start
• Empty authorized_keys -> warns loudly (allows for initial setup)
• All unauthorized inbound connections blocked

Linux (systemd):

sudo cp deploy/shurli-daemon.service /etc/systemd/system/shurli.service
sudo systemctl daemon-reload
sudo systemctl enable --now shurli

macOS (launchd): Copy deploy/com.shurli.daemon.plist to ~/Library/LaunchAgents/.

Relay server: See docs/RELAY-SETUP.md for the full VPS deployment guide. Quick install: make install-relay

Run the built-in diagnostic:

shurli doctor        # Check installation health
shurli doctor --fix  # Auto-fix common issues

Common issues and solutions are in docs/TROUBLESHOOTING.md.

This is not a weekend hobby project. Shurli is built as critical infrastructure, the kind where failure has real consequences for real people.

Shurli is experimental software under active development. It is provided "as is" with no warranty of any kind (see LICENSE). If you discover a bug, please open an issue.

Shurli is developed with significant AI assistance (Claude). All AI-generated code is reviewed, tested, and committed by a human maintainer.

No Cryptocurrency / No Token. Shurli is a networking tool. It has no token, no coin, no blockchain dependency.

Contributing: Issues and PRs are welcome. Run go build ./..., go vet ./..., and go test -race -count=1 ./... before submitting.

Networking:

• go-libp2p v0.47.0 - P2P transport, relay, hole-punching
• go-libp2p-kad-dht v0.28.1 - Distributed peer discovery
• go-multiaddr - Network address format

File Transfer:

• zeebo/blake3 v0.2.4 (CC0) - Per-chunk hash + Merkle tree integrity
• klauspost/compress v1.18.4 (BSD-3) - zstd streaming compression
• klauspost/reedsolomon v1.13.2 (MIT) - Erasure coding for loss recovery
• xssnick/raptorq v1.3.0 (MIT) - Fountain codes for multi-source download

ZKP:

• gnark v0.14.0 - PLONK zero-knowledge proofs

Other:

• gopkg.in/yaml.v3 v3.0.1 - Configuration

• Laurie Kirk (LaurieWired) - Hedged connection racing pattern adapted from her Tail Slayer research (video), which applied Google's "The Tail at Scale" concept to DRAM refresh stalls. Shurli applies the same principle to relay fallback, bootstrap connections, and multi-peer transfers.

MIT