GO PEER SDK - FLEET DEPLOYMENT GUIDE

Headless Linux x86-64 package 1.6.8. Persistent identity, protected-key service installation, and measured fleet onboarding.
Quick Start | Config | Stable Identity (READ THIS) | Fleet Deployment | systemd | Docker | Earnings | Windows SDK

For AI agents: this page is the complete, self-contained spec to deploy a peer fleet in Go. Read the "Stable Identity" section before scaling - doing it wrong creates a new device on every reconnect and gets the account capped.

WHAT THIS IS

A drop-in Go peer that shares an internet connection's bandwidth and earns USDC. It speaks the complete Proxies.sx relay protocol - identical wire format to the Node, Windows, and Android SDKs:

One file, one dependency (gorilla/websocket). Source: reference-sdk.go + go.mod.

LINUX X86-64: DOWNLOAD, NO GUI OR COMPILER

Reconnect stability: HTTP 429/502/503 and short connections now use bounded exponential backoff, Retry-After and jitter. A healthy stream for one minute resets the retry streak. Preserve the original key, name and state, and upgrade one stopped device first.

Go 1.6.8: authenticated relay assignments remain in the fallback cycle and are saved atomically with the existing identity. A peer can return to its assigned relay after an outage or SDK restart. Keep the original key, device name and state when updating.

Connection incident — October 3: the original EU and US SDK relays have intermittent connection failures under load. This client update protects connection handling; it does not establish that server recovery is complete. Preserve your existing key, device name and state, and avoid repeated reinstalls or whole-fleet restarts.

Headless Go peer 1.6.8, October 6, 2026. Download standalone Linux x86-64 package · SHA-256 checksums · 中文安装说明 · Full installation / upgrade guide. No Go, Node.js, Docker or desktop UI is needed on the device. Requires outbound network access and OS CA certificates. The service installer needs systemd 235+ and sudo.

Open SDK / device API keys, select the SDK/device preset, name the key and save its one-time secret privately. Use only consented devices and complete the current Partner Agreement. A key does not approve or list a device.

mkdir -p proxies-peer-install && cd proxies-peer-install
curl -fLO https://agents.proxies.sx/peer/releases/1.6.8/proxies-peer-linux-amd64.tar.gz
curl -fLO https://agents.proxies.sx/peer/releases/1.6.8/SHA256SUMS
sha256sum -c SHA256SUMS
tar -xzf proxies-peer-linux-amd64.tar.gz
cd proxies-peer-linux-amd64
sudo bash install.sh
# Enter the SDK key privately when prompted.
/usr/local/bin/proxies-peer -version
sudo journalctl -u proxies-peer -n 40 --no-pager

Allow up to 30 seconds of startup jitter. Expect REGISTERED or RESUMED, then CONNECTED and ACK. Relay hostnames depend on the assigned region. Keep configuration and state on disk; do not clone them to other devices. See the full guide for direct execution without systemd.

Build from source (optional)

Use a currently supported Go compiler. The source module targets Go 1.21+, but an old minimum is not a recommendation to use an unsupported compiler. Cross-compile once; devices do not need Go.

set -eu
build_dir="$(mktemp -d)"
cd "$build_dir"
curl -fL -H 'Cache-Control: no-cache' -o reference-sdk.go 'https://agents.proxies.sx/peer/releases/1.6.8/reference-sdk.go'
curl -fL -H 'Cache-Control: no-cache' -o go.mod 'https://agents.proxies.sx/peer/releases/1.6.8/go.mod'
curl -fL -H 'Cache-Control: no-cache' -o go.sum 'https://agents.proxies.sx/peer/releases/1.6.8/go.sum'
sha256sum -c <<'SHA256SUMS'
d18b26f4180fb73c9e1c7edcf8c764921132d967066d9e364824b1692a957ae6  reference-sdk.go
f9bce7d0fa8c432f56c968e117ec09dd9a5896b88866fccc4b11437453e62110  go.mod
1737d5523b7264df09b253e86e29f96af295a7bd18e0aaa4373c6099317e065f  go.sum
SHA256SUMS
go mod download
go mod verify
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -o proxies-peer reference-sdk.go
./proxies-peer -version

The final command must print proxies-peer 1.6.8 before installation; it does not register a device. Run this check on the Linux x86-64 target if cross-compiling. Stop if any checksum differs. These source/module files and the package are immutable under the 1.6.8 release directory; downloading them does not update an installed process. Follow the upgrade guide for one stopped device and preserve its original key, name and state.

CONFIGURATION

Flags override environment variables. Keep secrets out of command-line arguments and shared logs. The installer uses a root-only /etc/proxies-peer/peer.env.

Flag / environmentMeaning
-key / API_KEYRequired farmer SDK/device key; use the protected environment file.
-name / AGENT_NAMEStable unique name. If absent, a random 128-bit name is generated once and persisted.
-state / PEER_STATE_FILEIdentity and refresh token. Default ~/.proxies-peer-state.json; installed service uses /var/lib/proxies-peer/state.json.
-connections / WS_CONNECTIONSSDK default 4; installer starts with 1. Default clamp 1–5; hard maximum 6. Start conservatively and measure.
REGISTER_JITTER_MSGo 1.6.1 startup spread, default 30000 ms, maximum 3600000. Does not replace centrally paced rollout.
-country / COUNTRYInformational hint; actual exit IP classification/country controls routing. Cannot turn a datacenter exit into mobile.
-relay / RELAY_URLLeave unset for regional assignment. Custom farmer-domain support requires a separate reviewed deployment.
-verbose / VERBOSE=trueTunnel diagnostics; leave off for routine fleets.
-versionShow version without making network requests.

1.6.8 reliability update: failing sibling sockets no longer switch relay while an acknowledged connection on that relay is live. Standalone source builds default to one socket; explicit connection settings are retained. Backoff, redirect continuity and the public IPv4 target guard remain. This does not resolve server overload by itself. Existing key/name/state and relay protocol remain unchanged. Update one stopped device first using the upgrade instructions; publication does not update running installations or prove fleet capacity.

1.6.1 retries transient registration failures at most five times, with exponential backoff, jitter and Retry-After (seconds or HTTP date). Persistent 401/403 needs key/account/agreement review, not more devices or keys.

STABLE IDENTITY

The server creates agent_ plus the first 16 hexadecimal characters of SHA256(apiKey + ":" + name). Keep the same key and name. Go 1.6.1 saves the resolved name, device ID and refresh token atomically with mode 0600, and stops visibly if persistence fails. It rejects a saved identity bound to a different key or name.

Preserve both /etc/proxies-peer/peer.env and the service state directory. Never clone populated state or a configured device name into another device image. /etc/machine-id is only suitable if your images actually regenerate it; the installer instead saves a distinct random name once. Legacy named state migrates once using the same key/name; old nameless state needs its original explicit name. Restore corrupt state before retrying.

Multiple devices behind a carrier NAT can share an exit IP; they are not additional distinct exits. Multiple processes do not automatically use different modems. Supply separate real uplinks using your own network isolation if needed.

STAGED FLEET DEPLOYMENT

Start with one device, then a small controlled cohort. Progress toward an agreed pilot only after checking unique identities, actual exit country/type, verification, listing, customer tunnel success, token refresh/reconnect, usage metering and relay/API resource headroom. Do not launch thousands together or treat an account cap as tested concurrent capacity.

At the September 25 audit, configured registration guards were 200,000 total and 20,000 unproven devices, applied per registering SDK key. Proven means verified or previously served traffic. These are admission guards, not a performance promise; do not bypass them by creating extra keys. Request a reviewed onboarding window through maya@proxies.sx. The server enforces source/shared registration limits and relay/NAT socket limits; do not rely on the old “50 sockets per IP” instruction.

Provision one unique stable AGENT_NAME and private environment file per device. The installer uses one socket initially. Central pacing and stop conditions for sustained 429/5xx or rising disconnects are still required even with client jitter. Fleet counts and customer demand must be measured separately.

SYSTEMD SERVICE

The package installer sets this up. It runs with a dynamic unprivileged user, private persistent state and a root-only key file; no key appears in the unit. It preserves an existing configuration and refuses to replace a currently running service. Stop an existing peer in that device’s maintenance window before upgrading.

[Unit]
Description=Proxies.sx headless peer
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=simple
DynamicUser=yes
StateDirectory=proxies-peer
StateDirectoryMode=0700
EnvironmentFile=/etc/proxies-peer/peer.env
Environment=PEER_STATE_FILE=/var/lib/proxies-peer/state.json
ExecStart=/usr/local/bin/proxies-peer
Restart=on-failure
RestartSec=60
UMask=0077
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
CapabilityBoundingSet=

[Install]
WantedBy=multi-user.target
sudo systemctl status proxies-peer --no-pager
sudo journalctl -u proxies-peer -f
# Stop sharing and prevent boot startup (preserves identity):
sudo systemctl disable --now proxies-peer

For permanent removal stop the process first, remove the dashboard device, then remove its local secrets/state under your retention policy. Do not revoke a shared fleet key to remove one device.

CONTAINERS AND OTHER ORCHESTRATORS

Use the direct-run instructions in install.md. Run the static binary as an unprivileged user in a Linux image with CA certificates. Supply the key through your secret manager and a writable persistent state volume, with a unique stable name per real device. Do not run the systemd installer inside a container without systemd. Container replicas on a single default route do not create distinct residential/mobile exits.

HOW IT WORKS (protocol, in order)

1. Register   POST /v1/peer/agents/register {name, type:"custom", apiKey, sdkVersion}
              -> { deviceId, token|jwt, refreshToken, relay, earningsPerGB }
              deviceId = "agent_" + first16hex(SHA256(apiKey + ":" + name))
2. Connect    wss to register.relay, JWT in Sec-WebSocket-Protocol as token.<jwt>
              (NEVER in the URL). Opens WS_CONNECTIONS parallel sockets.
3. device_info  announce {country, protocol:"binary-v1", supportsRelayRedirect:true}
4. Heartbeat  every 30s
5. tunnel_connect  open raw TCP to target host:port, stream bytes both ways.
              HTTPS stays end-to-end - do NOT terminate TLS at the peer.
6. relay_redirect  server can move you to a nearer relay; the pool reconnects there.

If you write your own client, the two mistakes that cause "intermittent auth" and "zero traffic": put the JWT in the Sec-WebSocket-Protocol header (not the URL), and on a 4001/4002 close refresh identity once for all sockets (do not relaunch the whole pool). The reference file documents both inline.

QUALITY AND EARNINGS

Installed, connected, verified, listed, routable and earning are separate states. Verification and quality probes run through separate queues; there is no guaranteed “five probes then approved” or fixed completion time. Read the current routing throughput floor from the registration throughputContract.minKBps (KiB/s, 1024 bytes per second per unit); it is configurable and is not an SDK-version constant. Meeting that floor still requires the applicable latency, quality, country, consent and account checks. Do not lower quality or consent requirements just to increase device counts.

Actual qualified mobile egress is required for mobile-only supply; an Android device or Linux label does not prove it. Customer demand determines usage. Commercial shares follow your confirmed agreement and actual eligible sales; installation does not guarantee traffic, revenue or a fixed payment.

ACCEPTANCE CHECKS

Online + verified is a useful checkpoint, but does not prove listing or successful customer traffic. Check the dashboard, then arrange a bounded customer-routing test with support before scaling. Such a test needs separate customer proxy credentials and an existing traffic balance or support-arranged access; the farmer SDK key is not a proxy password. Do not buy a package just to prove the installer starts.

Confirm the same device identity after restart, successful reconnect/token refresh, correct exit country and network type, tunnel success and metered usage. Share UTC time, SDK version, one device name/ID and redacted error logs. Never send keys, tokens, state files or full environment files in chat.