Bring your local dataset workspace to another browser, without moving the workstation
LoRA Dataset Studio (LDS) is a self-hosted browser application for preparing image datasets, captioning images, training LoRAs and comparing results. This guide covers the Windows ZIP installation, a small local verification workflow, and the checks needed before connecting it to a Localtonet HTTP tunnel. Your workstation continues to run the application and its tools; the remote device provides the browser. We distinguish release-confirmed instructions from configuration details that must be verified on your installed version, especially authentication, storage paths and the listening address.
📋 What's in this guide
What runs locally, and what remote access changes
Dataset work spans many sessions: importing images, removing duplicates, selecting a balanced set, correcting captions, starting training and comparing checkpoints. The workstation that holds the files and GPU-backed tools does not need to be the device on which you review every image. A remote browser can provide access to the interface while the application continues running on that workstation.
The LoRA Dataset Studio project describes a ComfyUI-powered studio with JoyCaption captioning, ai-toolkit training and checkpoint comparison. Its listed model families include Krea 2, FLUX.1, FLUX.2 Klein, Qwen-Image 2.1, Z-Image, SDXL and Anima. Support for a model family does not mean every machine can train it, or that all dependencies arrive with the core application.
With Localtonet, our client establishes an outbound connection from your machine to a relay server. An HTTP tunnel provides a public HTTPS address forwarding to the local web service, without inbound router port forwarding, a public IP address or VPN setup. Standard HTTP tunneling is not a VPN. The endpoint is available only while the selected client is connected and the tunnel is running.
Scope and evidence boundaries
This tutorial covers a new Windows ZIP installation, not Git migration, Docker deployment, manual Python installation or Pinokio setup. The supplied V2 release notes establish the ZIP workflow, plugin separation and update-preservation behavior. For downloads, use the newest applicable published release on the repository rather than assuming that this referenced release remains the latest.
The available project extracts include a documentation index, but not the substantive Requirements, Network access and privacy, Settings reference or Security instructions. They therefore do not establish exact Windows versions, RAM or VRAM minimums, default bind address and port, public-access settings, authentication defaults or backup contents. This is a limitation of the evidence available for this guide, not a claim that those details are absent from the project documentation. Do not proceed to public exposure until the access-control checks below are satisfied.
Prepare the machine, storage and feature dependencies
Start with a Windows machine on which you are permitted to install and run the application, a browser, internet access for downloading the release and required components, and a writable extraction folder. The release-confirmed ZIP launcher prepares a compatible Python environment. This route does not instruct you to install a particular Python version manually.
The current V2 installation guide is the installation companion. For feature-specific hardware and dependency requirements, the V2 documentation index, under Requirements, identifies the relevant guide. Exact numerical requirements are not reproduced in the available extracts, so this article does not assign a universal GPU, memory or disk minimum.
Separate the browser interface from AI workloads
Opening a dataset workspace and completing a training run test different parts of the system. Begin with a few non-sensitive images and ordinary organisation or manual-captioning work. Add automated captioning, generation and training only after the corresponding tools are ready. A working web page does not demonstrate model compatibility, sufficient VRAM or a successful training installation.
| Workload | Preparation | First useful check |
|---|---|---|
| Importing and organising | Core application, writable storage and a small test image set. The release notes say this does not require a plugin. | Import images and reload their thumbnails. |
| Automated captioning | Check the chosen engine or plugin's dependencies, model downloads and settings. | Caption one test image before processing a folder. |
| Generation and training | Confirm the chosen model's hardware needs, tools, model locations and any required ComfyUI custom nodes. | Run a small local job before testing remote control. |
| Paid APIs or rented GPUs | Provider credentials, applicable charges and permission to send the selected data to that provider. | Validate one intentional request and review its result. |
| Remote browser access | Working local interface, verified access control, connected Localtonet client and an HTTP tunnel target. | Test denied access before authenticated remote use. |
Plan storage before importing your main collection
Allow space for source images, working datasets, captions, model downloads, generated media, training outputs and backups. These categories can grow independently. Avoid filling the application drive with a first large import before you understand where each category is stored.
The available release notes promise update preservation of datasets, media, history and local configuration; they do not establish their exact filesystem paths. Do not assume everything lives beneath the extracted ZIP. Record actual locations from your installation's configuration and tool settings before making a backup or moving the application. External model or image folders also need consideration.
Licence, privacy and optional costs
The referenced release publishes the core and free public plugins under the PolyForm Noncommercial license. Describe this as source-available, not unqualified open source. Review the repository's licence before using it for client work or other commercial purposes. Some plugins and early releases are members-only; paid API engines and rented GPUs charge separately when selected.
Usage statistics are optional and off by default according to the release notes. The application asks before sharing, and the choice can be changed in Settings → Maintenance. That setting is distinct from sending images or prompts to an external service you intentionally configure. Review each tool's data handling before using private material.
Install the Windows ZIP release
Use the packaged Windows release asset, not GitHub's source-code ZIP. They are different installation inputs. The release-confirmed filename is LoRA-Dataset-Studio-windows.zip. Open the repository's published releases and check the installation notes associated with the version you choose.
Download the Windows release asset
From the official repository, open Releases and select the newest applicable published Windows release. Download LoRA-Dataset-Studio-windows.zip. Check its release notes for any changed requirements.
Extract into a new folder
Extract the ZIP into a fresh folder on a drive with room for the application and planned work. Do not extract over an existing installation as a substitute for a documented update or migration.
Run start.bat
Double-click start.bat in the extracted folder. The launcher prepares a compatible Python environment. Let preparation finish and inspect any errors rather than repeatedly starting additional copies.
Complete core Setup, then choose plugins
Open the running application at its verified local address and complete core Setup. Then use Plugins → Store for the optional features you need, reviewing each plugin's preparation requirements and settings.
The available release notes do not promise that every invocation of start.bat automatically opens a browser, or specify exactly where it displays the local URL. If a browser opens, inspect its address and verify that it loads. If it does not, inspect launcher output and the installed version's configuration for the listening address. A missing browser tab alone does not prove startup failed.
Why other installation routes are outside this walkthrough
The documentation index lists Git-related updates, manual Python and Pinokio installation, plus a dedicated Docker guide. These routes have different environment and storage considerations. The presence of Docker helper files or Pinokio scripts in the repository does not establish a complete deployment procedure.
Use the V2 installation guide for alternative installation methods and the documentation index's Docker and Migrate to V2 entries for those deployments. Existing Git checkouts tracking the former main branch require the documented migration to v2. Do not apply a fresh ZIP-install procedure to migrate existing data.
Understand core Setup and optional plugins
The referenced V2 release says Setup opens on a tools overview: what is ready, what is missing, and Downloads & repair. A guided setup organised by goal is available from there. Core Setup and plugin installation are separate stages; plugins are selected later through Plugins → Store.
Install only what you intend to use. Each plugin describes its features and preparation requirements, which can include ComfyUI custom nodes. Review its settings before the first run. This keeps a basic dataset-management test separate from failures caused by optional models, tools or providers.
The V2 getting-started guide is the project companion for the first dataset. For this tutorial, use a handful of images you are authorised to process, import them, inspect their thumbnails, edit a caption and verify the saved result. Do not begin by uploading your entire collection or launching a long training run.
For training preparation, the dataset quality guide explains how model family affects captions and settings. Its character-LoRA guidance emphasises keeping the subject consistent while varying other attributes and captioning intentionally. Treat that as task-specific training advice, not a universal rule for every concept or caption engine.
Verify local operation and identify the real target
Before configuring remote access, establish a reproducible local baseline. You need to know that LDS starts, that its interface saves changes, and that the Localtonet client can reach the same service.
- Confirm startup. Inspect the launcher for errors and leave the application process running.
- Open the local interface. Use the address confirmed by the running installation, not a guessed default port.
- Test a small dataset. Import a few test images and confirm thumbnails render.
- Test persistence. Save a caption, reload the page and confirm the change remains.
- Inspect tool readiness. Review Setup for dependencies relevant to your next task.
- Record the endpoint. Note the scheme, hostname or IP address, and port separately. Keep tokens and credentials out of that record.
A browser URL is not a bind-address declaration
A URL containing localhost tells you how that browser reached the application. It does not prove whether LDS listens only on loopback or on other interfaces too. Similarly, a wildcard listener such as 0.0.0.0 is a bind setting, not the destination address to enter as a tunnel target.
Run the Localtonet client on the same Windows machine for this walkthrough. Test the exact local IP and port you plan to use from that machine. localhost may resolve to IPv4 or IPv6, so do not assume that a successful hostname request proves a particular numeric address works. A client running in another machine or container has a different loopback context.
If you cannot identify and directly open the local target, stop here. The configuration details must come from the installed application or its matching documentation. Adding a tunnel will not discover or repair an unknown listener.
Establish access control before public exposure
A dataset studio is more sensitive than a static demo page. It can contain private photographs, modify files, launch resource-intensive jobs and use configured paid services. A public HTTPS address protects the browser-facing connection; it is not, by itself, proof that only authorised people can use the application.
Confirm a supported authentication or access-control boundary before starting a public tunnel. A difficult-to-guess URL is not authorization. If you cannot establish protection for the interface, its media and its action endpoints, keep the studio local or use an appropriately configured private-access solution instead.
The V2 documentation index identifies Network access and privacy for public-access configuration, Settings reference for environment overrides and configuration keys, and Security policy for safe exposure. The repository also contains the project security policy. Their full instructions are not present in the supplied extracts, so this guide does not invent an access-token variable, login setting or public-bind command.
In particular, the index's mention of a forced access token for RunPod is not evidence that a Windows ZIP installation has the same default. Verify the Windows deployment you actually run.
Test the boundary, not just the login screen
- Configure the access protection supported by your installed version, following its matching security instructions.
- Open a fresh private browser session without existing application cookies or credentials.
- Confirm that the unauthenticated session cannot browse datasets, view protected media or perform actions. Test known resource addresses using disposable test data.
- Authenticate intentionally and verify that normal work succeeds.
- Repeat the unauthenticated checks at the public endpoint during the controlled tunnel test below.
A private window provides a clean browser session, not an independent network location. Use a phone on mobile data for the remote-network test as well. If the clean session can open the workspace without the intended authorization, stop the tunnel immediately.
Keep device tokens, application access tokens and provider API keys private. Do not include them in screenshots, browser-address captures or diagnostic reports. Limit access to trusted users and review their ability to trigger paid or destructive operations. Follow the project's responsible-use guidance for consent, privacy and source rights.
Connect the verified service with Localtonet
Use an HTTP tunnel for the browser interface. It forwards to a local IP address and port and supplies a public HTTPS endpoint. Our HTTP tunnel documentation is the configuration reference. The following follows the verified platform lifecycle; the supplied material does not include a current screen-by-screen HTTP form specification.
Install and run the Localtonet client
Run our client on the Windows device that hosts LDS and can open its verified local endpoint. Keep LDS running while you configure connectivity.
Authenticate and select the device
Use the device-specific auth token to connect the client and identify the machine that will run the tunnel. Keep the token private; it is not an LDS password or a value to share with remote users.
Select an available relay server
Choose from the server options currently offered in your dashboard. Do not copy a server code from an unrelated example or assume every region is available to every account.
Create the HTTP configuration
Select the HTTP tunnel family, the intended device and the verified local IP address and port. HTTP Process Types are Random Sub Domain, Custom Sub Domain and Custom Domain. Use an available option appropriate to your account; check current DNS instructions before choosing a custom domain.
Start and test the tunnel
Creating the configuration does not start it. Press Start and use the assigned public HTTPS address. First test denied access in a clean session, then authenticate and repeat your small dataset checks from another network.
Stop or delete access when finished
Stop the tunnel when remote access is no longer needed, or delete an obsolete configuration. Availability requires both a connected client and a running tunnel.
Verify the complete remote workflow
After verifying the access boundary, load the workspace, open a test image, save a caption and reload it. Import a small batch and inspect the results. If the page shell loads but images or actions fail, the application is not yet fully verified through the public origin.
Do not disable authentication, origin checks or other protections merely to make a remote request succeed. Inspect the failed request and application error, then apply only the configuration supported by LDS for public access.
No combined LDS and Localtonet throughput or upload-limit benchmark is established here. Test representative batches before depending on remote bulk imports. A practical workflow is to import large local collections at the workstation and use remote sessions for curation, caption editing and progress review.
Operate, update and back up the installation
Understand the independent lifecycles
LDS, its optional tools, the Localtonet client and the tunnel are separate moving parts. Stopping the tunnel removes that public route; it does not constitute a command to cancel an LDS job. Likewise, a connected Localtonet device does not prove that the application is healthy. After a restart, verify LDS locally before diagnosing remote connectivity.
Prevent unintended workstation sleep during a planned session using your organisation's approved power settings. Closing a remote browser is not a reliable job-cancellation method. Check job state in the application before maintenance or shutdown.
Update preservation is documented, but still make a backup
The referenced V2 release states that ZIP installations can use Settings → Maintenance → Update & restart to install the next published release while preserving data and local configuration, including datasets, media and history. Plugins are installed and updated separately through the Store. Review plugin settings and preparation requirements after updating.
That preservation statement is not a backup guarantee or a rollback procedure. Before updating, finish or safely stop active work, record the application version, and create a recoverable backup. An application restart can interrupt a browser session. Afterward, repeat the local persistence test, check plugin readiness, recheck access control and confirm the tunnel target has not changed.
Back up actual data locations
The project's Back up everything section is the relevant application-specific procedure. Its detailed contents are not included in the available extract, so this guide does not claim that a particular export includes all images, models, external folders, credentials or plugin data.
As a general backup practice, make an inventory before copying anything: datasets and captions, original media, generated outputs, history, configuration, plugin settings and external tool paths. Identify which items an application backup includes and preserve omitted locations separately. Avoid copying actively changing state without a consistency procedure. Keep a protected copy outside the installation folder and test restoration without overwriting your only working installation.
Monitor connectivity separately from application health
Our platform-wide Token/Tunnel webhooks report Connected or Disconnected changes for a selected Token Group. Their JSON body contains Id, ActionDate, Type and Status. These events can help detect a disconnected workstation, but they do not prove that an LDS import or training job succeeded. See the Localtonet webhook documentation. These are distinct from File Server's file-event webhooks.
Troubleshoot from the application outward
Change one layer at a time: application startup, local endpoint, local functionality, access control, client connection, tunnel and remote workflow. Keep a small test dataset for repeatable checks.
| Symptom | Possible explanation | Next check |
|---|---|---|
| No browser appears after start.bat | Browser launch did not occur, preparation is ongoing or startup failed. | Inspect launcher output. Discover and open the verified local endpoint; do not assume a missing tab means failure. |
| The local page does not load | The process is stopped, startup failed or the address is wrong. | Resolve the local error first. A tunnel cannot repair a service that is not listening. |
| Local page works, public endpoint fails | Wrong target, wrong device, disconnected client or stopped tunnel. | Test the exact IP and port from the client machine and check device and tunnel status. |
| Page loads but images or saves fail | Application errors, storage problems or public-origin configuration issues. | Compare the same action locally and remotely, inspect errors and retain security protections. |
| Private session opens datasets without authorization | The access boundary is missing or ineffective. | Stop the tunnel immediately and fix protection before further public testing. |
| Caption generation or training fails while browsing works | Missing models, tool configuration, provider errors or insufficient resources. | Reproduce locally; inspect Setup, Downloads & repair and plugin requirements. |
| Optional features are missing after updating | The core update and plugin installation are separate. | Review Plugins → Store and each plugin's readiness. Do not assume data deletion. |
| Remote access stopped overnight | The workstation slept, the application stopped, the client disconnected or the tunnel stopped. | Verify local operation, client connectivity and tunnel state in that order. |
The project documentation index links Troubleshooting and Getting help for symptom-specific guidance and diagnostic reporting. For a useful report, include the installed version, Windows ZIP installation method, operation attempted, exact error and whether it reproduces locally. Redact tokens, API keys, private image names, sensitive paths and credentials. Do not upload raw logs without reviewing them.
Frequently asked questions
How do I install LDS on Windows?
Download the Windows release asset, extract it into a new folder and run start.bat. The launcher prepares a compatible Python environment. Complete core Setup, then install optional features through Plugins → Store. Use the release notes for your chosen version rather than a source-code ZIP or an old branch's instructions.
Does start.bat always open a browser?
The supplied release notes confirm environment preparation, not an unconditional browser-launch guarantee. Inspect the running installation's output and configuration, then open its verified local address. Diagnose startup separately from browser launch.
What port and bind address should I use?
Use the values confirmed on your installed version. The provided extracts do not establish defaults. Test the exact target IP and port from the Localtonet client device. A browser URL identifies a reachable endpoint but does not reveal every interface on which the server listens.
Can I publish LDS without a login if the URL is random?
No. A random URL is not an authorization boundary. Establish supported access protection and verify that a clean private session cannot view datasets, fetch protected media or perform actions. If that test fails, stop the tunnel and keep the studio local until protection works.
Do dataset organisation and AI training have the same prerequisites?
No. The release notes say importing and organising datasets does not require a plugin. Automated captioning, generation and training depend on the selected tools, models and resources. Verify those requirements separately instead of treating a working web interface as proof that training is ready.
Will updating the Windows ZIP installation preserve my work?
The referenced V2 release says Settings → Maintenance → Update & restart preserves data and local configuration, including datasets, media and history. Plugins update separately through the Store. Make and test a backup anyway, including external data locations that your chosen backup procedure does not cover.
Can I use LDS commercially?
The referenced release uses the PolyForm Noncommercial license for the core and free public plugins. Review the applicable terms and obtain any necessary permission before commercial use. Free availability does not mean unrestricted commercial rights.
Connect a verified, protected workspace with Localtonet
Once LDS works locally and its access controls pass a clean-session test, connect the workstation to our platform and configure an HTTP tunnel. Verify a small remote workflow, keep device tokens private and stop the tunnel when your session is finished.
Get Started Free →
