Skip to content
Join the waitlistWaitlist

Deploy Guard

Where Guard can run, what every install has in common, and which page to read for your platform.

Guard runs where you run it: your laptop, a home server, or a server you rent. We host nothing that holds a key.

The setup below takes what you set on this site (your rules, the account you watched), detects your system, and writes one command to run on the machine where your bot runs (a server over SSH is the other way). Every command matches Guard’s v1.0.0 release. Your key is typed on the machine where Guard runs, never on this page.

  1. Choose the machine where the bot runs. Use the setup below as the main route; it selects a platform-specific command.
  2. Verify the release. Follow Verify a release before running it. The names and commands here remain planned until Guard’s first release.
  3. Start in paper mode. Follow Quickstart and inspect the first decisions before considering testnet.
  4. Connect the bot. Use its integration guide, keeping the client key separate from the API wallet key.
stored only in this browser · ·

Your settings from this site

The default rules. Set your own on the playground, or paste a rules code.

  • 5× max
  • 2.0% at stop
  • no stop: Guard sets one
  • liq. ≥ 10%
  • size ≤ 200%
  • open ≤ 6%
  • daily 6%
  • drawdown 25%
  • 5/5 markets
  • paper mode
Start Guard in
Paper: real prices, no orders, no key. Mainnet is never preset from a web page: you type it on the server, and the account again.

Where Guard runs

Next to your bot: run the command on the machine where your bot runs. If that is a server you reach over SSH, pick “On a server”.

Other ways to run it: On a server (SSH) · One-click · Packages · Docker.

Your system
Detected from this browser; pick another if your bot runs elsewhere.

Guard listens on 127.0.0.1:8547 only, on this machine. Every command here matches the release (zunder-guard v1.0.0).

Secrets: typed where Guard runs, never here

This page never asks for a key, and no command it makes contains one. Shell history, screen sharing and this browser would all keep it.

API wallet private key

For testnet and mainnet. Create an API wallet in the Hyperliquid app: it can trade, it cannot withdraw. Guard asks for its key with hidden input on the server and stores it encrypted for the service. API wallets

Alert webhook, optional

A webhook URL is a bearer secret too. Add it on the server, in Guard's config, after the setup. Configuration

Public values: safe to enter here, checked in this browser

this machine · what the setup asks
$ curl -fsSL https://zunder-design-preview.pages.dev/i | sh -s -- --rules zr1_eyJ2IjoxLCJtYXhMZXZlcmFnZSI6NSwibWF4…✓ installer verified: Sigstore signature of the v1.0.0 checksums (zunderlabs/zunder-guard)✓ zunder-guard 1.0.0 installed to /usr/local/bin · service user zunder-guard Your rules from zunderlabs.com  max leverage 5× · loss at stop 2% · no stop: Guard sets one 2% away  liquidation ≥ 10% · size ≤ 200% · open risk ≤ 6%  daily loss stop 6% · drawdown halt 25% · markets: allKeep these rules? [Y/edit] › YHyperliquid account address › 0x8c41…a90fMode [paper/testnet/mainnet] › paper✓ paper mode: real prices, no orders, no key needed ✓ Guard is running (systemd: zunder-guard) · 127.0.0.1:8547 · paperClient key for your bot (shown once): zc_7Hq2…Lm9xNext: point your bot at http://127.0.0.1:8547

Run this where your bot runs

One command with your rules, on this machine. It installs Guard after checking the release’s signature and asks you the rest here.

terminal
curl -fsSL https://zunder-design-preview.pages.dev/i | sh -s -- --rules zr1_eyJ2IjoxLCJt…siKiJdfQ

Hover or focus a part of the command to see what it does.

Every command on this page matches the release (zunder-guard v1.0.0). Prefer to read first? curl -fsSLO https://zunder-design-preview.pages.dev/i && less i, then sh i --rules …. Or verify by hand: Verify a release.

Check it, then point your bot at it

On the machine where Guard runs:

curl -fsS http://127.0.0.1:8547/healthz# {"status":"ok"}: Guard is upcurl -fsS http://127.0.0.1:8547/guard/status# version, mode, network, account and state, read-only
  • It starts in paper mode. Real prices, no orders sent. Testnet next. Mainnet only when you type it (Paper, testnet and mainnet).
  • It listens on localhost only (127.0.0.1:8547) unless you configure otherwise.
  • It talks to Hyperliquid only. The relay and telemetry are off unless you turn them on (Network footprint).
  • Every release can be verified before you run it (Verify a release).
  • The API wallet key is created by you in the Hyperliquid app and given to Guard on your machine. It never passes through us.
You haveRead
a Mac or Linux, where your bot runsthe one-liner above (curl -fsSL https://zunder-design-preview.pages.dev/i | sh -s -- --rules …), or Homebrew
Windowsthe PowerShell one-liner above (& ([scriptblock]::Create((irm https://zunder-design-preview.pages.dev/i.ps1))) -Rules …), or Docker
a server you reach over SSHOne SSH command, run from your computer
Docker anywhereDocker
no server yetOne-click templates

Next to your bot. Guard listens on localhost, so the bot and Guard belong on the same machine, or in the same private network.

Close to Hyperliquid matters more than anything Guard does. Guard adds about 3 ms per order; the trip to Hyperliquid is the larger part: 4.5 ms there and back from Tokyo, 238 ms from Frankfurt (medians; Latency). When the account stream is not current Guard reads the account first, one more round trip. Run Guard and your bot in Tokyo (AWS ap-northeast-1), with Guard’s data directory on a local SSD: its decision journal is synced to disk before each order goes out. Zunder’s research treats a host in Tokyo (ap-northeast-1) as next to Hyperliquid (docs/decisions.md, 5 Oct 2026).

One Guard guards one account. Hyperliquid allows 1,200 of request weight a minute per IP address, and a Guard alone sizes its budgets for all of it. Running several Guards on one machine (or behind one IP address)? Give each ip_share = 1/N, written as a decimal: "0.5" for two, "0.3333" for three (init --ip-share 0.5, or ip_share in guard.toml), every one of them, the first included, so that together they stay within the limit and each keeps a reserve for its own stops and closes (Config keys). Give each its own home and listen port, and start them a few seconds apart.

Guard refuses a share too small to keep it safe: at most three Guards per IP address with the main dex alone, two with one HIP-3 dex, one with two. Your bots’ own calls to Hyperliquid and this site’s browser tools spend the same 1,200, so leave them room.

  • A Linux server (the SSH command): encrypted with systemd-creds (systemd 250 or newer: Ubuntu 24.04, Debian 12 and later), with the host key and the TPM where there is one. systemd decrypts it only when it starts the service, into memory only the service can read. A copy of the disk without the host key is useless. Root on the running machine can still read it, as root can read any process’s memory. On older systemd: a file readable only by Guard’s own user, and the installer warns.
  • Docker: a file in the volume, mode 0600, owned by the container’s user.
  • macOS, and anywhere systemd-creds is not available: the file api-wallet-key in Guard’s home, mode 0600, readable only by you. Guard says at setup that the key lies there in plain text. There is no keychain support.
  • Mainnet, everywhere: the key is never stored. It is checked once at setup and comes on standard input at every start (under systemd: from an encrypted systemd-creds credential).

Everywhere: the key belongs to an API wallet that can trade but cannot withdraw, on an account that holds only what you are willing to risk. It is typed into Guard’s hidden prompt, never into a command line, a URL or this site.

This page as plain Markdown, for people and LLMs: /docs/deploy.md