Applio's Dockerfile pins torch 2.7.1 and then requirements.txt installs 2.11.0

MIT covers the weights, the official build adds the terms of use

The licensing section is longer than the licence requires, and the reason is a split.

The first half is permissive and explicit: the source code and the model weights in this repository are licensed under MIT, allowing modification, redistribution and commercial use.

The second half narrows it. If you choose to use this official version of Applio, described as the version provided in this repository without significant modification, you must also comply with the project's Terms of Use, which are said to apply to their integrations, configurations and default project behaviour.

So the licence you get depends on which artefact you took. Modify the project and MIT is the whole story. Run the official build as shipped and there is a second document attached to it, and a `TERMS_OF_USE.md` file sits at the repository root next to the `LICENSE` file.

The rest of that section is the part a commercial user has to notice. Commercial usage is permitted provided users adhere to legal and ethical guidelines, secure appropriate rights and permissions, and comply with the MIT licence. For commercial use the document recommends contacting the project by email, and it states that all audio generated must comply with applicable copyright laws and that Applio and its contributors are not liable for misuse.

Feature work has stopped while dependency updates continue

A note near the top of the document is the clearest statement of where the project is.

Applio will no longer receive frequent updates, and development will go forward mainly on security patches, dependency updates and occasional feature improvements. The stated reason is that the project is already stable and mature with limited room for further improvements.

The dates support that reading without contradicting it. The recent releases are 3.6.5 on 2026-09-19, 3.6.4 on 2026-07-27 and 3.6.3 on 2026-06-28, so roughly six-week gaps between feature releases, while the last commit on the default branch is dated 2026-10-04, a day before this writing.

That combination is the interesting part: the branch tip is a week ahead of the newest tag, and the note says the next commits are dependency and security work. Anyone planning a deployment is looking at a project that is being kept alive rather than extended.

The repository is not archived, and there are two documentation destinations, the project site and a separate documentation site, so the material a user needs is not all in the repository.

The container installs one PyTorch version and immediately replaces it

The container file is where the dependency story turns into a concrete bug.

It builds from a Python 3.12 image on the trixie base, exposes port 6969, sets the working directory to `/app`, installs ffmpeg and the PortAudio library through apt, copies the whole repository in, and creates a virtual environment at `/app/.venv`.

Then it installs the deep learning stack explicitly:

pip install --no-cache-dir torch==2.7.1 torchvision torchaudio==2.7.1 --index-url https://download.pytorch.org/whl/cu128

and immediately afterwards, on the next line, installs `requirements.txt` if that file is present. And `requirements.txt` asks for `torch==2.11.0` and `torchaudio==2.11.0`.

So the pinned 2.7.1 build, fetched from the CUDA 12.8 wheel index, is downloaded and then replaced by whatever the requirements file resolves. The explicit pin does no work.

The rest of the image is careful: the apt lists are cleaned, pip runs with no cache, the virtual environment's bin directory is put on `PATH`, logs are declared as a volume, and the entrypoint runs `app.py` bound to `0.0.0.0` on port 6969.

make help prints an empty list

The Makefile is short and has three targets, and the first one does not work.

help:
	@grep -hE '^[A-Za-z0-9_ \-]*?:.*##.*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'

That target greps the Makefile for lines that end in a help comment after a colon. The three targets that exist, `run-install`, `run-applio` and `run-tensorboard`, carry no such comment, so the pipeline matches nothing and `make help` prints nothing at all.

The declaration line above it is also empty. `.PHONY:` is written with no prerequisites, so none of the four targets is actually marked phony. A directory containing a file named `run-install` would stop make from running the recipe.

The install target itself installs build tools and ffmpeg with apt-get, upgrades setuptools and wheel, pins pip itself to 24.1, installs the requirements, and then runs `apt-get update` at the end rather than before the installs. It also runs without sudo, so it assumes a root shell, which is a difference from the shell script the README tells users to run.

The Makefile runs the app with a public share link

One line in the Makefile is a privacy decision rather than a build detail:

run-applio:
	python app.py --share

The `--share` flag asks the Gradio framework to create a public tunnel and print a shareable URL. Anything reachable through that URL is reachable by anyone who has it, which for an application that uploads audio and writes files into a `logs/` directory is worth knowing before you run the target on a laptop connected to a conference network.

The container does the same thing by a different route. Its command is `app.py --server-name 0.0.0.0 --port 6969`, which binds every interface rather than loopback, and the compose file publishes the service with a single port entry and no host mapping, so the host port is assigned at run time.

The compose file also reserves a GPU: the service declares a device reservation with the nvidia driver, a count of one and the gpu capability. That means the documented container path needs the NVIDIA container runtime and a GPU present, which is a different requirement from the local shell scripts the README leads with.

A second image definition sits beside the one the compose file uses. `Dockerfile_cuda` is in the repository, and the compose file names `dockerfile: Dockerfile`, so the CUDA variant is available to build by hand and is not what the one-command path uses.

A CPU vector index and a GPU runtime are pinned side by side

The requirements file is about thirty packages, every one of them pinned to an exact version with no ranges.

Two of the pins deserve attention together. `faiss-cpu==1.14.3` is the CPU build of the vector search library, while `onnxruntime-gpu==1.26.0` is the GPU build of the ONNX inference runtime. They are different distributions so nothing conflicts at install time, but the result is an environment carrying a CPU vector index and a GPU inference runtime at the same time, on a machine that may have no GPU at all.

The rest of the stack is recent. `torch==2.11.0` and `torchaudio==2.11.0`, `transformers==5.13.1`, `gradio==6.20.0`, `numpy==2.4.6`, `scipy==1.18.0`, `librosa==0.11.0` and `soundfile==0.14.0` are all current majors, and the audio processing set is broad: `noisereduce`, `pedalboard`, `stftpitchshift`, `soxr`, `torchcrepe`, `torchfcpe` and `swift-f0` cover pitch shifting, resampling and pitch detection.

There are also two network-facing packages for the interface rather than the model, `edge-tts` for speech synthesis and `webrtcvad-wheels` for voice activity detection, plus `pypresence`, `sounddevice`, `psutil`, `matplotlib` and `tensorboard`.

With exact pins everywhere, the only way to move any of them is to edit the file, which is consistent with a project that describes its remaining work as dependency updates.

Distribution runs through scripts, a Colab notebook and a weights repository

There are four ways to get hold of Applio, and they are not equivalent.

The documented local path is a pair of scripts per platform. On Windows you double-click `run-install.bat` and then `run-applio.bat`, with `run-tensorboard.bat` optional for monitoring. On Linux and macOS the same three exist as shell scripts. The result is a Gradio interface in the default browser.

The container path is the `Dockerfile` plus `docker-compose.yaml` described above, and a `Makefile` that duplicates the install and run targets for people who prefer make.

Then there are two Google Colab notebooks under `assets/`, one with the interface and one without, which run the project without a local install at all.

And the model weights live in a separate Hugging Face repository under the same owner's name, in a Compiled directory, with plugins in their own repository. Two projects are credited as references: a Gradio screen recorder component and `rvc-cli`, which is the command line tool from the RVC line of work this project builds on.

One housekeeping detail sits in the tree: a `logs/` directory is committed at the root, and the container image declares that same path as a volume.

Editorial conclusion

Applio fits someone who wants a local, no-code interface for voice conversion with their own recordings and their own permissions, since the install is two double-clicks and the interface opens in a browser. Three things to settle first. Read the terms rather than the licence alone, because MIT covers the source and the weights while using the official unmodified build also binds you to the project's Terms of Use, and the document asks commercial users to make contact before deploying. Check what you are running, since the container image installs one PyTorch version and then replaces it with the one in the requirements file, and the CPU and GPU builds of the vector and inference libraries are pinned side by side. And be clear about whose voice you are converting: the project's own terms require you to secure rights and permissions, and generated audio has to comply with copyright law, so a voice you do not own is not a research question.

Frequently asked questions

Official sources

1. IAHispano/Applio on GitHub
2. License: MIT
3. Project website
4. README
5. Releases