Administrator setup · free SDK and paid host pilots

From checkout to your first safe test.

Install Node Guard Free or choose a signed host beta for noncritical Ubuntu 24.04 AMD64 evaluation. Start host protection in TEST and keep a separate recovery console.

Install Node Guard Free Compare paid hosts Get Node Pro Get Core Beta

Check your environment and choose a path

Node Guard Free needs Node.js 20 or newer, one persistent application process, and a trusted source for the real client IP. Node Pro and Infrastructure Core need a noncritical Ubuntu 24.04 AMD64 host; the tested Core path uses generic XDP. Node Pro needs a dedicated Linux user for each protected app.

Node Guard Free needs no checkout. One paid block covers up to five Linux hosts; two cover ten. Each host uses one slot regardless of CPU or worker count and receives a separate signed JSON license. Orders above nine licenses arrive as a ZIP. Review current pricing and availability.

For a paid host pilot, find your license and package

After the invoice is paid, search your checkout inbox and spam folder for the HoneyMesh license email. Save the JSON attachments in a private folder. For an order above nine hosts, extract the attached ZIP into that folder; assign a different JSON license file to each host. If the email does not arrive, contact Admin@Network-Decode.com with your Stripe invoice number. Never email app secrets or passwords.

Node Pro buyers use Node Pro access and Infrastructure Core buyers use Core Beta access. Verify the same billing email used at checkout before downloading the plan on your receipt.

ls -lh ~/Downloads/HoneyMesh-*.tar.gz 2>/dev/null

If installation is on a separate VPS, copy the package and its matching emailed JSON license there over SSH. Replace FILE, LICENSE.json, USER, and HOST with the real filenames and hosting-provider login details. Keep the license out of any public web directory.

scp ~/Downloads/FILE USER@HOST:~/

scp ~/Downloads/LICENSE.json USER@HOST:~/

For a paid host pilot, check the publisher and package hash

Compare sha256sum FILE with the exact plan archive hash on paid host access. The publisher fingerprint is C59DB2A1911DDB6FDD718C14CD3F4417586EE6E4. Verify the detached manifest signature and internal package checksums in the extracted archive before installing anything. Stop if a hash, signature, fingerprint, or plan differs.

cd ~/Downloads  # or the folder containing the package
sha256sum FILE

Customer archives include CUSTOMER_INSTALL.md, a signed manifest, public key, and package checksums. Follow the instructions and hashes in the exact downloaded release.

For an already installed paid host agent

Open the local HoneyMesh SOC

On the protected host, confirm the service is running and read its current mode. Keep it in TEST while you check normal traffic and recovery.
Read the locally generated admin token from private runtime state. Enter your computer's sudo password when prompted. The command prints the token only in your terminal; never send it to support, put it in a screenshot, or add it to a shell command.
Open https://127.0.0.1:8443 on that host and paste the token into the Enter Admin Token prompt. If the browser was already open with an empty or wrong token, refresh the page to get the prompt again.

sudo systemctl status honeymesh.service --no-pager
curl --cacert /etc/honeymesh/certs/ca/ca.crt https://127.0.0.1:8443/api/health
sudo jq -r '.admin_token' /var/lib/honeymesh/runtime-state.json

The root configuration at /etc/honeymesh/honeymesh.json can have an empty admin_token; the agent generates and saves the active token in /var/lib/honeymesh/runtime-state.json. The SOC admin token, your emailed paid license, and the Firewall console login are separate credentials. If the command prints nothing, contact support before changing either file.

For a remote VPS, keep the SOC bound to loopback and use ssh -L 8443:127.0.0.1:8443 USER@HOST from your laptop. Confirm the local CA before trusting the browser certificate. Seeing interfaces and events confirms the console can read the agent; it does not by itself prove ENFORCE or a paid entitlement. Review the interface, TEST mode, and rollback path before changing mode.

Path A · application only

Node Guard

Install the free SDK in the Node.js app you want to protect. It needs no account, license, root access, or HoneyMesh agent and does not attach XDP.

Install the published free alpha

cd /path/to/your-app
node --version
npm install @network-decode/node-guard@0.2.0-alpha.12
npx nodeguard init
npx nodeguard doctor nodeguard.policy.json
npx nodeguard policy validate nodeguard.policy.json

init creates an OBSERVE policy and refuses to overwrite an existing file. Check your lockfile for the exact package version and npm integrity hash.

Connect verified events in OBSERVE

Replace /path/to/your-app with your application directory. Follow the developer setup for Express or the Next Route Handler guide. Your application must verify the source and explicitly record a security event; the SDK does not classify every request automatically.

cp node_modules/@network-decode/node-guard/examples/auth-observations.json ./observations.json
npx nodeguard policy test nodeguard.policy.json observations.json --at 2026-11-03T18:00:00Z

The included synthetic events should produce an OBSERVE decision without blocking. The example file is in the installed npm package. This simulation does not prove your real application has recorded an event.

Use createPolicyGuardV1 with the generated policy. Keep mode: "OBSERVE" during normal traffic review. Do not take client identity from a raw forwarding header or request body.

Check traffic and keep a rollback

Run normal requests and one controlled known-bad event from a source you control. Check decisions in your app logs. Exclude operator and monitor addresses before considering ENFORCE, which limits requests in the application. Roll back by returning to OBSERVE or redeploying your prior app build. Process-local limits clear on restart. Multiple workers do not share counters in this alpha.

Path B · Linux host and app

Node Pro

Buy Node Pro for $10 per five-host block, then verify your billing email on Node Pro access. Download the signed Node Pro archive matched to your receipt. Each host needs a distinct emailed node_pro license document.

Verify the exact archive

Compare the archive SHA-256 on the access page, check publisher fingerprint C59DB2A1911DDB6FDD718C14CD3F4417586EE6E4, and verify the included manifest-node_pro.asc against manifest-node_pro.json. Follow the bundled CUSTOMER_INSTALL.md and NODE_PRO_APP_BRIDGE.md; they match this agent and bridge release.

Start with one protected application

Use a noncritical Ubuntu 24.04 AMD64 host with a separate provider console. Install the Node Pro Debian package from the verified archive, import one emailed license for this host, and register one application with its dedicated Linux UID and private secret. Keep the agent in TEST and auto_block off while reviewing normal traffic and a controlled event.

Review recovery before enforcement

Keep the included CUSTOMER_UPDATE.md with the archive. Confirm agent health, the application bridge identity, the intended XDP interface, and a provider-console recovery path before enabling scoped host actions. Preserve existing state when updating an installed host.

Path C · local Linux protection

Infrastructure Core Beta

Buy Infrastructure Pro for $15 per five-host block, then verify your billing email on Core Beta access. Download the signed Core and Firewall archive matched to the plan; each host needs its own emailed PRO license document.

Verify and install the signed Core archive

Compare the archive SHA-256 on the access page, check publisher fingerprint C59DB2A1911DDB6FDD718C14CD3F4417586EE6E4, and verify the included manifest-core.asc against manifest-core.json. Follow CUSTOMER_INSTALL.md from that archive. Start in TEST and keep trusted sharing off.

Observe, test, and keep recovery ready

Before an ENFORCE test, confirm a separate provider console, protected management addresses, one controlled source and an independent control source. Select only the intended interface. Verify block and release, then return to TEST. Use the bundled CUSTOMER_UPDATE.md for version-matched rollback and updates.

Loading HoneyMesh...

Open the local HoneyMesh SOC

On the protected host, confirm the service is running and read its current mode. Keep it in TEST while you check normal traffic and recovery.

Read the locally generated admin token from private runtime state. Enter your computer's sudo password when prompted. The command prints the token only in your terminal; never send it to support, put it in a screenshot, or add it to a shell command.

Open https://127.0.0.1:8443 on that host and paste the token into the Enter Admin Token prompt. If the browser was already open with an empty or wrong token, refresh the page to get the prompt again.

sudo systemctl status honeymesh.service --no-pager curl --cacert /etc/honeymesh/certs/ca/ca.crt https://127.0.0.1:8443/api/health sudo jq -r '.admin_token' /var/lib/honeymesh/runtime-state.json