Run an AI chat and RAG platform on your own infrastructure, verify it locally, and make its web interface available remotely
Onyx is an open-source AI platform that provides a browser-based interface for LLM chat, agents, retrieval-augmented generation, web search, actions, and other AI workflows. This guide begins with the official Onyx installation method, explains how to select between Lite and Standard deployment modes, and shows how to verify the application on the host before exposing anything publicly. After the local deployment works, we configure a Localtonet HTTP tunnel as a separate remote-access step. Because the documented evidence does not establish a universal Onyx hostname, port, or local protocol, the tunnel must use the endpoint reported by the installer or the current Onyx deployment documentation.
What Onyx provides
Onyx is the application layer between users, language models, organizational knowledge, and connected applications. Its web interface can support ordinary LLM conversations as well as agents with custom instructions, knowledge, and actions. The platform also includes capabilities such as web search, file uploads, code execution, deep research, and integrations through connectors or MCP.
Self-hosting is useful when a team wants to operate the application on infrastructure it controls. The Onyx Community Edition is available under the MIT license and includes core functionality for chat, RAG, agents, and actions. Onyx also documents an Enterprise Edition with additional capabilities intended primarily for larger organizations. This tutorial focuses on installing the self-hosted platform and does not assume that Enterprise Edition functionality is available.
A self-hosted deployment is not automatically reachable from outside its local network. It normally starts as a service available only on the host or LAN. That is the right place to begin. Confirming that the web interface starts and behaves correctly before adding remote access keeps application troubleshooting separate from tunnel troubleshooting.
Choose between Onyx Lite and Standard
Onyx offers two deployment modes with different resource and feature profiles. Choose the mode before installation so that the resulting stack matches your intended use. Lite is appropriate for evaluating the chat experience or operating a smaller interface focused on chat and agents. Standard is intended for the complete platform, particularly when retrieval, connectors, indexing, and larger team workflows are required.
| Capability | Onyx Lite | Onyx Standard |
|---|---|---|
| Primary use | Lightweight chat UI and agents | Complete Onyx platform for serious users and larger teams |
| Memory profile | Documented as requiring under 1 GB of memory | Requires additional resources for its more complex stack |
| Chat, tools, uploads, and Projects | Included | Included |
| Vector and keyword index for RAG | Not included | Included |
| Background connector workers | Not included | Included |
| Supporting infrastructure | Does not include model inference servers or the full indexing stack | Includes model inference components plus performance optimizations using Redis and MinIO |
Standard mode is the appropriate choice when the deployment must ingest knowledge from connectors and build the indexes used for RAG. Lite can be a more practical starting point when the immediate objective is to test LLM chat, tools, file uploads, Projects, or agents without deploying the complete indexing stack.
The supplied Onyx evidence establishes that Lite uses under 1 GB of memory, but it does not provide a complete CPU, storage, operating-system, or Standard-mode sizing matrix. Review the current Onyx deployment overview and its linked resourcing guidance before selecting a production host.
Install and verify Onyx locally
The recommended Onyx quickstart is a guided installation script that deploys the platform through Docker Compose. The extracted documentation does not establish every operating-system prerequisite or describe every prompt shown by the installer. It is therefore important to use the current Onyx documentation for prerequisites and to read the installer output instead of assuming that a particular package, port, path, or service name will apply to every deployment.
Prepare a host that meets the current Onyx requirements
Select a machine for the deployment and review the current Onyx resource guidance. The recommended installer deploys a Docker Compose stack, so confirm that the host satisfies the installation requirements documented by Onyx. Do not infer production capacity from Lite mode's under-1-GB memory description, especially if you plan to run Standard mode, indexing, connectors, or model-related components.
Select Lite or Standard mode
Use Lite for a smaller chat-and-agents deployment, or Standard when you need vector and keyword RAG indexes, connector synchronization workers, model inference components, Redis, and MinIO. The guided installer supports both modes.
Run the official installation command
Run the installer command published by Onyx from the host where the Docker Compose deployment will operate. Follow its guided prompts and retain the final output because it may contain the endpoint and operational information needed for local verification.
curl -fsSL https://onyx.app/install_onyx.sh | bashIdentify the actual local web endpoint
Obtain the local hostname or IP address, port, and protocol from the installer output or the current Onyx deployment documentation. The supplied evidence does not specify a universal local URL, port, or whether every installation serves HTTP or HTTPS locally. Record the real endpoint rather than substituting a familiar web port.
Open the Onyx interface locally
From the host, or from another authorized device that can reach it, open the exact endpoint identified in the previous step. Confirm that the Onyx interface loads. Complete the application setup required by the current Onyx version, including any administrator, model-provider, or deployment configuration presented by Onyx.
Test the application before tunneling
Sign in if authentication is enabled and perform a basic workflow appropriate to the selected mode. Confirm that pages load and that the application remains reachable after a refresh. Resolve container, model, database, connector, or application errors locally before configuring Localtonet.
The command above downloads the official Onyx installation script and pipes it directly to Bash. This is the command published by Onyx, but administrators should still apply their normal software review and change-control practices. If your policy requires inspection before execution, review the current script and Onyx documentation first rather than running remote code without approval.
Prepare Onyx for remote access
Publishing the interface changes its exposure boundary. A page that was previously limited to the host or LAN will receive traffic through a public address. Before creating the tunnel, verify that Onyx has appropriate authentication and that users receive only the access they need. Do not treat possession of an unlisted public URL as an access-control system.
Also identify the machine on which our Localtonet client will run. It can run on the Onyx host or on another device that can reach the Onyx web endpoint. The local target entered into the tunnel must be reachable from that client device. If Onyx listens only on a loopback address, a client running on another machine may not be able to connect to it.
Complete local setup, configure application authentication where appropriate, and remove test credentials before starting a public tunnel. Protect model-provider keys, connector credentials, authentication tokens, internal documents, and private endpoints. A tunnel provides connectivity, but application authorization remains essential.
Publish the Onyx web interface with Localtonet
Once the Onyx interface works locally, an HTTP tunnel is the natural Localtonet configuration for its browser-based UI. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, a public IP address, VPN setup, or inbound firewall changes. The public tunnel remains available only while the selected device is connected and the tunnel is running.
Install and run the Localtonet client
Install our client on the Onyx host or on a device that can reach the verified Onyx endpoint. Start the client so that the device can establish its outbound connection to our relay platform.
Authenticate or select the client device
Use the device-specific authentication token associated with the client that will run the tunnel. Keep this token private. Never place it in documentation, screenshots, source repositories, shell history shared with others, or public configuration examples.
Select an available relay server
Choose an available server or region from the current Localtonet dashboard. Available values can vary, so obtain the selection from the product rather than copying a hardcoded server code from an old tutorial.
Create an HTTP tunnel for the verified target
Create the appropriate HTTP tunnel and enter the local IP address and port that you confirmed during Onyx verification. Match the target to the real deployment endpoint. Do not assume a port or silently switch between local HTTP and HTTPS. HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain process types, with availability and domain requirements determined by the current product configuration.
Start the tunnel and test the public address
Creating a tunnel does not start it. Press Start, then open the assigned public URL from a network outside the Onyx host's LAN if possible. Confirm that the Onyx interface loads and that authentication is enforced as intended. A public HTTP tunnel serves content at a public HTTPS address.
Stop or delete access when it is no longer needed
Stop the tunnel when remote access is temporary, or delete it if the configuration is no longer required. The endpoint is reachable only while the selected client device is connected and the tunnel is running.
Troubleshoot the deployment in layers
If the public URL does not work, begin with the local application. Open the exact Onyx endpoint directly from the Localtonet client device. If that request fails, the tunnel cannot forward traffic successfully. Check the Onyx deployment and its Docker Compose services using the operational instructions provided by the current Onyx installer or documentation.
If Onyx works from the client device, verify that the tunnel target contains the same reachable IP address and port. A loopback address refers to the device on which the client runs. It will not refer to a different server on the LAN. Also confirm that the correct Localtonet device is connected, the selected relay value is current, and the tunnel has been started rather than merely created.
If the login page appears publicly but a feature fails after sign-in, test that feature locally. This distinction helps determine whether the problem belongs to Onyx configuration, an LLM provider, a connector, a supporting container, or network exposure. Avoid changing several layers simultaneously because that makes the original fault harder to identify.
Frequently asked questions
What port does Onyx use?
The supplied official evidence does not establish one universal Onyx port, hostname, or local protocol. Use the endpoint reported by the guided installer or specified by the current documentation for your chosen deployment. Do not guess the port when configuring the Localtonet target.
Should I install Onyx Lite or Standard?
Choose Lite when you want a lightweight chat UI with agents, tools, uploads, and Projects. Choose Standard when you need the full RAG indexing stack, background connector workers, model inference components, Redis, and MinIO. Standard is recommended by Onyx for serious users and larger teams.
Does Localtonet install or manage Onyx?
No. Install, configure, and verify Onyx through its official deployment workflow first. With Localtonet, we provide the connectivity layer that forwards a public address to the working local web endpoint.
Do I need router port forwarding or a public IP address?
No. Our client establishes an outbound connection to a Localtonet relay server. This allows the tunnel to provide a public URL without inbound router port forwarding, inbound firewall changes, VPN setup, or a public IP address.
Is the Onyx interface always available after I create the tunnel?
No. Creating a tunnel does not start it. The selected client device must be connected and the tunnel must be running. If the client stops, loses connectivity, or the tunnel is stopped, the public endpoint will no longer forward to Onyx.
Does a public tunnel replace Onyx authentication?
No. The tunnel supplies network reachability, not a replacement for application authorization. Configure Onyx authentication and appropriate user permissions before exposure, protect credentials and provider keys, and stop the tunnel when public access is not required.
Publish your verified Onyx interface with Localtonet
Install Onyx, confirm its real local endpoint, and then create an HTTP tunnel from a connected device that can reach it. Keep application authentication enabled and start the tunnel only when remote access is appropriate.
Get Started Free →
