Install a local Unsloth web interface, verify it, and make it available through a controlled HTTP tunnel
Unsloth Studio provides a browser-based interface for running and training AI models on your own hardware. This guide starts with the official installation process for Windows, Linux, macOS, and WSL, then verifies the interface locally on an explicitly configured port. After the local service works, we connect it to a Localtonet HTTP tunnel for remote access without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. Localtonet is an optional alternative for remote connectivity because Unsloth also documents its own secure Cloudflare-based access mode.
What this setup includes
Unsloth can be used as a native desktop application, as the browser-based Unsloth Studio interface, or as the code-oriented Unsloth Core package. This tutorial focuses specifically on a manual Unsloth Studio installation because Studio exposes a local web interface that can be opened in a browser and connected to an HTTP tunnel.
The sequence matters. First, install Studio using the official installer for your operating system. Next, launch it on a known local address and port, open that address locally, and create the initial Studio password. Only after those checks succeed should you configure remote access. This separation makes troubleshooting easier because it confirms whether a problem belongs to Unsloth, the local machine, or the remote-access configuration.
Review the installation requirements
Requirements vary by operating system, hardware, and the work you intend to perform. Running the Studio interface, chatting with a model, and training a model do not necessarily place the same demands on a system. Consult the current Unsloth requirements for your hardware before downloading large models or beginning training.
The official Studio documentation states that Windows installations work directly on 64-bit Windows 10 or Windows 11. It identifies NVIDIA drivers as a requirement for relevant Windows training setups and lists supported Python versions from 3.11 up to, but not including, 3.14. It also recommends working inside a Python environment such as uv, venv, or conda/mamba. On WSL, the documentation instructs NVIDIA users to install the NVIDIA driver on Windows rather than inside WSL, while installing the CUDA toolkit inside the WSL distribution.
For macOS, the documented baseline is macOS 12 Monterey or newer on Intel or Apple Silicon. Hardware support and available model operations can change, so verify the latest Unsloth documentation rather than treating one platform as equivalent to another. A successful web-interface launch does not by itself prove that a particular model will fit in memory or that a selected training workflow is supported by the machine.
| Environment | Official manual installer | Important preparation |
|---|---|---|
| macOS | Shell installation script | Use a supported macOS release and confirm that the intended model workflow supports the available hardware. |
| Linux | Shell installation script | Review the current hardware and driver requirements for the GPU or CPU workflow you plan to use. |
| WSL | Shell installation script inside the WSL distribution | For NVIDIA setups, follow Unsloth guidance about the Windows driver and the CUDA toolkit inside WSL. |
| Windows | PowerShell installation script | Use PowerShell and review the documented Windows, driver, Python, Git, and environment requirements. |
Unsloth Desktop is the native application, while Unsloth Studio is the browser-based web UI covered here. The commands below install Studio manually. If you choose the native desktop download instead, follow the desktop-specific instructions rather than mixing the two installation paths.
Install and verify Unsloth Studio
Install Studio with the official installer for your platform
On macOS, Linux, or WSL, open a terminal and run the official shell installer shown below. On Windows, open PowerShell from the Start menu and run the official PowerShell installer. The installer may ask whether you want to start Studio immediately. You can accept that prompt or start it manually afterward.
Launch on port 8888 and verify the local interface
Start Studio with port 8888 explicitly selected, then open http://127.0.0.1:8888 in a browser on the same machine. On first launch, create a strong password. Confirm that the Studio interface reaches its Chat page before continuing to Localtonet.
macOS, Linux, and WSL installation command
curl -fsSL https://unsloth.ai/install.sh | shRun this command in the terminal for macOS or Linux, or inside the selected Linux distribution when using WSL. Review the script source and your organization’s software-installation policy before piping a remote script into a shell. If the installer offers to launch Studio and you accept, it can start the interface as part of setup.
Windows PowerShell installation command
irm https://unsloth.ai/install.ps1 | iexRun this command in PowerShell. The installer handles the Studio setup and may ask whether it should launch the application after installation. If command execution is restricted by your organization, consult the administrator responsible for the machine rather than weakening system policy without approval.
Launch Studio on an explicit local port
unsloth studio -p 8888This command explicitly selects port 8888. It does not rely on an assumed default. Open the following local URL after the application starts:
http://127.0.0.1:8888A first-time installation should prompt you to create a password before continuing to the Chat page. Complete that step and confirm that you can reload the interface and sign in. If the page does not open, keep the investigation local. Check the Studio process output, confirm that the process is still running, and verify that another program is not already using the selected port.
Unsloth warns that server-side tools are enabled by default. Do not publish an unprotected Studio instance. Create a strong, unique Studio password, avoid sharing the public tunnel address unnecessarily, and consider Unsloth’s documented tool-disabling option when server-side tools are not required. Remote access should follow your organization’s authorization and least-privilege policies.
Choose the correct bind address
The address used by Studio determines which network interfaces can accept a connection. The loopback address, 127.0.0.1, limits direct access to software running on the same operating-system network environment. Binding to 0.0.0.0 listens on available interfaces and can make the service reachable from other devices when host and network controls permit it.
When the Localtonet client runs on the same machine and can reach Studio at 127.0.0.1, the narrower loopback binding is preferable because it avoids adding direct LAN exposure merely for tunneling. WSL and containerized environments can have additional network boundaries, so verify reachability from the environment where the Localtonet client actually runs.
If the client cannot reach the loopback listener because it runs in a different environment, Unsloth documents the following explicit external-interface binding:
unsloth studio -H 0.0.0.0 -p 8888Use that broader binding only when it is required. Recheck the host firewall, LAN exposure, and authentication because other devices may be able to reach the service directly. Binding to 0.0.0.0 is not a security feature and does not replace the Studio password.
Connect the verified Studio service with Localtonet
Once http://127.0.0.1:8888 works locally, the Studio interface is a suitable target for an HTTP tunnel. With Localtonet, our client on the device establishes an outbound connection to a relay server. The tunnel then provides a public address for the local service, so inbound router port forwarding, firewall changes, a VPN, and a public IP address are not required for the standard tunnel workflow.
Creating a tunnel does not automatically start it. The selected Localtonet client must remain connected, and the tunnel must be running. Studio must also remain active on the configured local port. If any part of that chain stops, the remote interface becomes unavailable.
Install and run the Localtonet client
Install our client on the device that can reach the Unsloth Studio endpoint. For a straightforward setup, run it on the same machine as Studio and verify that Studio is still available locally.
Authenticate or select the client device
Use the device-specific authentication token associated with the client that will run the tunnel. Never place that token in documentation, screenshots, shell history, or public messages.
Select an available relay server
Choose a currently available server or region from the Localtonet dashboard. Available server codes and regions can change, so obtain the value from the current product instead of copying a hardcoded example.
Create an HTTP tunnel to Studio
Choose the HTTP tunnel family and configure the local target as the address and port that you already verified. For a same-machine setup, use 127.0.0.1 and port 8888. If your environments require another reachable address, use only the address you tested from the Localtonet client device.
Start the tunnel and test the assigned address
Press Start, then open the assigned public address from a separate device or network. Confirm that the Unsloth password prompt appears and that authenticated access works as expected.
Stop or delete access when it is no longer needed
Stop the tunnel after the remote session if continuous access is unnecessary. Delete the tunnel when you no longer intend to use the configuration.
For current dashboard guidance, review our Localtonet HTTP tunnel documentation. Exact domain options, available relay servers, and plan-specific capabilities should always be checked in the current dashboard rather than assumed from an example.
Local access, LAN access, and tunnel access compared
| Access method | Typical listener | Best use | Key consideration |
|---|---|---|---|
| Local browser only | 127.0.0.1:8888 | Installation verification and private same-machine use | Not directly reachable from another device. |
| Direct LAN access | 0.0.0.0:8888 | Access from authorized devices on the same network | Can expose Studio to the LAN, subject to host and network controls. |
| Localtonet HTTP tunnel | A tested local IP address and port | Remote access through a public tunnel address | The client, tunnel, and Studio process must all remain running. |
| Unsloth secure mode | Defined by Unsloth | Unsloth’s built-in Cloudflare-based HTTPS access option | This is an alternative to Localtonet, not a prerequisite for it. |
Unsloth documents a --secure option that creates a Cloudflare-based remote HTTPS link. You do not need to combine that mode with a Localtonet HTTP tunnel. Choose one remote-access approach, understand its authentication model, and avoid creating multiple public paths unless there is a clear operational need.
Troubleshooting the complete connection path
The local page does not open
Do not configure the tunnel yet. Confirm that the unsloth studio -p 8888 process is running and that the terminal has not reported an installation or startup failure. Verify the exact URL, including the port. If port 8888 is occupied, consult current Unsloth guidance before choosing and configuring another port, then use that same verified port as the tunnel target.
The local page works, but the public address does not
Confirm that the Localtonet client is connected and that you selected the correct device token. Check that the tunnel was started rather than merely created. Verify that its local target matches the working Studio address and port. In WSL, containers, or split host environments, remember that 127.0.0.1 can refer to a different network namespace from the one where the client runs.
The password page appears remotely
That is expected for a protected first-time or signed-out session. Use the password created through Studio. Do not place the password in the tunnel configuration or share it alongside the public address. Localtonet device tokens and Unsloth application passwords serve different purposes and should both remain private.
The public address stops responding later
Check every component in order: the Unsloth Studio process, the local endpoint, the Localtonet client connection, and the tunnel state. A Localtonet tunnel is available only while its selected client is connected and the tunnel is running. Restarting the machine can also stop Studio unless you have separately configured an approved startup process.
Frequently asked questions
Is port 8888 always the default Unsloth Studio port?
This guide does not assume that it is always the default. The command unsloth studio -p 8888 explicitly selects port 8888, and that verified value is then reused as the Localtonet tunnel target.
Must Studio bind to 0.0.0.0 for Localtonet?
Not necessarily. If our client runs on the same machine and can reach Studio through 127.0.0.1, a loopback listener can be used. A 0.0.0.0 binding may be needed when the client runs across a separate WSL, container, or host boundary, but it also broadens direct network exposure.
Does Localtonet replace the Unsloth password?
No. Keep the Studio password enabled and use a strong, unique value. The tunnel provides connectivity to the local service, while Studio remains responsible for its application-level sign-in behavior.
Do I need router port forwarding or a public IP address?
No. The Localtonet client establishes an outbound connection to our relay, so the standard tunnel workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Is Localtonet required for remote Unsloth Studio access?
No. Unsloth documents its own --secure Cloudflare-based remote-access option. Localtonet provides an alternative HTTP tunneling workflow when you want to manage the connection through our dashboard or REST API.
Why does the remote address stop working when the client closes?
The tunnel is available only while the selected Localtonet client is connected and the tunnel is running. The Unsloth Studio process must also remain active on the configured local address and port.
Connect your verified Unsloth Studio interface
Install Studio, confirm that its password-protected local page works, then create a Localtonet HTTP tunnel to the tested local address and port. Keep the tunnel active only for as long as remote access is required.
Get Started Free →
