Libation: A Desktop Tool That Removes Audible DRM and Keeps the Files

The problem Libation solves for Audible customers

An Audible purchase is a licence tied to an account, delivered as a DRM-protected file through Audible's own apps. If the account closes, or the app drops a title, the audiobook goes with it. Libation exists for the person who has paid for a library and wants a copy that does not depend on Audible continuing to serve it.

The README states the goal plainly: it is a free, open-source application for downloading and managing your Audible audiobooks, and it "decrypts your library, removes DRM, and lets you own your audiobooks forever." That is the whole scope. It is not a player, not a store, and not a way to get audiobooks you have not bought. The intended user is someone with an existing Audible account who wants local files, cover art and tags on their own machine.

Region support is a real constraint rather than a footnote. The README lists US, UK, Canada, Germany, France, Australia, Japan, India and Spain. If your Audible account belongs to a region outside that list, the README gives no indication that the tool works for you.

How Libation downloads and decrypts: AAXClean instead of ffmpeg

The README attributes the decryption work to AAXClean, described as enabling fast decryption without heavy dependencies like ffmpeg. That single sentence carries most of the architectural weight. Audible delivers audiobooks in its AAX format, and AAXClean is the component that turns those into ordinary audio files. Because the project does not shell out to ffmpeg, a Libation install does not drag in a separate media toolchain, which matters on Windows and macOS where users would otherwise have to install one by hand.

The Dockerfile shows the shape of the non-GUI side. The build stage publishes LibationCli, a command line project under Source/LibationCli, as a self-contained Linux binary with ReadyToRun enabled. The runtime stage then copies that publish output to /libation, copies the contents of the Docker directory alongside it, symlinks /libation/LibationCli into /usr/local/bin, and sets the entrypoint to /libation/liberate.sh. So the container is a wrapper around the CLI, not around the desktop application.

The environment variables in the Dockerfile also describe how state is laid out. LIBATION_CONFIG_DIR points at /config, LIBATION_CONFIG_INTERNAL at /config-internal, LIBATION_DB_DIR at /db, and LIBATION_BOOKS_DIR at /data, with LIBATION_CREATE_DB set to true and LIBATION_DB_FILE left empty. LANG and LC_ALL are both set to C.UTF-8, and the comment above them says this is the character set used for folder and filenames when liberating. Anyone who has had non-ASCII author names mangled by a tool will recognise why that line is there. SLEEP_TIME is set to -1, which the Dockerfile does not explain; the behaviour behind that value is not documented in the repository.

Installing Libation and running the CLI in Docker

The README does not contain installation steps. It states that all documentation has moved to getlibation.com and links to a Getting Started page, and it directs readers to the Releases page for the latest build for their platform. The site's download page is the one place that recommends a build per system, so start there rather than guessing from the repository tree.

The repository does ship a Dockerfile, which is the one install path the repository describes in full. Building it produces an image whose entrypoint is /libation/liberate.sh, with the CLI symlinked at /usr/local/bin/LibationCli. The build compiles Source/LibationCli/LibationCli.csproj for Linux, so this path gives you the command line tool, not the desktop GUI.

FROM --platform=${BUILDPLATFORM} mcr.microsoft.com/dotnet/sdk:10.0 AS build
ARG TARGETARCH

COPY Source /Source
RUN dotnet publish \
    /Source/LibationCli/LibationCli.csproj \
    --os linux \
    --arch ${TARGETARCH} \
    --configuration Release \
    --output /Source/bin/Publish/Linux-chardonnay \
    -p:PublishProtocol=FileSystem \
    -p:PublishReadyToRun=true \
    -p:SelfContained=true

That is the build stage verbatim from the Dockerfile. The runtime stage declares four directories and the environment variables that point at them:

ARG USER_UID=1001
ARG USER_GID=1001

ENV LANG=C.UTF-8
ENV LC_ALL=C.UTF-8

ENV SLEEP_TIME=-1
ENV LIBATION_CONFIG_INTERNAL=/config-internal
ENV LIBATION_CONFIG_DIR=/config
ENV LIBATION_DB_DIR=/db
ENV LIBATION_DB_FILE=
ENV LIBATION_CREATE_DB=true
ENV LIBATION_BOOKS_DIR=/data

Those defaults are the paths to mount when you run the image: configuration in /config, the database in /db, and liberated audiobooks in /data. The GUI path is a separate download from the Releases page, and its steps are on getlibation.com, not here.

What Libation does not do

Libation is a desktop application. The README claims full support for Windows, macOS and Linux, and the releases are platform builds, but nothing in the README describes a mobile client, a web interface or a hosted service. If you want to listen on a phone, you are expected to move the liberated files to whatever player you already use. That is the point of the tool, but it is also the limit of it.

The documentation gap is the second limitation. The README has been reduced to a pointer: features, a link list, and a note that all documentation has moved to getlibation.com. Troubleshooting, account setup and the details of what happens when a download fails are not in the repository README. For a tool that touches a paid account and writes files to disk, that means the repository alone is not enough to evaluate it. You have to read the site.

The Dockerfile is also narrower than it first appears. It publishes LibationCli, so container users get the command line tool. There is no evidence in the repository of a containerised GUI, and running a desktop application in a container is not something the Dockerfile attempts. If your reason for wanting Docker is a headless server that periodically syncs your library, the CLI is the right target; if you wanted the graphical library browser in a container, the Dockerfile does not support that.

Finally, DRM removal on content you have licensed is legally uneven across jurisdictions. The project ships under GPL-3.0 and says nothing about the legality of using it in your country. That is a question for a lawyer, not for this article.

Libation compared with a general-purpose downloader

The obvious alternative is a generic media downloader that also handles Audible, or a script built around Audible's own command line tooling. The difference is where the work happens. A general downloader gives you a file and leaves the format problem to you: you supply ffmpeg or an equivalent, and you handle decryption yourself. Libation bundles that step into AAXClean, which the README explicitly contrasts with the ffmpeg approach.

The second difference is library management. Libation's feature list includes search, filter and tag your books, plus importing an existing library with cover art. A downloader that just fetches URLs has no concept of your library as a collection. If your goal is a one-off grab of a few titles, a simpler downloader is less machinery. If your goal is a maintained local catalogue that you can browse and re-sync, Libation's organisation features are the reason to pick it, and the Docker CLI is the reason to run it on a server.

The trade-off runs the other way too. A small script is auditable in an afternoon and has no GUI to maintain. Libation is a C# application with a desktop front end, a CLI, a Docker image and a separate documentation site, and all of that has to keep working as Audible changes its service. The release history in the repository shows v14.2.0, v14.2.1 and v14.2.2 within ten days of each other in September 2026, which suggests active release churn rather than a frozen tool.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-17, days before this writing. Releases are frequent: v14.2.0 on 2026-09-07, v14.2.1 on 2026-09-12, v14.2.2 on 2026-09-16. For a tool that depends on a third party's DRM, that cadence is the maintenance model. Audible changes something, Libation ships a patch. Anyone running it should expect to update rather than install once.

The upgrade path is a download from the Releases page, or a rebuild of the Docker image, since the Dockerfile pulls mcr.microsoft.com/dotnet/sdk:10.0 and mcr.microsoft.com/dotnet/runtime:10.0. Pinning those base images is the practical way to control when the runtime underneath you changes. Nothing in the repository describes a migration process for the database in /db across versions, so back that directory up before upgrading if your library metadata matters to you.

Libation is GPL-3.0. For someone running it at home, that is a non-issue. For someone embedding it in a product, GPL-3.0's copyleft terms apply to distribution, and the README's own framing is a personal tool. The README also asks for donations and says that as long as the maintainer keeps working on it, it will remain free and open source. That is a statement about intent, not a guarantee, and it is worth reading as such.

Editorial conclusion

Adopt Libation if you already buy audiobooks on Audible and want the files on your own disk, and if you are comfortable with a desktop GUI whose documentation lives on getlibation.com rather than in the README. Do not adopt it if you want a hosted service, a mobile listening app, or anything that works without an Audible account. Verify first that your Audible region is one of the nine the README lists, then read the Getting Started page before you download, because the README itself does not contain the setup steps.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. rmcrackan/Libation on GitHub