Akegarasu/lora-scripts: a GUI wrapper for kohya-ss sd-scripts

What SD-Trainer actually wraps

The README describes the project as "LoRA & Dreambooth training GUI & scripts preset & one key training environment for kohya-ss/sd-scripts". That sentence is the whole design. Akegarasu/lora-scripts does not implement the training loop. It clones kohya-ss/sd-scripts as a git submodule, pins its own dependency set in requirements.txt, and adds a Gradio interface plus a folder of preset TOML files under config/. The target user is someone who wants to train a LoRA or a Dreambooth model on their own images and does not want to assemble the kohya environment by hand. If you already run kohya-ss directly and are happy editing its command line, this project adds a layer you will spend time reading past. If you have never trained a diffusion adapter and want a form with fields, it removes the first afternoon of setup work. The distinction matters because every bug you hit is either in the wrapper or in the submodule, and the README does not tell you which is which.

How the GUI, the submodule and the TOML presets fit together

The data flow is: gui.py starts a Gradio server, the browser posts a training configuration, the server renders that configuration into arguments for the sd-scripts trainer inside the submodule, and the trainer writes checkpoints to output/ while TensorBoard reads logs from logs/. The GUI is not a separate trainer. It is a form that emits command-line arguments. The TOML presets in config/ are the same arguments in file form, which is why train_by_toml.ps1 and train_by_toml.sh exist alongside train.ps1 and train.sh. The WebUI bundles three panels the README names explicitly: TensorBoard, a WD 1.4 Tagger for auto-captioning, and a Tag Editor. Those are the parts that justify the wrapper: captioning a few hundred images by hand is the tedious half of LoRA training, and the tagger runs inside the same process. The submodule boundary is the thing to understand. requirements.txt pins accelerate, transformers, diffusers[torch], pytorch-lightning, safetensors, lycoris-lora and others, but the sd-scripts tree carries its own requirements.txt, and the Dockerfile installs both. Two dependency sets, one environment. When versions disagree, the failure surfaces in the submodule, not in the wrapper's code.

Installing lora-scripts and starting the WebUI on port 28000

The README lists Python 3.10 and Git as required dependencies. Clone with submodules, because a plain clone leaves the trainer directory empty:

git clone --recurse-submodules https://github.com/Akegarasu/lora-scripts

On Windows, install.ps1 creates a virtual environment and installs the dependencies. The README points readers in mainland China to install-cn.ps1 instead. On Linux, install.bash does the same job. Then start the GUI:

bash run_gui.sh

The README states the program opens http://127.0.0.1:28000 automatically. On Windows the equivalent is run_gui.ps1. The server binds to 127.0.0.1 by default, and the argument table lists --host, --port (default 28000), --listen, --disable-tensorboard, --disable-tageditor, --tensorboard-host (default 127.0.0.1) and --tensorboard-port (default 6006). A container path exists too:

FROM nvcr.io/nvidia/pytorch:24.07-py3
EXPOSE 28000
CMD ["python", "gui.py", "--listen"]

The Dockerfile clones with --recurse-submodules, installs xformers==0.0.27.post2 with --no-deps, then installs requirements.txt in the root and again in scripts/. The container starts the GUI with --listen, which is what makes the port reachable from outside. If you prefer the legacy path, train.sh will not activate the venv for you; the README says to run source venv/bin/activate first, edit train.sh, and run it. TensorBoard comes up separately at http://localhost:6006/ via tensorboard.ps1.

Where the wrapper gets in your way

The first limitation is the submodule. Nothing in the README documents how to update kohya-ss/sd-scripts independently of the wrapper, or what breaks when you do. If a new base model needs trainer support the pinned submodule does not have, you are editing a submodule whose own documentation lives in another repository. The second is that the WebUI is the documented interface and the command line is not. The argument table covers server flags (--host, --port, --listen, --localization, --dev) and toggles for TensorBoard and the tag editor. It does not enumerate the training hyperparameters you set in the form. Those live in the preset TOML files and in sd-scripts. So a reader looking for a stable, documented config schema will not find one here. The third is dependency weight. requirements.txt pins exact versions across torch-adjacent packages, including numpy==1.26.4 and gradio==3.44.2, and the Dockerfile layers xformers on top. On a machine with an existing CUDA setup, that pinning is either a feature or a conflict, and the README does not discuss which. Finally, the README does not document rollback, checkpoint resumption, or what a failed run leaves in output/. If you need those guarantees in writing, this is the wrong layer to depend on.

kohya-ss sd-scripts without the wrapper

The real alternative is the upstream project itself, kohya-ss/sd-scripts. The difference is not capability, since lora-scripts runs that trainer. The difference is who owns the interface. Upstream gives you a documented command-line tool and its own configuration files; you build the environment, you pass the arguments, you read the errors. lora-scripts gives you install.ps1 or install.bash, a Gradio form, a tagger panel and preset TOML files in config/. Choosing upstream means more setup time and fewer moving parts, and every error message points at the trainer rather than at a wrapper that rendered your form into arguments. Choosing lora-scripts means the tagger, the tag editor and TensorBoard arrive in one process on port 28000, which shortens the path from a folder of images to a first checkpoint. A second option visible in the repository layout is the notebook path: train.ipynb and run.ipynb exist at the top level for users who would rather work in Jupyter than in the WebUI. The README does not describe either notebook, so treat them as present but undocumented.

Licence and the cost of staying current

The repository is AGPL-3.0. That matters if you plan to expose a modified version as a network service, because the AGPL's network clause reaches users who interact with the software over a network rather than receiving a binary. Running it locally to produce LoRA weights is the ordinary case, but the licence question about the weights themselves is separate and this repository does not answer it. On maintenance: the last push was on 2026-08-21 and the repository is not archived. The most recent release listed is v1.10.0 from 2024-10-05, with v1.9.0 before it in 2024-08-31. So the code moves between releases, and the release notes are the only place a version-to-version change would be recorded. Upgrade cost is dominated by the pinned dependency set. requirements.txt names exact versions for accelerate, transformers, diffusers[torch], pytorch-lightning, safetensors, bitsandbytes and lycoris-lora, and the Dockerfile adds xformers==0.0.27.post2. Moving to a newer torch build means re-resolving that set, and the README does not describe a supported upgrade path. Budget for a fresh virtual environment rather than an in-place upgrade.

Editorial conclusion

Adopt it if you want kohya-ss's trainer behind a browser UI on a single machine and you are comfortable reading the sd-scripts submodule when the defaults do not fit. Do not adopt it if you need a documented CLI contract, a stable config schema across releases, or a maintainer-guaranteed upgrade path; the README does not cover migration between versions. Before committing to a training run, verify the submodule actually cloned, that the environment installs on your Python 3.10 interpreter, and that the preset TOML in config/ matches the arguments your GPU can afford.

Frequently asked questions

Official sources

1. Akegarasu/lora-scripts on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases