Applio: a Gradio voice conversion stack built on RVC, and what it costs to run

The gap Applio fills between RVC research code and a usable interface

RVC voice conversion code exists in several forks, and most of them assume you are comfortable editing Python, managing checkpoints by hand and reading a terminal. Applio's stated purpose is narrower than that: a simple, high-quality voice conversion tool, focused on ease of use and performance. The audience is artists, developers and researchers who want speech-to-speech conversion without assembling a training pipeline first.

The practical difference shows up in the repository layout. There is a run-install script per platform, a run-applio script per platform, a run-tensorboard script per platform, and a tabs directory that holds the Gradio interface code. Someone who has never trained a voice model can install, launch a browser UI and start converting a sample. That is the product. If you already have a training harness you like, Applio's value drops sharply, because the underlying conversion approach is RVC, not something Applio invented.

How the conversion pipeline is put together

The entry point is app.py, which launches the Gradio interface. The Makefile shows the intended invocation: python app.py --share. core.py is the second entry point, and the Makefile uses it for TensorBoard, which tells you training and monitoring run through the same core module rather than through the UI process.

Dependencies in requirements.txt describe the actual pipeline. torch and torchaudio handle inference and training. torchcrepe and torchfcpe provide pitch extraction. faiss-cpu handles the retrieval step that RVC uses to match features against an index. librosa, scipy, soundfile, soxr and noisereduce cover audio loading, resampling and cleanup, and pedalboard and stftpitchshift handle effects and pitch shifting. gradio serves the interface, edge-tts is present for text-to-speech, and tensorboard plus matplotlib cover training visibility.

So the data flow is: audio in, pitch and feature extraction, retrieval against an index, conversion through the trained model, then audio out. Plugins and configuration files are the extension points the introduction mentions, and the repository points to a separate Applio-Plugins repository for that. The README does not document the plugin API in detail, so treat plugin development as something you would learn from the plugins repository rather than from this one.

Installing Applio and converting your first clip

The README gives platform scripts rather than a pip command. On Windows you double-click run-install.bat. On Linux or macOS you execute the shell script. The Makefile shows what the install target does underneath, which is useful if you want to run the steps yourself inside a virtual environment.

make run-install

That target installs build-essential, python3-dev and ffmpeg through apt, upgrades setuptools and wheel, pins pip to 24.1, then installs requirements.txt. It is written for Debian-style systems; on macOS the apt-get lines will fail, which is why the README points macOS users at run-install.sh instead.

After installation, launch the interface:

make run-applio

This runs python app.py --share. The README states that starting Applio launches the Gradio interface in your default browser. The --share flag in the Makefile is the Gradio share option, which exposes the interface through a public URL; if you do not want that, run the script without it. Expect the first launch to be slow while models load, and expect the training tab to be the resource-heavy part, not conversion.

There is also a container path. The Dockerfile builds from python:3.12-trixie, installs ffmpeg and libportaudio2, creates a virtual environment at /app/.venv, installs torch 2.7.1 and torchaudio 2.7.1 from the CUDA 12.8 wheel index, then installs requirements.txt. It exposes port 6969 and runs app.py with --server-name 0.0.0.0 --port 6969.

services:
  applio:
    build:
      context: ./
      dockerfile: Dockerfile
    ports:
      - "6969"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

That compose file reserves one NVIDIA GPU. Note the version key in the compose file is '1', which is an old Compose file format; modern Docker Compose may warn or reject it, so be ready to adjust that line before building. Also note that the Dockerfile pins torch 2.7.1 while requirements.txt pins torch 2.11.0. The Dockerfile installs torch first from the CUDA wheel index and then installs requirements.txt, so the requirements pin can override the CUDA build. That is a real inconsistency to check before you rely on GPU acceleration inside the container.

Where Applio stops being the right tool

The README carries an explicit note: Applio will no longer receive frequent updates, with future work focused 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 last push was on 2026-09-14, so the repository is not abandoned, but the maintainers have told you the direction of travel. If your adoption plan assumes a steady stream of new capabilities, that plan is wrong.

There is a second boundary that matters more in practice. Applio is a conversion tool, not a consent or rights management system. The README states that users must respect copyrights, intellectual property and privacy rights, and that all audio generated with Applio must comply with applicable copyright laws. Nothing in the repository enforces that. If your workflow requires provenance tracking or voice-consent records, you build them yourself.

Hardware is the third constraint. The compose file reserves an NVIDIA GPU, and the Dockerfile installs CUDA wheels. CPU-only conversion is possible in principle because faiss-cpu is in the dependency list, but the README makes no performance claim for CPU inference, and training a model on CPU is not something the documentation presents as a normal path. If you have no GPU, treat training as out of scope.

Applio compared with using RVC directly

The most common comparison is Applio against RVC itself, and the difference is packaging rather than algorithm. RVC is the voice conversion method; Applio is a distribution of it with a Gradio interface, cross-platform install scripts, a Dockerfile and a plugin repository. Choosing raw RVC means you assemble the environment, wire up the interface if you want one, and manage checkpoints and indexes yourself. Choosing Applio means you accept its dependency pins, its interface design and its slower release cadence in exchange for not doing that work.

That trade is worth naming honestly. Applio's requirements.txt pins exact versions across roughly two dozen packages, including a specific torch and gradio release. That pinning is what makes the install scripts reproducible, and it is also what makes dependency drift painful: if a security advisory lands in a pinned package, you are waiting on the project or patching your own fork. A team with a strong Python platform practice may prefer to own that surface directly. A team that wants to convert audio this week should not.

Licence, commercial use and upgrade cost

The source code and model weights in the repository are under the MIT license, which permits modification, redistribution and commercial use. That is the permissive part, and it is the part most engineers check first.

The README adds a second layer: if you use the official version as provided, without significant modification, you must also comply with TERMS_OF_USE.md. The README recommends contacting support@applio.org for commercial use to confirm alignment with ethical standards. This is not a licence restriction on the code, but it is a stated expectation attached to the official distribution. Whether that layer binds you depends on your counsel's reading, and this article is not legal advice. The concrete step is to read TERMS_OF_USE.md before shipping anything commercial, and to keep a record of whether you are running the official version or a modified fork.

Upgrade cost is low by design and low by necessity. Releases are infrequent: 3.6.2 in March 2026, 3.6.3 in June 2026, 3.6.4 in July 2026. The project's own note says future work is security patches and dependency updates. For a pinned environment that is roughly the right cadence, but it also means a breaking dependency change upstream may sit unresolved. If you deploy via Docker, your upgrade path is rebuilding the image and re-testing conversion output, because the torch version in the Dockerfile and the one in requirements.txt do not currently agree.

Editorial conclusion

Adopt Applio if you want a working Gradio front end over RVC and can live with a project that says it will no longer receive frequent updates. Do not adopt it if you need a supported commercial product with a maintenance contract, or if you cannot supply your own consented voice data and clean reference audio. Before committing, verify three things: that run-install.sh completes on your target machine, that your GPU matches the CUDA build the Dockerfile pins, and that your intended use fits both the MIT license and the repository's TERMS_OF_USE.md.

Frequently asked questions

Official sources

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