Skip to content

LAN Deployment

Goal

Run VILab on one host machine and allow other machines on the same network to call its /v1/* endpoints.

  • One machine runs the VILab desktop host
  • That machine manages providers and external API keys
  • Other internal apps use project-scoped external API keys

Bind the service to the network

The embedded service binds to the host and port configured in Server URL.

Recommended host-side value:

text
http://0.0.0.0:8765

Client-side callers should use the actual LAN IP or hostname of the host machine, for example:

text
http://192.168.1.24:8765

Firewall and reachability

  • Allow inbound TCP traffic on the service port
  • Confirm that clients on the same LAN can reach the host IP
  • Keep the service on trusted internal networks only

Health check from another machine

powershell
curl http://192.168.1.24:8765/health

Authentication model

  • /health does not require an API key
  • /v1/* requires Authorization: Bearer <external_api_key>
  • /admin/* requires Authorization: Bearer <adminKey>

The current implementation still accepts adminKey on public endpoints, but that is not the recommended operational model. Use external API keys for integrations.

Key issuance rule

Issue one external API key per:

  • Project
  • Script
  • Device
  • Integration

Recommended names:

  • web-dashboard-prod
  • ios-prototype-lab
  • robot-gateway-01

Operational note

This first phase does not include:

  • User accounts
  • Team login
  • Key scopes
  • Key expiry
  • Rate limits

Those are follow-up hardening features, not requirements for self-hosted LAN use.

Public release docs and self-hosted deployment guidance.