How to Expose Local LLMs to the Internet Securely

What you are exposing and how the request path works

Ollama can run a model and provide a local HTTP API. On a typical installation, that API is available on the inference machine at http://127.0.0.1:11434. The loopback address is intentionally local: another computer on the internet cannot connect to it directly.

With Localtonet, the client application runs on the inference machine, or on another device that can reach the inference service. The client establishes an outbound connection to a selected Localtonet relay. An HTTP tunnel then maps a public HTTPS address to the configured local IP address and port. A remote request reaches the public address, travels through the active tunnel, and is delivered to the local target.

What local deployment does and does not guarantee

Local inference can reduce dependence on a hosted model provider and lets you choose where model execution occurs. It does not automatically provide complete privacy, zero cost, lower latency, unlimited capacity, or regulatory compliance. Hardware, electricity, administration, storage, and network connectivity still have costs. Performance depends on the model, quantization, context size, concurrency, hardware, and workload.

Data also does not remain entirely inside the inference machine once you expose the API. A remote prompt must travel from the caller to the public endpoint and back through the tunnel. The caller, any application placed in front of Ollama, logs, monitoring systems, and other components in the request path may process or retain data. Local deployment can support a privacy or data-residency program, but it does not establish compliance by itself.

Useful scenarios

A controlled public endpoint can help with mobile application testing, short-lived demonstrations, automation that must call an externally reachable URL, or access from a separate development device. A team may also use a centrally hosted model, but shared use requires stronger authentication, authorization, usage controls, logging decisions, and capacity planning than a personal test.

An LLM inference API is not the same thing as an AI agent endpoint or an MCP server. Ollama accepts model inference requests. An agent usually adds tools, workflow logic, memory, or application-specific permissions. Model Context Protocol defines interactions between MCP clients and MCP servers that expose tools or resources. If your actual objective is to publish a locally running McpNet Gateway, use the documented Localtonet MCP Gateway workflow instead of treating an Ollama inference API as an MCP server.

Prerequisites and decisions to make first

Complete the following checks before creating a public tunnel. Separating local runtime work from tunneling work makes failures much easier to diagnose.

Choose a model based on current evidence

Model catalogs and tags change frequently, so this guide does not prescribe a volatile model ranking or an unverified memory minimum. Visit the current Ollama model library, review the model's license and publisher information, and choose a size suitable for your machine. Record the exact tag shown by Ollama because the API payload must use that installed name.

A smaller or more heavily quantized model often needs fewer resources, but model parameter count alone is not enough to predict memory use or performance. Context length, quantization, runtime overhead, concurrent requests, prompt size, and hardware acceleration all affect the result. Test the actual model and workload rather than relying on a generic RAM table.

Decide whether the endpoint is temporary or shared

For a brief test controlled by one operator, you can start the tunnel only for the test window, avoid sending sensitive content, verify one request, and stop it immediately. This limits exposure time but does not add authorization.

For team access, automation, or any recurring use, do not expose an unauthenticated Ollama API directly. Put an application or reverse proxy that validates credentials in front of Ollama, bind Ollama to loopback, and point Localtonet to the authenticated front end. The remainder of this guide identifies the two possible targets clearly.

Install Ollama, acquire a model, and verify the local API

The commands in this section use Ollama's native API because it is the direct interface for the runtime. Ollama also documents compatibility endpoints, but compatibility is not necessarily identical to every behavior of a hosted API. Start with the native API so that runtime and tunnel problems are not confused with client-library compatibility problems.

ollama pull MODEL_NAME

ollama run MODEL_NAME

curl --fail-with-body http://127.0.0.1:11434/api/tags

curl --fail-with-body http://127.0.0.1:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_NAME",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word ready."
      }
    ],
    "stream": false
  }'

Before continuing, confirm that the response identifies the requested model and contains an assistant message. The wording of generated text can vary, so validate the JSON structure rather than requiring an exact sentence. If this local request fails, do not create the tunnel yet. Resolve the runtime, model, or resource problem first.

Build a security boundary before public exposure

Secure exposure requires more than creating a tunnel. Begin with a threat model: identify who should call the service, what data they may submit, which operations they need, how much compute they may consume, and what would happen if credentials or the URL leaked.

Principal risks

Transport encryption is not authorization

A Localtonet HTTP tunnel provides a public HTTPS address. HTTPS protects HTTP traffic on the public connection against passive observation and tampering in that portion of the route. It does not prove that a caller is allowed to use the model. Authorization must be enforced by an application component that understands and validates the caller's credentials.

Localtonet authentication, SSO, and IP-restriction controls are not assumed in this tutorial because their current behavior is not established by the supplied product documentation. Instead, use a separately authenticated application, API gateway, or reverse proxy when the endpoint will be shared or kept available.

Recommended separation

Keep Ollama on 127.0.0.1:11434. Configure your chosen gateway or application to listen on another local loopback port, authenticate each request, and proxy only the required inference paths to Ollama. Then point Localtonet to the gateway port, not directly to port 11434.

Controls to implement where supported

• Require endpoint-level authentication and reject missing, expired, or invalid credentials.
• Grant each caller only the operations and models required for the workflow.
• Restrict accepted methods and paths instead of forwarding an entire administrative interface.
• Set request-body, context, output, concurrency, and timeout limits appropriate to your gateway and runtime.
• Decide whether prompts and responses may be logged. Redact or disable sensitive logging where your software supports it.
• Keep gateway credentials, Localtonet device tokens, and other secrets out of command-line arguments, repositories, screenshots, and client-side code.
• Rotate credentials after suspected disclosure and review the gateway's access records if logging is enabled.
• Stop the tunnel when remote access is no longer required.

Create and start the Localtonet HTTP tunnel

The tunnel target depends on your security design. For a short, controlled, non-sensitive test, the target can be Ollama at 127.0.0.1:11434. For recurring or shared access, the target should be the local port of your separately authenticated gateway.

HTTP and File Server tunnels support Random Sub Domain, Custom Sub Domain, and Custom Domain process types, and each serves content at a public HTTPS address. Availability can vary by plan or current product configuration. This tutorial uses a process type available in your dashboard and does not prescribe custom-domain DNS records because those requirements must be checked against current Localtonet documentation.

Verify the public endpoint from a remote system

Test from a device or network separate from the inference machine. A browser opened on the same machine is not a complete remote test. Replace PUBLIC_HTTPS_URL with the exact HTTPS URL displayed by Localtonet and replace MODEL_NAME with the exact installed model name.

Controlled direct-Ollama test

Use this only for a brief test that does not contain sensitive data. The following request confirms that the native tags route is reachable through the tunnel:

curl --fail-with-body "PUBLIC_HTTPS_URL/api/tags"

Then submit a small non-streaming chat request:

curl --fail-with-body "PUBLIC_HTTPS_URL/api/chat" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_NAME",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word ready."
      }
    ],
    "stream": false
  }'

A successful response should be valid JSON containing an assistant message. The first request can take longer if the model is not already loaded. After this controlled test, stop the tunnel unless you have implemented authorization.

Authenticated gateway test

The exact credential format is determined by your gateway, not by Ollama or the tunnel. For a gateway that explicitly validates a bearer token, a request may take this form:

curl --fail-with-body "PUBLIC_HTTPS_URL/api/chat" \
  -H "Authorization: Bearer YOUR_GATEWAY_CREDENTIAL" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_NAME",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word ready."
      }
    ],
    "stream": false
  }'

Replace the example header with the authentication scheme documented by your gateway. Store the real credential in an appropriate secret store or environment mechanism rather than committing it to source code. An arbitrary API-key string has no protective value unless a component in the request path validates it.

Test the negative path

A successful authorized request is only half of an authentication test. Repeat the request with no credential and then with an invalid credential. The gateway should reject both before the request reaches Ollama. If an unauthenticated request still produces a model response, the authorization boundary is not working.

Also test an allowed endpoint and a path that should not be exposed. A narrow gateway should forward the required inference routes and deny administrative or unrelated paths. Record expected response codes according to the gateway you selected rather than assuming every implementation uses the same error format.

Operate the endpoint safely and shut it down cleanly

A local model exposed for remote use is a small internet-facing service. Treat it as an operational system even when it runs on a workstation. The public route, local runtime, authorization layer, and host resources can fail independently.

Routine checks

• Verify the local Ollama tags and chat endpoints before investigating the tunnel.
• Confirm the authenticated gateway rejects missing and invalid credentials.
• Confirm the selected Localtonet client remains connected.
• Confirm the tunnel is running, not merely created.
• Watch memory, compute utilization, storage, and request latency on the inference host.
• Review gateway access records where logging is enabled and permitted by your data-handling policy.
• Recheck model names after pulling, replacing, or removing models.
• Retest authorization after gateway, runtime, or client upgrades.

Model and request lifecycle

Initial requests may be slower while a model loads. Larger prompts and contexts require additional processing and memory. Multiple simultaneous callers can increase queueing or trigger resource errors. Set realistic client timeouts and introduce concurrency or request limits in the authenticated application where supported.

Streaming responses also behave differently from a single JSON response. Use "stream": false during initial diagnosis. Once the basic route works, test streaming with the actual client and gateway because buffering and client timeout behavior can differ.

Shutdown sequence

How other local LLM runtimes fit this workflow

The networking pattern is not specific to Ollama. Any local HTTP inference server can be a tunnel target if the Localtonet client can reach its listener. However, ports, startup flags, API paths, authentication settings, model formats, hardware support, and user-interface navigation are runtime and version specific.

Do not assume that every local AI tool exposes the same OpenAI-compatible endpoints or accepts the same request fields. Even when a runtime advertises compatibility, model naming, streaming, tool calls, structured output, embeddings, error bodies, and authentication behavior can differ. Validate the runtime locally before creating a tunnel.

Safe adaptation checklist

1. Install the runtime from its current first-party distribution.
2. Acquire a model using the runtime's documented model workflow.
3. Start the intended API, not merely a browser chat interface.
4. Identify the actual listening IP address and port from the running configuration.
5. Call the intended API path locally with a documented payload.
6. Place authentication and request controls in front of the runtime if they are not built in.
7. Create and start a Localtonet HTTP tunnel targeting that protected listener.
8. Repeat the same request remotely and verify unauthorized requests fail.

The current public pages for LM Studio and Jan describe evolving product lines, which is another reason not to copy old ports or menu paths into a new deployment. Consult the documentation bundled with or published for the exact release you install.

Troubleshooting an Ollama and Localtonet endpoint

Diagnose from the inside out: model, local Ollama API, authorization layer, Localtonet client, tunnel state, and remote request. This order prevents a public routing problem from hiding a simpler local failure.

The local server is unreachable

Run the local tags request again:

curl --fail-with-body http://127.0.0.1:11434/api/tags

If the connection is refused or times out, confirm Ollama is installed and running according to the current instructions for your operating system. Check whether the API was configured to use a different address or port. Localtonet cannot forward to a service that is not listening.

The tunnel targets the wrong address or port

Confirm that the tunnel target matches the component you tested locally. A direct temporary test normally targets 127.0.0.1:11434. A protected deployment must target the authenticated gateway's port instead. If Localtonet runs in a container, virtual machine, or different physical device, its 127.0.0.1 refers to that environment, not automatically to the Ollama host.

The Localtonet client is disconnected

The tunnel depends on the selected device being connected. Confirm that the Localtonet application is running on the intended machine, that the authenticated device is the one selected by the tunnel, and that the machine still has outbound connectivity. Do not solve this by opening an inbound router port.

The tunnel was created but never started

Creation and startup are separate lifecycle actions. Open the tunnel list and check its status. Press Start if it is stopped. If it stops again, first confirm the selected client is connected and the local target responds.

The model name is invalid

Query /api/tags locally and copy the exact model name into the request body. A catalog name, display name, or tag from another machine may not match what is installed. Pull the intended current tag if it is absent, then repeat the local request before testing remotely.

The API payload is malformed

Confirm that the request uses POST, includes Content-Type: application/json, contains valid JSON, names an installed model, and uses the fields expected by the selected Ollama endpoint. Shell quoting differs across operating systems, so test from a file or an API client if your shell alters quotation marks.

Authentication fails

Determine which component validates credentials. Localtonet forwarding does not make an arbitrary Authorization value valid. Check the authenticated gateway's current configuration, credential format, expiration, audience, and path rules. First test the gateway on its local port, then test through the public URL.

If requests succeed without credentials, stop the tunnel and correct the gateway routing. The protected tunnel must target the gateway, not a parallel route that reaches Ollama directly.

The request times out while loading the model

Submit a small local request and allow the model to load before repeating the remote test. Check host memory and compute utilization. A client, gateway, or automation platform may have a shorter timeout than Ollama needs for cold loading. Adjust only the component whose documented timeout is too short, and avoid masking persistent resource exhaustion with extremely long retries.

Context or resource errors appear

Reduce the prompt size, conversation history, requested output, or concurrency. Try a model appropriate for the available hardware. Model size is only one factor, so inspect the runtime's actual error and resource usage. Do not assume a tunnel problem when the HTTP request reaches Ollama and Ollama returns a model or memory error.

Local requests work but remote requests fail

• Confirm the public URL is copied exactly and uses https://.
• Confirm the selected Localtonet device is connected.
• Confirm the tunnel is running.
• Confirm the target matches the locally tested listener.
• Test the same path and payload locally and remotely.
• Check whether the gateway rejects the remote credential or path.
• Use a simple non-streaming request before diagnosing streaming behavior.

Remote metadata works but chat generation fails

A successful tags response proves routing to Ollama, but it does not prove the requested model can load or generate. Check the exact model name, then run the same chat payload locally. Inspect runtime errors, available memory, model state, prompt size, and timeout behavior.

Responses are slow or unstable

Compare local and remote timing. If local generation is already slow, investigate model size, context, quantization, hardware, and concurrent workload. If only remote calls fail, inspect the gateway and client timeout behavior. Network exposure cannot make inference faster than the host can generate results.

Frequently asked questions