Audion plays a local music folder with synced lyrics and no network calls

Audion treats the music folder as the source of truth

Audion is a desktop music player for a local library. The pitch in the README is that it brings the Spotify experience to a local collection with no internet required and no tracking, and the four listed highlights are synced lyrics with karaoke style word highlighting, an extensible plugin system, a customizable interface, and full offline operation. That last point is the design constraint that shapes everything else. There is no account to create, no catalogue to sync against, and no server that has to be reachable for playback to work. The library is a folder on your machine, and the README describes the first run as clicking Add Music Folder, selecting a music directory and waiting for the scan to finish. The interface borrows the familiar streaming look, with a home page, a library view, a fullscreen mode and a theme selection screen, so the visual grammar is the one people already know while the data stays local.

A Svelte front end sits inside a Tauri shell

The stack is visible in the repository layout and in package.json. The front end is Svelte 5 on SvelteKit with Vite 6 as the build tool, and it is compiled to static output through @sveltejs/adapter-static. The desktop shell is Tauri 2, with the Rust side living in src-tauri/ and the Svelte code in src/, which is why the primary language of the repository is listed as Svelte while the topic tags mention rust. The npm scripts show the split clearly: `vite dev` for development, `vite build` for the front end, a `tauri` script for the shell, a `check` script that runs svelte-kit sync with svelte-check against tsconfig.json, and a Windows-specific bundling script using @choochmeque/tauri-windows-bundle. Several Tauri plugins are pulled in as dev dependencies, covering file system access, dialogs, notifications, global shortcuts, deep links, the OS API and an opener. Runtime dependencies are lighter and more telling: dashjs for playback, dompurify for sanitising content, marked for markdown, lucide-svelte for icons and svelte-i18n for translations.

Five prebuilt artifacts and a community package

Installation is a download rather than a build. The Releases page carries a Windows installer named Audion_x64-setup.exe, a macOS disk image Audion.dmg, a Linux AppImage named Audion-x86_64.AppImage, a Flatpak named audion_<version>_linux.flatpak, and an Android APK named Audion.apk. There is also an Arch User Repository package, audion-bin, which the README marks as community maintained and auto-updating. On an Arch based system the install is one command through whichever AUR helper you prefer:

# Using yay
yay -S audion-bin

# Using paru
paru -S audion-bin

The naming is worth pausing on, because a version in a Flatpak filename and a version in the Arch package are two release trains to track rather than one, and the README offers the platform specific release asset as the alternative when you would rather not use an AUR helper at all. There is no iOS or iPadOS artifact in the list, which is the one platform gap a reader with an Apple mobile device will notice immediately.

The plugin system runs through scripts in the repository

Extensibility is the second headline feature, and the repository shows how it is wired. PLUGINS.md sits at the root as the plugin documentation, plugin-examples/ holds sample plugins, and scripts/ contains the tooling that keeps the plugin set consistent with the application. The npm scripts define sync-plugins as a node script run against scripts/sync-plugins.js, and a separate check-icons script run against scripts/check-icons.js that appears to guard icon assets. There is also a developerguide.md for contributors and releasenote.md for release notes. Two things follow from this layout. First, plugins are code that runs inside your desktop application, so they carry the same trust implications as any other extension, and PLUGINS.md is the place to look before installing one. Second, the plugin directory is synchronised by a script rather than hand-copied, which means plugin authoring has a defined workflow, and the plugin-examples directory gives you a starting shape instead of a blank page.

audion-server-docker turns the player into a streaming client

Audion also ships a self-hosted server, audion-server-docker, written in Rust with a responsive Svelte front end, so a library can sit on a home server or a VPS and stream to Audion clients anywhere. The repository ships a preconfigured docker-compose.yml in that directory, and the README tells you to check the configuration before starting it:

   services:
     audion-server:
       build:
         context: .
         dockerfile: Dockerfile
       ports:
         - "8080:8080"
       volumes:
         - ./data:/data
       environment:
         - AUDION_ADMIN_USER=admin
         - AUDION_ADMIN_PASSWORD=securepasswordhere # Change this!
         - AUDION_JWT_SECRET=your-secret-key-here
         - AUDION_DATA_DIR=/data

The compose file builds from a local Dockerfile, maps port 8080, mounts a ./data directory and takes four environment variables, two of which are credentials the README expects you to change. Starting it is a single command from inside that directory:

   cd audion-server-docker
   docker compose up --build -d

The web interface is reachable at http://localhost, with port 8080 also giving direct backend API access, and it is where files, playlists and users are managed. On the client side, connection is configured in settings under Server Connection by choosing Custom Server and entering the server URL and credentials, after which streaming playback, library sync and remote access are available.

The offline promise and the server mode pull in opposite directions

The clearest tension in the project is that the same application is both a fully offline player and a streaming client for a server you expose to a network. The offline mode needs nothing but a folder, and it makes no network calls. The server mode needs an admin password, a JWT secret, an exposed port and a reachable host, which is a different security posture entirely and belongs on a network you control rather than the open internet. The README is honest about the mechanics of the compose file, since it ships an example password with a Change this comment and an example JWT secret, but it does not describe a reverse proxy, TLS termination or a firewall setup, and those deployment decisions are left to you. The other edges are smaller but real. The repository licence listing is unresolved even though package.json declares MIT, and the AUR package is community maintained rather than built from the release pipeline. The plugin model is another: an extensible plugin system in a music player means third-party code with access to the app, and PLUGINS.md is the only guide to what the project expects of a plugin.

Release tags and a repository that moves every week

The maintenance picture is healthy in the narrow sense that the project is not archived and the last push was on 2026-10-14. The release history is compressed: v1.4.0 was tagged on 2026-09-14, a v1.4.1-beta on 2026-09-19, and v1.4.1 on 2026-09-28, with package.json already reporting version 1.4.1. A beta tag sitting next to the stable one means you can end up on a pre-release build without meaning to, so check which tag you downloaded. The code layout is what you would expect from a project of this size rather than a weekend script: src/ for the Svelte application, src-tauri/ for the Rust shell, static/ for assets, packaging/ for the installers, scripts/ for the plugin and icon tooling, plus svelte.config.js, vite.config.js and tsconfig.json. Development is driven by npm scripts, and the check script runs svelte-kit sync followed by svelte-check, which is the gate to run before opening a pull request. The package manifest declares the project as an ES module, names the license MIT, and pins the toolchain to Svelte 5, Vite 6 and TypeScript around 5.6, so a contributor needs a Node toolchain and a Rust toolchain for the Tauri shell rather than a single language setup.

Editorial conclusion

Adopt Audion if your music already sits on a disk and you want a player that stays offline, with word-synced lyrics and a plugin system you can extend. Skip it if you need an iOS build, a packaged Linux distribution, or a project whose licence you can read without hedging, because package.json declares MIT while the repository licence listing is unresolved. Before installing, read PLUGINS.md and confirm that the plugin you rely on is one the project intends to keep, since plugin code is JavaScript that runs inside the app.

Frequently asked questions

Official sources

1. dupitydumb/Audion on GitHub
2. Issues
3. Project website
4. README
5. Releases