Install the AI Grid host and plan remote access for an already configured grid
AI Grid, also called autonomous-grid, provides a shared OpenAI-compatible entry point for model-serving computers. This guide covers the available installation paths, host startup and inspection, and the Localtonet configuration needed to reach an existing, protected grid endpoint. It is not a backend-registration tutorial: a working model integration and a repeatable local inference test are prerequisites for the remote-access portion. We also explain when to stop rather than publish an endpoint whose authentication, binding, or operational controls have not been verified.
📋 What's in this guide
What this guide covers, and what it does not
AI Grid is an orchestration layer above inference software. The project's current product page describes Ollama, vLLM, LM Studio, and llama.cpp as model-serving options and presents the grid as a shared OpenAI-compatible endpoint. The runtime still loads the model and performs inference. Installing the grid host alone does not establish that a model is registered, available, or usable by a client.
We focus here on installing and inspecting the host, understanding the network path, and configuring optional remote access for an already functioning deployment. We do not provide a join command, pairing sequence, model-server configuration file, or end-to-end backend installation procedure. The available project material does not establish a complete current sequence for those tasks. If you do not already have a working grid integration, complete that separate deployment before proceeding to the tunnel.
With Localtonet, our client establishes an outbound connection to a relay server. An HTTP tunnel then provides a public HTTPS address for the selected local service without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. That solves reachability, not model configuration or application authorization.
Keep the addresses separate
A deployment can have several different addresses: the model runtime's serving address, the grid's HTTP origin, the grid's API base URL, and the public tunnel URL. A protected deployment may also have an authentication gateway in front of the grid. Each address has a different purpose.
The previously documented AI Grid examples use http://192.168.1.25:8090 for the host and http://192.168.1.25:8090/v1 for an API base. These are examples, not a universal port or a network address to copy. Record the endpoint reported by your installation and verify it with your working client. A path such as /v1 belongs in the application's API configuration, not in Localtonet's local IP field.
Prerequisites and deployment decisions
Installation and publication have different prerequisites. You can install the host to evaluate the software without publishing anything. To continue through the remote-access portion, you need a known-good grid request, a reachable target, and an authorization control that has passed both positive and negative tests.
| Requirement | What to establish | Why it matters |
|---|---|---|
| Host platform | Confirm the selected installer supports the operating system and architecture. | The current product page promotes macOS and Linux; Windows evidence is release-specific. |
| Working backend integration | At least one model already responds through the grid. | A tunnel cannot register a backend or repair inference failures. |
| Repeatable local test | Retain a working client configuration or request with its real model identifier and API path. | The same test provides a meaningful remote comparison. |
| Verified authorization | Unauthorized requests are rejected at the intended public entry point. | Knowing a URL must not be sufficient to run inference. |
| Client-to-target reachability | The device running Localtonet can reach the protected service. | The tunnel forwards from that device's network context. |
| Operational ownership | The operator knows how to inspect, stop, and recover the installed grid release. | Closing a terminal is not proof that background services have stopped. |
Choose a stable host
Select a computer that remains online during the intended access window. The grid host and model server may share a computer or run on separate machines. Size the model runtime for the chosen model, memory requirements, accelerator support, and workload rather than assuming that installing an orchestrator creates additional capacity.
If another device will address the grid over the LAN, consider a stable local addressing strategy appropriate to your network. An old DHCP address can become unreachable or eventually belong to a different machine. Recheck the destination after reboots and network changes instead of assuming that a saved tunnel target remains correct.
Platform support is not one blanket claim
The current AI Grid product page promotes a native macOS and Linux app, with Apple Silicon and NVIDIA GPU download labels respectively. These labels do not establish every supported architecture, operating-system version, or backend combination.
Windows support is evidenced separately by the repository's PowerShell installer and the v0.3.61 release notes, including Windows 11 Smart App Control handling. That is not sufficient evidence for an unqualified Windows 10 support claim or for identical desktop-app availability across all platforms. Confirm the compatibility of the chosen release before installation.
Install the host, start it, and inspect its endpoint
The commands below retain the project's installation and host-management examples from the original guide. The supplied current repository extract lists the installers but does not include their full contents or a complete current CLI reference. Consequently, these examples are not a claim that every command and prerequisite has been revalidated against every newer release. Review the AI Grid repository before running downloaded code, particularly on an existing deployment.
macOS or Linux shell installation
The previously documented shell installation command is:
curl -fsSL https://grid.autonomous.ai/install.sh | bashThis downloads a script and immediately executes it. If your organization's policy requires review, retrieve and inspect the script before execution instead. Do not run an installer with extra privileges merely to work around an unexplained failure. Read its output for prerequisites, installation location, and shell-path changes.
The available evidence does not establish exact minimum OS versions, a complete package dependency list, or current native-app installation screens. This section covers the shell entry point, not a complete native desktop installation walkthrough.
Windows repository installation
The v0.3.61 release notes explicitly provide this PowerShell installer invocation:
powershell -ExecutionPolicy ByPass -c "irm https://raw.githubusercontent.com/autonomous-ai/autonomous-grid/main/install.ps1 | iex"This command also downloads and executes code, and uses an execution-policy bypass for the invoked process. Follow your organization's software-execution policy. The URL tracks the repository's main branch, so its contents can change independently of the release note that documented the command.
The release identifies a Windows update problem in 0.3.60: the update attempted to replace files from inside the installation being replaced. For that affected version, it instructs users to rerun the installer rather than use grid update. It also describes a grid.cmd fallback through signed Python when Smart App Control blocks the unsigned grid.exe launcher. Do not generalize that workaround into disabling Windows security controls.
Check the executable and start the host
After installation, open a fresh terminal if necessary and check the command:
grid --versionA version response establishes that the executable is available in this shell. Record the version for troubleshooting. It does not prove that the host is running or that any backend has joined.
The host startup and inspection commands retained from the documented workflow are:
grid start
grid infoRead any startup errors before continuing. Record the actual host endpoint and API base information reported by the installation. Do not fabricate expected console output or assume a specific node-list format. If these commands are unavailable in the selected release, stop and reconcile the release's CLI documentation before proceeding.
The supplied evidence does not establish a current backend-registration sequence, inference request schema, binding default, or shutdown command. We therefore do not invent join flags, API routes, model names, or a stop command. An existing tested integration and a release-specific operational runbook are required for the remaining sections.
Verify an existing deployment before changing its access path
The remote-access procedure assumes you already possess a successful inference test. It does not substitute a generic OpenAI request for a verified AI Grid API example. OpenAI compatibility alone does not establish every route, model identifier, authentication scheme, or streaming behavior supported by a particular release.
Establish a repeatable baseline
- Use the existing client configuration that already completes inference through the grid, not directly through the backend.
- Record its grid API base, exact model identifier, request type, and credential mechanism without copying secrets into notes or screenshots.
- Submit a small, non-sensitive prompt, such as a request to return a short greeting.
- Confirm that the client receives a completed model response rather than only an HTML page, redirect, connection acknowledgment, or model listing.
- Keep this configuration unchanged as the baseline for testing the protected entry point and, later, the public URL.
This is a regression-test procedure for an existing integration, not a new client setup recipe. If you cannot perform it, stop here. A complete integration tutorial would need a verified backend startup command, registration sequence, client request, and expected output that the available evidence does not supply.
Choose the target from the Localtonet device's perspective
Loopback addresses refer to the machine making the connection. If Localtonet and the protected HTTP service run on the same machine, a loopback target can work only if that service actually listens there. Do not replace a reported LAN address with 127.0.0.1 without testing it. The supplied AI Grid evidence does not establish its default bind interface.
If Localtonet runs on another LAN device, its loopback address cannot reach the grid host. Use the grid host's reachable LAN address, or the address of the authentication gateway protecting it. The service must listen on an appropriate interface, and existing host and network policy must permit the connection. The outbound tunnel does not fix a blocked client-to-target LAN path.
If inspection shows a wildcard listener such as 0.0.0.0, that is a listening instruction, not a destination address to give a remote client. Select a real reachable address. Likewise, containers and virtual machines may have separate network namespaces; test from the environment that actually runs our client.
Test the protected entry point separately
Where a gateway provides authentication, repeat the baseline through that gateway before configuring Localtonet. Verify both an authorized request and a request without valid authorization. A successful raw-grid request does not prove that the gateway preserves the API path, request body, or streaming behavior. Conversely, a rejected unauthorized request does not prove that authorized inference works.
Do not publish until authorization is verified
The available project evidence does not identify a verified built-in authentication configuration for the grid's inference endpoint. This is not proof that no such feature exists, but it means this guide cannot instruct you to enable one. Do not expose the endpoint publicly until a real application-layer authorization control is in place and tested. URL secrecy and HTTPS alone are insufficient.
A practical design is to put an operator-managed authentication gateway in front of the grid, expose only that gateway through the tunnel, and keep the raw grid endpoint off the public path. Alternatively, use documented native authentication if the installed release supplies it and you have verified its behavior. This article does not supply a gateway product configuration, so that protection is a prerequisite rather than an implied result of the tunnel steps.
Publication acceptance criteria
- A request with no credential cannot run inference.
- A request with an invalid or revoked credential is rejected.
- An approved identity can complete the same small inference test used locally.
- Administrative routes and unnecessary services are not reachable through the published entry point.
- The tunnel targets the protected listener rather than an unprotected upstream address.
- The operator can revoke access and stop the tunnel promptly.
Do not treat a placeholder API key accepted by a client library as proof that the server validates credentials. Some client interfaces require a nonempty key field even when a destination does not enforce it. The meaningful test is rejection of unauthorized requests at the server-side boundary.
Localtonet device tokens identify client devices. They are not AI Grid API keys and must not be reused as inference credentials. Keep them out of repositories, screenshots, shared client configurations, and support messages.
Protect data and resources, not just connectivity
Prompts can contain source code, customer information, conversation history, or agent context. Review what a remote client sends before connecting it. Use a non-sensitive test prompt, limit permissions, and avoid logging complete prompts or authorization headers unnecessarily.
An authenticated API can still be overloaded. Set workload limits and request controls in the application or gateway where supported, based on measured model capacity. Do not assume that a tunnel supplies inference quotas or makes an administrative interface safe to expose.
Configure Localtonet for a protected, working HTTP endpoint
Continue only after the publication acceptance criteria pass. An HTTP tunnel matches this HTTP API workflow. File Server publishes folders, proxy configurations make a device an exit node, and VPN Manager is our separate private mesh VPN feature. Standard HTTP tunneling is not a VPN.
The configuration below includes Process Type before the device, relay, and local-target selections. Use the canonical Localtonet HTTP tunnel documentation alongside the current dashboard for the exact interface presented to your account. The supplied material does not include a live copy of that page, so this is not a claim of a newly verified screen-by-screen interface or current documentation step count.
Install and run our client
Run the Localtonet client on the device that can reach the protected HTTP service. Keep that device online throughout the remote-access window.
Open HTTP tunnel configuration and select Process Type
Choose Random Sub Domain, Custom Sub Domain, or Custom Domain as available for your account. These process types serve the same target content at a public HTTPS address. Check current domain instructions before making DNS changes.
Select the device token and relay server
Select the AuthToken for the intended connected client, then choose an available server from the dashboard. Do not copy another device's token or hardcode an example relay code.
Enter the protected local IP address and port
Use the listener verified from the Localtonet device. If authorization is enforced by a gateway, target that gateway, not the raw grid port. Keep API paths out of the IP and port fields.
Start the tunnel
Press Start after confirming the target and security checks. A saved configuration is not a running tunnel. The public endpoint is available only while the selected client is connected and the tunnel is running.
Verify the assigned public endpoint
From an approved remote client, duplicate the working protected-client configuration and replace only its local origin with the assigned public HTTPS origin. Preserve the API path, model identifier, authorization mechanism, and request settings. Check how your client handles base paths so that it does not accidentally duplicate or remove /v1.
Repeat the unauthorized and authorized tests. The first must remain rejected; the second must complete inference. A public page loading successfully is not sufficient. If authentication is bypassed or an unexpected administrative route is reachable, stop the tunnel immediately and correct the boundary before trying again.
Available regions, options, and plan entitlements can vary. Use current dashboard values rather than assuming every configuration is included in every subscription. Custom-domain DNS details are deliberately not specified here because those requirements need confirmation against current documentation.
Routine operation and layered troubleshooting
Startup and shutdown
For routine startup, bring up the model runtime using its established runbook, start the grid, inspect its endpoint, and repeat local inference. Next verify the protected entry point and its authorization failures. Only then connect the Localtonet client and start the tunnel. This ordering prevents a remote-access problem from concealing a local service failure.
For shutdown, stop the public tunnel first, then stop accepting application work and allow outstanding requests to finish where appropriate. Stop the gateway, grid, and model runtime using their documented release-specific controls. The available evidence does not establish an AI Grid shutdown command, so none is guessed here. Do not assume that closing a terminal terminates a background host.
Stopping Localtonet does not stop AI Grid. Stopping AI Grid does not delete the tunnel configuration. Keep the tunnel stopped while repairing or replacing its target, and delete it when the saved configuration is no longer needed.
| Symptom | First check | Next action |
|---|---|---|
grid is not recognized |
Installer output and the current shell's executable path | Open a fresh terminal; resolve reported installation or permission errors. |
| The grid starts but inference fails | The same model directly through its runtime | If the runtime works, inspect the existing integration and exact model identifier. |
| Host-local access works, LAN access fails | Destination address, listener interface, and LAN policy | Test from the actual Localtonet device; do not substitute its loopback address. |
| The protected entry point fails | Gateway authorization and upstream configuration | Compare the working grid request with gateway path and credential handling. |
| The public endpoint is offline | Connected device and running tunnel state | Start the tunnel and verify that the selected client can still reach its target. |
| Public HTTP responds but inference fails | API base, model identifier, credentials, and response body | Repeat the identical request locally through the protected entry point. |
| Unauthorized inference succeeds | Whether the tunnel bypasses authorization | Stop the tunnel immediately and correct the protected boundary. |
Windows launcher and update failures
For the specific Windows 0.3.60 update failure, the 0.3.61 release directs users to rerun the installer. The same release explains its launcher fallback for Windows 11 Smart App Control. A blocked model-server executable is a separate issue from a blocked grid launcher; read the named program in the error rather than assuming the CLI workaround fixes every executable.
Slow requests and timeouts
Compare direct runtime inference, local grid inference, protected-entry-point inference, and public inference separately. Use the same model and prompt, and distinguish cold model loading from subsequent requests. This helps identify whether the delay is model execution, routing, gateway behavior, or the network path.
If a short non-streaming test works but your real workload fails, investigate the client's request type and every intermediary's handling of that workload. Do not infer universal timeout values, streaming guarantees, or performance improvements from basic HTTP reachability. Hardware, model size, concurrency, and network conditions all affect results.
After upgrades or address changes
Record the installed version and current endpoint again. Retest inference and authorization before restoring public access. If the protected listener moves, update the tunnel target deliberately. Do not redirect the tunnel to a raw upstream port simply to make a failed test pass.
Frequently asked questions
Does this guide connect Ollama or another backend to AI Grid?
No. It covers host installation examples, startup, inspection, and conditional tunneling of an existing grid. A verified backend integration and working local inference test are prerequisites because a complete current registration sequence is not established by the available evidence.
Is Windows 10 support confirmed?
Not by the supplied primary evidence. The repository contains a Windows installer, and v0.3.61 documents Windows update fixes and Windows 11 Smart App Control behavior. The current product page promotes native macOS and Linux downloads. Confirm your exact platform and release before installing.
Is port 8090 always the correct target?
No. It appears in an example, not a universal configuration. Inspect your deployment and test its actual listener. If an authentication gateway protects the grid, the tunnel should target that gateway's verified address and port.
Can I publish an endpoint without authentication if I keep the URL private?
No. URL secrecy is not an authorization control. This guide does not establish a built-in AI Grid authentication setup. Keep the tunnel stopped until a documented native control or an operator-managed gateway reliably rejects unauthorized requests.
Can our Localtonet client run on another LAN computer?
Yes, if that computer can reach the protected HTTP listener. Use a reachable LAN destination, not the Localtonet computer's loopback address. The grid's default binding behavior is not established here, so verify the actual listener and network path.
Does creating a tunnel make the service public immediately?
Creating a configuration does not mean it is running. Start the tunnel explicitly. Its public endpoint is available only while the selected device is connected and the tunnel is running. Stop it when access is no longer required.
Is this a VPN, and does it require router port forwarding?
This is an HTTP tunnel, not a VPN. Our client connects outbound to a relay, so inbound router port forwarding is not required. Localtonet VPN Manager is the separate private mesh VPN feature.
Add remote access only after local inference and authorization pass
Once your existing grid works through a protected HTTP entry point, use Localtonet to make that same service reachable by approved remote clients. Verify both accepted and rejected requests, keep the device token private, and stop the tunnel outside the intended access window.
Get Started Free →
