Quick Start

Get started in a few minutes — here's the universal first step, then pick what you want to do.

Add a device

Connect your devices privately

Expose a local service to the internet

Bridge a private network into the mesh

Route internet traffic through another device

Back up your phone to your own storage

Run a private AI server

Put a gateway in front of your AI

How It Works

HostAnywhere has six features that work independently or together:

• Public Services — expose any local port to the internet via a *.hostanywhere.io subdomain. No router config, no static IP needed.
• Private Mesh Network — all your devices (and your team's devices) get a private IP and can reach each other directly, from anywhere, as if they were on the same LAN.
• Internet Gateway — route a laptop's outbound internet traffic through your home or office connection, like a personal VPN you fully own.
• Storage Server & Backups — back up your phones (Photos, Contacts, Calendars, more) to one of your own devices, end-to-end encrypted before upload.
• AI Server — turn one of your own devices into a private AI server. Run open models on your own hardware (or adopt an AI setup you already have), so you and your team get AI without prompts or data ever leaving your control — with an optional one-click web chat to use it from any browser.
• AI Gateway — a single, OpenAI-compatible endpoint in front of all your AI, whether it runs on your own device or on cloud providers. It injects your provider API keys so they're never exposed to clients, and gives you one place to control, secure, and measure every AI request. It's three gateways in one:
  • LLM Gateway — one endpoint for chat and embeddings.
  • MCP Gateway — one endpoint in front of your MCP tool servers.
  • A2A Gateway — one endpoint for agent-to-agent traffic.
  And across all three:
  • Routes — send each request to the right model with your own rules: try your local AI Server first and fall back to cloud providers (OpenAI, Anthropic, Gemini, and more), or route by conditions like which app is calling, prompt size, or whether an image is attached.
  • Guardrails — check prompts, tool calls, and responses for unsafe content, prompt-injection attempts, and PII — flagging or blocking automatically before anything reaches a model or leaves your network.
  • Caching — turn on response caching to serve repeat requests instantly from a cached answer, cutting both latency and provider costs.
  • Spend limits — set budget caps per team, key, or model, and requests are turned away once a limit is hit — no surprise bills.
  • Observability — see every request, token, and dollar: usage and cost by user, model, and route, error and cache stats, and a live view of what guardrails caught.

The agent handles all of them. Install it once on a device and it manages public services, the private mesh network connection, and — optionally — a storage server for backups and an AI Server with its gateways. Prefer not to run it on your own hardware? The AI Gateway is also available fully hosted, so you can use it from the cloud with no agent to install.

Add a Device

Install the agent on any device to connect it to your private mesh network and expose local services.

📺 Prefer to watch? Each platform below has a short walkthrough video.

Windows

macOS

Linux

curl -fsSL https://hostanywhere.io/install.sh | sh

hostanywhere login

iOS

Android

Expose a Service

Expose a Service creates a public URL for something running on your local machine — a dev server, a self-hosted app, a webhook receiver, a media server — without opening ports on your router or having a public IP. The agent on your machine opens an outbound connection to the HostAnywhere relay; visitors hit the relay over HTTPS at your chosen subdomain (e.g. https://myapp.hostanywhere.io), and the relay forwards the request through that tunnel to your local port.

Typical use cases:

• Sharing a dev preview with a teammate or client without deploying anywhere.
• Receiving webhooks during development.
• Sharing a self-hosted app with family or friends without setting up a VPN for them.
• Letting a phone reach a local app on a desktop when off the same Wi-Fi.
• Quick demos that need a real public URL.

Why it works:

• The agent only makes outbound connections, so there's nothing to configure on your router — works behind NAT and CGNAT.
• HTTPS is built in. Every subdomain lands on *.hostanywhere.io with a valid TLS certificate, no configuration needed.
• Multiple services per machine — one tunnel per service.

How to expose a service

From the dashboard, click + Expose a Service and fill in:

• Subdomain — the public URL prefix, e.g. myapp → https://myapp.hostanywhere.io
• Local address — where the traffic should go on your machine, e.g. localhost:3000

Private Network

Every device running the agent is assigned a private IP address and can reach any other device on your network directly — no VPN setup, no configuration required.

• Devices get a stable private IP in the 100.64.x.x range.
• Any port on any device is accessible from other devices on the same network.
• Works even if devices are behind different routers, carriers, or on different continents.
• When you invite teammates, their devices automatically join the same private network.

Finding your private IP

Your device's private IP appears in the dashboard under Devices — click a device card to see it. It's also shown in the Windows tray or macOS menu bar icon.

VPN Gateway

A VPN Gateway lets one device act as a bridge between your mesh and a private network the mesh can't reach directly — your home LAN, an office network, or a datacenter subnet. Any mesh peer can then reach resources on those networks (printers, NAS, servers, cameras, management interfaces) without running the HostAnywhere agent on each one.

This is useful when:

• You have legacy devices (printers, IoT, IPMI/iDRAC consoles) that can't run an agent.
• You want one device to tunnel your mesh into a corporate LAN.
• You're bridging a datacenter subnet or VPC range into the mesh.

How it works

Designate any device as a VPN Gateway and tell it which private CIDRs it can route to (e.g. 192.168.1.0/24, up to 10 subnets per gateway). Other mesh peers learn those routes automatically and forward traffic for those ranges through the gateway. Peer-to-peer traffic between mesh devices continues to flow directly as before.

Enable a VPN Gateway

Other mesh peers pick up the new routes within seconds and can start reaching addresses in those ranges.

Multiple gateways

You can designate more than one device as a VPN Gateway — useful for bridging your mesh into multiple private networks (home, office, datacenter) at once. Each gateway advertises its own subnet list independently.

Internet Gateway

An Internet Gateway routes a device's entire outbound internet traffic (0.0.0.0/0) through another mesh peer — like a personal VPN that terminates on hardware you fully own. Where VPN Gateway gives mesh peers access to a private LAN, Internet Gateway routes a peer's web/app traffic out through another peer.

This is useful when:

• You're on hotel or coffee-shop Wi-Fi and want every packet to leave from your home connection instead.
• A region- or geo-blocked service should see you as connecting from a device in another region.
• You want an end-to-end-encrypted hop for all internet traffic from a laptop you don't fully trust the local network of.

How it works

Designate up to three devices on your mesh as gateways, ranked by priority: Primary, Secondary, and Tertiary. The agent on the gateway side enables IP forwarding and installs a NAT rule so mesh traffic exits through the gateway's WAN interface. On the client side, the agent installs a default route pointing at the chosen gateway. Failover is automatic — if the Primary goes offline, peers fall back to Secondary within seconds, then Tertiary if needed. Peer-to-peer traffic between mesh devices continues to flow directly as before.

Enable an Internet Gateway

Multiple gateways & failover

The 3-slot priority system gives you redundancy without per-peer routing choices. The mesh always uses the highest-priority gateway that's currently online. A common pattern: Primary = your always-on home server, Secondary = your work device, Tertiary = a cloud VPS. If your home internet drops, traffic falls through automatically.

Storage Server, Backups & Library

HostAnywhere lets you back up your phones to your own hardware. Three pieces:

• Storage Server — a small encrypted-blob store the desktop agent runs on a Mac, Linux, or Windows device you own.
• Backups — the iOS and Android apps push selected categories (Photos, Contacts, Calendars, etc.) to your storage server.
• Library — a tab in the mobile app to browse and restore everything you've backed up, from any of your signed-in devices.

Every file is encrypted on your phone before it leaves the device. HostAnywhere's servers never hold your data.

Storage Server

A storage server runs as a background process inside the desktop agent. It listens on TCP port 36129 inside your private mesh, serves a self-signed TLS certificate (its SHA-256 fingerprint is pinned by the phones), and accepts encrypted blob uploads from your phones.

Enable a storage server

Where backups are stored on disk

You can override the path under Advanced. Useful when you want backups on a specific external drive, a separate NAS volume, or a non-default partition.

Multiple storage servers

You can run storage servers on more than one device. Phones automatically pick the one with the lowest latency on each sync (mesh first, internet fallback). Each server keeps an independent copy of the data uploaded to it — handy if you want a primary at home plus a backup on a different drive or in a different location.

Backups (iOS & Android)

The mobile app's Backups tab is where each phone picks what to back up. Categories are off by default; you opt in per category, and each toggle prompts for the OS permission it needs the first time you enable it.

What can be backed up

Enable a backup category

End-to-end encryption

Every file is encrypted on the phone before it's uploaded. AES-256-GCM with convergent encryption: the data-encryption key for a given file is derived from its own SHA-256 hash, then wrapped with a master key that exists only on your phones. Master keys are generated locally on first sync — escrowed via iCloud Keychain on iOS, stored in Android Keystore-backed encrypted preferences on Android. HostAnywhere has no copy and can't decrypt anything.

On iOS, encryption is always on (no toggle). On Android, encryption defaults to on with a Settings toggle for parity with iOS conventions.

Cellular vs Wi-Fi

By default backups only run on Wi-Fi to avoid surprise data usage. A "Back up over cellular" toggle in Settings flips that.

Library

The Library tab in the mobile app lists everything you've backed up, grouped by category, across all your storage servers. Each item shows its category, size, and the date it was backed up.

Restore from another device

AI Server

Turn a computer you own into a private AI server — run open models locally, add a ChatGPT-style web chat, and reach it from your other devices or (optionally) the whole internet. Your prompts never leave hardware you control.

Turn on the AI Server

Install a model

Under Manage models, pick a suggested model (for example deepseek-r1:8b) and click install. Progress shows inline; it appears under Installed when ready. On a CPU-only box, expect a few tokens per second — a GPU is much faster.

Use your own server instead

Already run a model server on that machine? Expand Advanced, set Inference backend to Other OpenAI-compatible endpoint, enter its base URL (the /v1 path is added for you), and click Connect. Works with LM Studio, LocalAI, llama.cpp, vLLM, Jan, and anything else that speaks the OpenAI /v1 API.

Web Chat — a browser UI for your models

Web Chat is a ChatGPT-style interface (powered by Open WebUI) that HostAnywhere installs and keeps running on your AI Server device. Chat from any browser on your private network — or expose it to the internet with one click.

Install Web Chat

Create your account (do this before exposing)

Open the mesh link from any device on your private network and sign up. Two things to know:

• There's no default password — the first person to sign up becomes the admin and sets their own credentials.
• Until an admin account exists, Expose to the internet stays disabled (labelled “Sign up first to expose”) — a guard so you can never publish an unclaimed, open instance.

Use it over the mesh

Click Open Web Chat (or visit the http://<mesh-ip>:8080 link) from any device signed in to your private network, pick a model, and chat. Requests run on your hardware and travel only between your own devices over the encrypted mesh.

Expose Web Chat to the internet

Want to reach your private AI from anywhere — a phone on cellular, a laptop off your network? Expose Web Chat. HostAnywhere creates a public HTTPS address that tunnels straight to the Web Chat running on your device: no port forwarding, no public IP, no inbound firewall changes.

Reach it from your apps

Web Chat is for browsers. For code, point an OpenAI client at the device's model endpoint over the mesh — or put an AI Gateway in front for one stable URL, API keys, routing and cloud failover.

curl https://100.64.13.10:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-r1:8b","messages":[{"role":"user","content":"Hello"}]}'

AI Gateway

One place to govern every AI boundary your apps cross. The AI Gateway speaks the OpenAI API and gives you a single authenticated, guardrailed entry point for three things: the models your apps call, the tools your agents use, and the agents they hand off to. Provider keys, tool credentials, and agent secrets all stay on the gateway — never in your app code. Configure it once at the account level, and every gateway you run shares the same providers, routes, keys, guardrails, spend limits, and usage.

Start here — the Overview

Open Dashboard → AI Gateway and you land on the Overview tab: a guided checklist that walks you to your first working request in about two minutes. It tracks four steps and always shows what's next.

The three gateways

The AI Gateway governs three boundaries, each an endpoint on the same gateway. They share one set of keys, guardrails, spend limits, and usage — you set those up once and they apply everywhere.

• On your device — each gateway runs inside the desktop agent on your mesh. Local-first: it reaches your own AI Servers, MCP servers, and agents without leaving your network. Enable per device under AI Gateway → LLM / MCP / A2A or on the device itself; when it's Running its mesh URL is shown and you can optionally expose it to the internet.
• HostAnywhere-hosted — managed endpoints at api.hostanywhere.ai, toggled on from the same pages. Cloud-only to run, but each can still reach a model, tool server, or agent you host on your own device — the request is delivered over your agent's reverse tunnel, so private upstreams never touch the public internet.

Point any client at the matching endpoint with an ha-gw-… key — for the LLM gateway it's a drop-in OpenAI base URL:

curl https://api.hostanywhere.ai/v1/chat/completions \
  -H "Authorization: Bearer ha-gw-..." \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"Hi"}],"user":"my-app"}'

LLM providers

An LLM provider is a cloud AI service the gateway can route to. Under AI Gateway → LLM Providers, connect the ones you want and paste each API key. Keys are encrypted at rest and only ever used on the gateway — your apps authenticate with a HostAnywhere gateway key instead, so provider secrets never live in your code.

Supported today: OpenAI, Anthropic, Google Gemini, Groq, Mistral, DeepSeek, xAI (Grok), Together, Perplexity, Fireworks, OpenRouter, Cerebras, Cohere, NVIDIA NIM, DeepInfra, Azure OpenAI, and AWS Bedrock.

Routes

A route is a virtual model your apps call by name. Instead of hard-coding gpt-4o or a specific local model, your app calls a route like smart (or the built-in auto), and the gateway resolves it to an ordered chain of real targets — trying them in order and failing over automatically if one errors or times out.

Each target is either a local model (local/<model>) or a provider model (<provider>/<model>), and carries its own reliability settings:

A per-target circuit breaker backs these up: after 3 consecutive failures, a target is skipped for a 30-second cooldown — so a dead provider doesn't add its timeout to every request; traffic goes straight to the next target until it recovers.

{
  "name": "smart",
  "strategy": "fallback",
  "targets": [
    { "model": "local/deepseek-r1:8b", "timeout_ms": 8000 },
    { "model": "openai/gpt-4o-mini", "retries": { "max": 2, "backoff": "exponential" } }
  ]
}

MCP gateway — tool servers

The Model Context Protocol is how AI agents call tools and read data. The MCP gateway fronts one or many of your MCP servers behind a single URL: it aggregates their tools (each server's tools appear as name__tool), checks every tools/call against your guardrails — on both the arguments going in and the results coming back — and injects each server's own credential on the gateway, so it never lives in your client. It reuses the same keys, guardrails, and usage as the rest of the AI Gateway.

Connect a server under AI Gateway → MCP servers. Each has a namespace (its name — it prefixes every tool as name__tool), a transport, and an optional injected credential:

Any MCP client authenticates with a gateway key and sees the aggregated tool list — no per-server URLs or secrets in the client. Every tools/call is inspected both ways by your guardrails (with an optional per-server override); a blocked call is refused with a JSON-RPC error and recorded in guardrail activity. Try any server end-to-end in the MCP Playground.

curl https://api.hostanywhere.ai/mcp \
  -H "Authorization: Bearer ha-gw-..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Under the hood the gateway speaks MCP's Streamable-HTTP transport: initialize opens a session whose id comes back in the Mcp-Session-Id response header — include that header on subsequent requests, and end the session with a DELETE carrying the same header.

A2A gateway — agents

The Agent2Agent protocol lets one agent send tasks and messages to another. The A2A gateway sits in front of the agents you talk to: you register each one and it becomes reachable at /a2a/<name>. Every message is screened by your guardrails, the target agent's credential is injected on the gateway, and every exchange is metered — the same keys, guardrails, and usage as the rest of the AI Gateway.

Register an agent under AI Gateway → A2A agents:

Send to an agent with an ha-gw-… key; scope the key to specific agents so a caller reaches only what it should, and try registered agents in the A2A Playground.

curl https://api.hostanywhere.ai/a2a/planner \
  -H "Authorization: Bearer ha-gw-..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"message/send","params":{"message":{"role":"user","parts":[{"kind":"text","text":"Plan my week"}]}}}'

A2A clients can also discover a registered agent through the gateway — its agent card is served at GET /a2a/<name>/.well-known/agent-card.json, so capability discovery works without ever touching the agent's origin.

API keys

Your apps authenticate to every gateway with a HostAnywhere gateway key (ha-gw-…) — never your provider, tool, or agent secrets. Manage them under AI Gateway → API keys. One key works across the LLM, MCP, and A2A gateways.

Caching

Turn on caching to serve identical repeated requests from memory instead of re-calling the model — dropping latency to near-zero and saving spend on duplicate calls.

Guardrails

Guardrails inspect and clean traffic on the gateway, before it reaches a model, tool, or agent — and again on the way back for tools and agents. They run in memory; HostAnywhere reads content only to screen it, and it's never logged or stored. Configure the account-wide policy under AI Gateway → Guardrails; it's built from four independent layers:

Customize with a preset or by hand. Pick Off, Standard, or Strict for a one-click policy, or Custom to tune each moderation category's input/output action, the injection action, PII, and the blocklist individually. (Content moderation, PII redaction, and blocked patterns are included on every plan. Prompt-injection detection and AI-powered PII detection require a paid plan — Developer and up.) If the guard model is briefly unavailable a request may fail open and is flagged guard degraded in the response and usage.

Attach it where it matters. The account policy applies everywhere by default; you can override it per destination:

Spend limits

Spend limits cap how much the gateway can spend over a rolling window — a set of rules under AI Gateway → Spend limits. Each rule sets a dollar budget for a time window, optionally scoped to certain providers or models. When a rule's budget is reached, further matching requests are rejected until the window resets.

Observability

The Usage & cost tab gives metrics across every gateway — LLM, MCP, and A2A. Overview (cost, tokens, requests, p95 latency, unique users, with trends), Users, Errors, and Cache hit-rate and savings. It's metadata only: counts, cost, latency, and the opaque user id your apps send — never prompt or response content. Set the OpenAI user field on your requests to attribute usage per end-user in the Users tab.

Guardrail activity. A second tab under Observability shows what your guardrails caught — blocks and redactions across LLM prompts, MCP tool calls, and A2A messages — so you can see what was stopped and tune your policy.

Playgrounds

Under Tools, three built-in consoles let you exercise any gateway without writing code — pick where it runs (cloud or a specific device) and watch it work:

• Chat Playground — send a chat request through a chosen gateway and model or route. Each reply shows the model used, tokens, cost, latency, cache hits, and whether guardrails passed.
• MCP Playground — connect to a gateway, list the aggregated tools, and call one — seeing the guardrailed arguments and results.
• A2A Playground — send a message to a registered agent through the gateway and inspect the response.

Access Control

Access Control lets you decide who on your mesh can reach what. Every connection between two devices is checked against an ordered list of rules; the first rule that matches the connection decides whether to allow or deny it. By default a new network is fully open — every device can reach every other device on every port. Add rules to lock things down when you need finer control.

Typical use cases:

• Lock a home NAS so only your laptop and phone can reach it, even though other family members are on the same mesh.
• Allow contractors to reach a single dev server on port 22 and nothing else.
• Block a guest device from reaching anything except the internet gateway.
• Require devices to be currently compliant in Intune or have a CrowdStrike ZTA score above 75 before they can reach production systems.

How rules are evaluated

Rules have a priority (lower number = higher priority). For every connection, HostAnywhere walks the list in priority order and stops at the first rule whose source, destination, port, and protocol all match — that rule's action (allow / deny) decides the outcome. If no rule matches, the network's default policy applies.

• Default policy: allow (the default for new networks). The mesh is open; rules carve out specific denies or posture-gated allows.
• Default policy: deny. The mesh is locked down; everything you want to permit needs an explicit allow rule. This is the right stance for production / multi-user networks.

Rules have a direction — in (someone is dialing this device) or out (this device is dialing someone). A symmetric "X can talk to Y" usually needs both directions, or you can write one direction and let the default policy cover the return path.

Where it's enforced

Rules are resolved server-side and pushed to every device. Each platform enforces them with its native firewall, so there's no proxy / sidecar to install:

Writing a rule

Open the dashboard, click Access Control (under Users), then + New rule. Fill in:

• Action — allow or deny.
• Direction — in (others dialing this device) or out (this device dialing out).
• Source — a single device, a tag (the most common choice), the device's owner (any device they own), an OS family (Windows, macOS, Linux, iOS, Android), an address group, a CIDR, or All devices.
• Destination — same options as Source.
• Ports — a single port (22), a list (80,443), a range (5000-5010), a port group (HTTPS, SSH, …), or All ports.
• Protocol — TCP, UDP, both, or Any (Any covers ICMP — useful for a "no ping" rule).
• Priority — defaults to the next available number; drag rows in the list to reorder.
• Posture conditions (optional) — gate the rule on the connecting device's EDR / XDR / MDM state. See EDR, XDR & MDM Integrations.

Tags

Tags are labels you attach to devices to group them for access-control rules. They're the most common way to write rules: instead of naming individual devices, you tag the devices that share a purpose and then write rules against the tag. A device can wear any number of tags — your work laptop might be tagged engineering, production-access, and office at once.

Typical tags:

• home, office — physical location
• engineering, finance, support — team or department
• production, staging — environment
• byod, guest, contractor — device class or access level

Create and manage tags in the dashboard under Access Control → Tags. Each tag can have an optional description (so future-you remembers what it's for) and a color (so it's easy to spot in the rules list). Adding or removing a device from a tag instantly updates every rule that references the tag — there's no need to edit each rule when the membership changes.

Address groups and port groups

Address groups let you reuse a set of devices or CIDRs across many rules — "Engineering laptops", "Office subnet", "Production servers". Use them when you need to mix in raw IP ranges that aren't HostAnywhere devices (e.g. a corporate subnet or a cloud VPC). For pure device groupings, tags are simpler. Built-in groups always exist:

• All devices — every device on the network.
• All users — every device owned by any human member (excludes service / unattended hosts).
• My devices — the requesting device's own owner's devices. Useful for "let me reach my own machines from anywhere" rules.

Port groups are reusable port lists with a protocol — e.g. HTTPS = TCP 80,443 or SQL = TCP 1433,3306,5432. Both groups are managed under Access Control → Groups in the dashboard and selected by name in the rule editor.

Rule examples

• "Production servers can be reached by engineering only."
  Default policy deny. Add allow in, source = tag engineering, destination = tag production, all ports. Adding or removing engineers from the team is just a matter of toggling the tag on their device — no rule edits.
• "Only Intune-compliant devices can reach the database."
  Default policy deny. Add allow in on devices tagged database: source = All devices, ports = your database port (e.g. 5432 for PostgreSQL), protocol = TCP, posture condition = Intune: must be compliant.
• "Engineering needs SSH everywhere, but only if Falcon ZTA ≥ 75."
  allow out, source = tag engineering, destination = All devices, ports = 22, protocol = TCP, posture condition = Falcon: score ≥ 75.
• "Block guest phones from anything except the internet gateway."
  Default policy deny. One allow out rule with source = tag guest, destination = Internet gateway (built-in role group), all ports.

Posture conditions

A rule can optionally require the connecting device to be in a healthy state, as judged by an EDR, XDR, or MDM product you've connected to HostAnywhere. Set this up under EDR, XDR & MDM Integrations, then check the Device posture box in the rule editor and pick a provider with a minimum score (CrowdStrike) or required compliance (Intune).

EDR, XDR & MDM Integrations

Connect an external endpoint-protection (EDR / XDR) or device-management (MDM) product to HostAnywhere, and you can require a device to be in a healthy state — Intune-compliant, CrowdStrike ZTA score above a threshold — before it can satisfy an allow rule. HostAnywhere caches each device's latest state every 5 minutes.

Most teams connect one EDR / XDR provider and one MDM provider; together they cover laptops, desktops, and mobile devices with one posture story.

How matching works

HostAnywhere matches its device records to records from your endpoint-security tenant by case-insensitive hostname. This works well when devices keep their default OS-reported hostname; if you rename a device after installing the agent, its posture won't match until the new name also reaches your EDR, XDR, or MDM tenant.

If a device hasn't been scanned recently — for example, it's been offline, or it just enrolled and isn't visible to your provider yet — posture-gated allow rules don't apply to it. There's no way to accidentally bypass a posture check by going offline.

CrowdStrike Falcon

Falcon's Zero Trust Assessment score (ZTA) rates each device on a 0-100 scale based on sensor health, OS patch status, login behavior, and account hygiene. Higher is better.

Setup on the Falcon side

1. Sign in to the Falcon console as a Falcon Administrator and go to Support & resources → API clients and keys → Create API client.
2. Give the client a name (HostAnywhere posture sync) and grant scopes:
   • Hosts — Read
   • Zero Trust Assessment — Read (optional but recommended)
3. Save and copy the Client ID, Secret, and Base URL (e.g. https://api.crowdstrike.com or one of the regional variants).

Setup on the HostAnywhere side

1. In the dashboard, open Integrations and click + Add provider.
2. Pick CrowdStrike Falcon, paste the Base URL, Client ID, and Secret, and hit Test connection. A green check means the credentials work and at least one host is visible.
3. Click Sync now to populate the score table immediately, or wait for the 5-minute background worker.

Score fallback

If the API client doesn't have Zero Trust Assessment Read permission, HostAnywhere falls back to a 0-100 score derived from Falcon's other health signals — whether the agent is enrolled, how recently it checked in, and whether Falcon reports the sensor as normal. Your rules don't need to know which path produced the score; they compare against a minimum score either way.

Microsoft Intune

Intune is a binary model — each device is either compliant or non-compliant against the compliance policies you've configured in Endpoint Manager. Devices in a remediation grace period are counted as compliant, the same way Microsoft's Conditional Access treats them.

Setup in Microsoft Entra ID

1. Sign in to entra.microsoft.com as a Global Administrator.
2. Applications → App registrations → + New registration. Name it HostAnywhere posture sync, choose Single tenant, leave the Redirect URI blank. Click Register.
3. On the Overview page, copy the Application (client) ID and the Directory (tenant) ID.
4. Certificates & secrets → + New client secret. Set the longest expiry your policy allows (Microsoft caps at 24 months). After clicking Add, immediately copy the Value column — it's only shown once.
5. API permissions → + Add a permission → Microsoft Graph → Application permissions. Add DeviceManagementManagedDevices.Read.All. Then click ✓ Grant admin consent for [your directory].

Setup on the HostAnywhere side

1. In the dashboard, open Integrations and click + Add provider → Microsoft Intune.
2. For Base URL / Tenant, paste the Directory (tenant) ID. For Client ID and Client Secret, paste the values from steps 3 and 4 above.
3. Hit Test connection, then Sync now.

Operations

• Sync cadence. Each provider syncs every 5 minutes in the background. Force an immediate sync from the provider row in Integrations.
• Last sync state. The Integrations page shows when each provider last synced and the most recent error (if any) — useful when an expired secret starts returning auth errors.
• Secret rotation. Azure caps client secrets at 24 months and CrowdStrike at 12. Rotate before the expiry and update the provider row; HostAnywhere will pick up the new secret on the next sync attempt without restarting.
• Encryption at rest. Client secrets are encrypted at rest with AES-256-GCM. Only the HostAnywhere control plane can decrypt them.

Next: wire these into rules under Access Control.

Plan Limits

Limits apply to the whole network. The owner's plan determines the limits — members don't need their own paid plan.

See the Pricing page for annual pricing and the Enterprise contact form.

Inviting Members

Open the Users section in the dashboard and click Invite User. You can invite someone two ways:

• Copy link — share a one-time invite link via any channel (Slack, email, etc.).
• Send email — enter their email address and HostAnywhere sends the invite for you.

Invite links are single-use and expire after 7 days. When the recipient opens the link and signs in, they are automatically added to your network.

Roles

Members can see all devices on the network in the dashboard but can only edit or delete their own. Other members' devices are shown as read-only.

Removing Members

In the Users section, click the remove button next to any member. Only the owner can do this.

When a member is removed, their devices immediately disappear from the shared device list and they lose access to the private network. Their own account and any public services they created are not affected.

FAQ

Do I need to open any ports on my router?

No. The agent connects outbound — no router configuration, port forwarding, or firewall changes needed.

Can I expose multiple services from one machine?

Yes. A single agent handles every service you add to that device — you don't need to run multiple agents. Create each service in the dashboard (one subdomain → one local port); the agent picks them up on its next config poll (within ~10 s) and runs all of them concurrently.

Can I be in multiple networks?

Not currently. Each account belongs to one network at a time.

My invited user joined but I don't see their devices.

They need to install the agent and connect at least one device. Once they do, it appears in all team members' dashboards automatically.

Does the agent need admin / root access?

Admin access is needed when first setting up the private network interface — the Windows installer handles this automatically. For the macOS .pkg, the installer takes care of it. On Linux, the agent needs sudo or CAP_NET_ADMIN to create the network interface. Regular tunnel traffic does not need elevated privileges.

Is traffic secure?

Yes. Public services use HTTPS end-to-end. Private mesh traffic is encrypted between devices — the relay never sees the content.

What happens when I hit a plan limit?

The action that would exceed the limit (adding a device, inviting a user, creating a public service) is blocked with a clear message. Nothing existing is removed. Upgrade your plan to continue.

How is my backup encrypted?

Each file is encrypted on your phone before it's uploaded, using AES-256-GCM with convergent encryption. The data-encryption key is derived from the file's own SHA-256 hash, then wrapped with a master key that lives only on your phones (escrowed via iCloud Keychain on iOS, Android Keystore on Android). HostAnywhere has no copy of the master key and can't decrypt anything. See Storage Server & Backups for more.

Can I run multiple storage servers?

Yes. Run the storage server on as many devices as you like — phones automatically pick the one with the lowest latency on each sync. The storage servers also replicate to each other automatically in the background: a blob uploaded to one server propagates to the others within a few minutes via the mesh. You get geographic + drive redundancy for free — a primary at home, a second copy on a NAS, a third on a friend's machine — all stay in sync without manual intervention.

Can HostAnywhere see my internet traffic when I use Internet Gateway?

No. All traffic flows agent-to-agent over WireGuard, encrypted end-to-end. HostAnywhere's servers see only mesh metadata — which peers are online, peer counts, and so on — never the contents of the tunnels themselves.

What if my storage server is offline when a phone tries to back up?

The phone retries periodically. Nothing is ever uploaded to HostAnywhere as a fallback — your data only goes to storage servers you own. When the server comes back online, the queued items sync automatically. If you have multiple storage servers, the phone tries the others first before queuing.