Bakabase: a local media library manager built around custom attributes and card entities

What it manages, and the attribute model behind it

Bakabase is a local media manager for all types of files, and the documentation describes it as a tool for managing local media, animation, comics, audio, doujinshi, films and photo collections, organised by attributes you define yourself, with metadata fetched automatically and full resource and file operation support.

The attribute model is the core idea. Rather than imposing a fixed schema for a film or a comic, the library lets you define what a resource is, and then everything else follows from that. That is what makes a single application able to hold anime, manga, voice recordings, novels, games and modification packs, which is the stated range of the project, along with integrations for Steam, DLsite and ExHentai and for Bilibili video.

On top of the attributes sit data cards. An entity such as an actor, an author, a brand, an IP or a character is abstracted into a card, and each card has its own properties, such as name, nationality and representative works, and is linked to resources automatically through attribute values you specify. The mechanics are described precisely. You choose a set of matching properties on the card type, and a resource is associated with the card when its values on those properties match, with support for matching any or matching all. External data arriving from enhancers or synchronisation is matched against existing cards by an identifier property you choose, and a miss can create a new card. You can also scan the values already present across your resources and generate the matching card set in one action.

The reverse direction works too. Opening a search from a card filters the resource list by that card's matching properties, and the resource detail panel lists every card associated with it. That is a small feature with a large consequence, because it turns the library from a list of files into something you can navigate by entity.

The resource detail panel is also laid out by you. There are eleven built-in blocks, covering the cover, rating, actions, basic information, hierarchy, description, play time, attributes, associated data cards, owning media library and owning profile, each of which can be shown or hidden, and the panel is arranged on a grid of four, six, eight or twelve columns where blocks can be dragged, resized across columns and rows, with a custom gap, and a dialog that adjusts the panel size between 50 and 95 percent of the viewport with a live preview. Hiding a block keeps its position and size so it can be restored, and a one-click reset returns to the default layout.

Installing the desktop build, and the upgrade gap at 2.3

Two release channels are published, and the documentation is clear about which is which. The stable release is linked from the releases latest page and is suitable for daily use. The test release is on the releases page, and you pick the one tagged 2.4.0-beta to try the features described as in development, with the warning that the test version's features and data structures may still be adjusted and that you should keep a complete data backup before upgrading.

The desktop all-in-one build contains the local server and the desktop window, and it can also manage other servers that have been paired with it. The platform matrix is specific: a Windows x64 setup executable or a portable zip that you update by replacing the program files by hand, a macOS package for Apple Silicon, and a macOS package for Intel. Linux and NAS users are pointed at the Docker server instead.

The install note is worth reading because it prevents a common mistake: do not treat the .nupkg update package or the GitHub Source code archive as an installer. On first launch of a 2.4 beta you get an initialisation wizard where you choose the data directory, and you can create empty data or import from another Bakabase instance that is stopped. The original media files are not copied automatically with the application data, and existing users keep their data directory after upgrading.

Updating the installed version is done from inside the application, under System, then Configuration, then System Information, then Current Version, where you click Check for updates. There is a separate switch to receive 2.4 beta updates, and turning it off means only stable versions are checked, without downgrading existing data. When an update is available you download it from the page, and if the download has already started you wait for an update ready message and then click restart to update, which keeps the data directory, workspaces, device pairings and path mappings and replaces only the program files. The portable build and a source run do not support the installer update and have to be updated by hand.

The 2.3 boundary is the sharp edge. Version 2.3 changed the installer, so the old updater cannot jump across it, and you have to download the installer and do a fresh install once. The documentation tells you to back up the old data completely, exit the old program, and either pick the import existing data option in the first-run wizard or use the import path under System, Configuration, Workspace, then the current workspace's data directory. It also warns not to keep your data inside the program installation directory and not to let two instances share one data directory that is being written to.

The Docker server for a NAS, and the mounts that decide everything

The Docker build contains the server and the web interface and is aimed at a NAS or an always-on device. The documentation follows the 2.4 beta, provides Linux AMD64 and ARM64 images, notes that Apple Silicon can use the ARM64 image directly, and makes one point that catches people out: the image tags have explicit version numbers and there is no latest tag, so you must name a published version.

The deployment uses the Compose scripts in the repository and needs Docker Compose, Git, Bash and Python 3, and on Windows it can be run in WSL. The steps are:

git clone https://github.com/anobaka/Bakabase.git
cd Bakabase
cp docker/.env.example docker/.env

Then you configure the storage location and the mounts before starting, and the documentation is emphatic that a container cannot reach every directory on the machine or on the NAS by itself. There are three mounts to think about, the application data holding the database, settings, covers and device connections, which is required, and two optional ones for media files and for downloads.

The environment file takes the image and the host data directory:

BAKABASE_IMAGE=anobaka/bakabase:<版本号>
BAKABASE_DATA_DIR=/absolute/path/to/bakabase-data

And the compose file declares the bind mounts, with the source being an absolute path that already exists on the host and the target being the path inside Bakabase:

services:
  server:
    volumes:
      - type: bind
        source: /absolute/path/to/media
        target: /media
        bind:
          create_host_path: false
      - type: bind
        source: /absolute/path/to/downloads
        target: /downloads
        bind:
          create_host_path: false

The create_host_path: false setting is a small but important detail, because it makes Docker fail rather than silently create a directory where you meant a mount to be.

The commands that follow are run through a wrapper script, which is worth noting because it keeps the compose invocation consistent:

./docker/image.sh pull
./docker/image.sh up -d --no-build
./docker/image.sh logs -f server

On first start the log contains a Server setup line with a full link, and you complete the setup with that link, keeping the token in it, and afterwards the panel is at http://localhost:34567, reachable from the local machine only by default.

Upgrading the container, and the rule about not copying a live database

The upgrade path for Docker is documented with a warning that is worth repeating, because getting it wrong loses data.

The check for updates inside the web interface does not replace the image. The documented sequence is to stop the service properly first, back up the complete host application data directory, and keep that backup outside the directory itself, and the reason given is that you should not copy the SQLite file while the service is running.

The stop command is:

./docker/image.sh stop server

After the backup, you keep the rest of your .env settings, all the mounts and the data directory, change only the BAKABASE_IMAGE value to the target version, and then:

./docker/image.sh pull
./docker/image.sh up -d --no-build --force-recreate

The force-recreate flag is the important one. The documentation says separately that when you add or change a mount you must run the same command with --force-recreate to rebuild the container, and that a plain restart will not apply new mounts. That is a Docker behaviour rather than a Bakabase quirk, but it is the kind of thing that produces a support question.

After the upgrade you check the version, the media libraries and the directory access in the interface. The documentation also warns not to use down -v to clean up an old service, because that removes data held in named volumes.

For people who want to verify a change from source, the repository supports a local build in the same deployment. Set BAKABASE_IMAGE to bakabase:local in the .env, run git submodule update --init --recursive and then ./docker/source.sh, which builds and starts inside Docker. Switching back to the official image means changing BAKABASE_IMAGE back to the release tag and running the image update commands. Both modes share the same project, the same server service and the same local configuration, and can be swapped without running a second set of containers.

What is in the 2.4 beta, and what the project is really for

The features listed as in development and verification for 2.4.0-beta are substantial, and they describe where the project is heading.

A pure server and Docker mode, where the browser manages the library and ARM64 and AMD64 images are provided, with the source build and the published images sharing the same deployment configuration and data directory. Initialisation and workspaces, where you choose a data directory, import other instances with a pre-check and map old paths, and the desktop build supports named, mutually isolated workspaces.

Unified multi-device management, where you search, filter and manage resources from authorised devices inside the existing resource list, with device colour coding to show the source, and where metadata is synchronised to the managing side. Data synchronisation and conflict handling, covering custom attributes, options and extension groups, with a central view of devices, data types, progress and records and batch conflict handling.

Reusable resource rules, where a filter scope can be reused and rules for players and playable files configured separately, so you can assign a device that can actually reach the file to do the processing. Browser and local playback, choosing between the web and the local player according to client capability and combining path mapping with local rules to open remote resources.

And then the acquisition workflow, which is the part of the project with a specific shape. There are collections and subscriptions that track what you already have and what is missing and find new content from supported sources, and a configurable workflow that connects downloading, extraction and file placement. There is post parsing, which organises the body of a post and its download clues, combines AI with link, password and processing instruction extraction, and hands the result to the acquisition flow for review. And there is a collection memo, which records on a timeline the collected ranges, links and notes of what you are after.

The multi-device example in the documentation makes the intent concrete: films on a media NAS, animation and comics on a small server, games and music on the everyday computer, with two everyday computers paired to the server so that the resource list can be searched and managed across all of them without moving files. The documentation is careful that path mapping copies no media and creates no network mount, and that cross-device playback still depends on the file being reachable and on what the player and the executing device can do.

Where Bakabase is the wrong tool

The first limit is that it is a management tool for a large, already-local collection, not a download client or a discovery service. Its value appears after you have thousands of files that a folder tree cannot express, and it does nothing useful for somebody with a hundred files who wants a better file browser. The attribute system is also work: you have to decide what a resource is and which properties matter, and a library that ends up with a dozen half-used attributes is a worse library than a good folder tree.

The second is the beta line. The 2.4 releases are tagged 2.4.0-beta with a build number that changes several times a day, the last three being v2.4.0-beta.695, v2.4.0-beta.712 and v2.4.0-beta.716 on 2026-10-19 alone, and the last push to the repository was two days later. The documentation says the test version's features and data structures may still be adjusted and asks for a complete backup before upgrading. That is a candid warning, and it means a deployment that stores anything you would miss should sit on the stable line and treat the beta as a separate instance.

The third is the amount of configuration the Docker path asks for, and the sharp edges in it. The data directory has to exist before the container starts, the source paths have to be real absolute paths on the host, the compose file has to be written by hand, the first-run setup link has to be found in the logs, and the port binds to the local machine only until you work through the LAN access and pairing flow. None of that is difficult, but it is more than a single docker run, and each of those steps is a place where a mistake shows up as an empty library rather than an error.

The fourth is the multi-device model, which is powerful and also a security model to think about. Pairing a desktop with a server, or a MacBook with two servers, means authorising each relationship separately, and the documented example has a MacBook paired with two servers. Every pairing is a grant of access to a library, and the more devices you pair, the more places a permission has to be revoked.

And the fifth is the platform integrations, which bring the app's behaviour partly under the control of external services. Browsing and managing content from Steam, DLsite and ExHentai means depending on those sites' interfaces, and the Tampermonkey script and post parsing features mean the project is partly driven by pages you visit, with AI extraction of links, passwords and processing instructions from post bodies. That is a large amount of moving parts outside your own installation, and a user who wants a purely local library manager is using more of this project than they need.

Editorial conclusion

Bakabase is worth trying if you have a large local collection that a folder tree and a file browser have stopped handling, because the attribute model treats your own metadata as first-class and lets you define what a resource is, because the card system links cross-cutting entities such as studios or characters to many resources at once, and because the Docker server build turns the same application into something a NAS can run for a whole household. It is the wrong tool if your library is small, and it is the wrong tool if you want a stable release to build on. Before you install it, check three things: whether you want the stable release or the 2.4.0 beta line, since the beta is where the pure server, the multi-device work and the collection workflows live and the documentation says its features and data structures may still change and asks for a full data backup before upgrading; that the desktop installer cannot jump the gap at 2.3, because 2.3 changed the installer and the old updater cannot cross it, so that path needs a manual install and a data import; and that the Docker image has no latest tag, so BAKABASE_IMAGE in docker/.env must name an explicit published version rather than a moving tag.

Frequently asked questions

Official sources

1. anobaka/Bakabase on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases