PixivBiu: Local Pixiv Client and Artwork Downloader

PixivBiu's local client scope and intended users

PixivBiu is a Pixiv client for browsing artwork, searching and filtering results, following users, viewing collections, and downloading images. It is aimed at users who want a local interface or a controllable server deployment rather than relying exclusively on the standard Pixiv website.

The project offers two distributions. Core contains the full frontend and backend and serves the application through a browser. Desktop packages that same Core functionality in applications for Windows, macOS, and Linux. The README states that Desktop is functionally equivalent to Core and is intended to make local use easier.

PixivBiu documents browsing of artworks, users, and rankings. It also documents favorites and followed accounts. Search filters can use favorite count, view count, tags, and type. Downloads can include single images, multiple images, original images, and animated works. The user interface language can be selected with `PIXIVBIU_APP_LANGUAGE`, which accepts `auto`, `en`, `zh-CN`, `zh-TW`, or `ja`.

The intended boundary is narrower than the feature list may initially suggest. The README describes the project as intended for personal study and research. It asks users to comply with Pixiv's Terms of Service, respect creators' copyright, and avoid commercial or infringing use, including unauthorized redistribution of downloaded works. The open-source license applies to the application, not to the images it retrieves.

How the embedded Go server serves the Pixiv interface

The repository layout shows a Go server under `cmd/` and `internal/`, with a browser frontend under `frontend/`. The build process compiles the frontend and backend into one executable. The Makefile sets the server package to `./cmd/server` and names the resulting binary `bin/pixivbiu`, with an `.exe` suffix on Windows.

The Dockerfile explains the packaging sequence. Bun builds the SPA, and Vite writes the production assets to `internal/web/dist`. The Dockerfile then copies those assets into the Go build stage, where `go:embed` includes them in the server binary. The final image copies the executable into a distroless, non-root runtime. This design means the deployed service does not need a separate frontend server after the image or executable has been built.

The server depends on `github.com/txperl/pixivgo` for its Pixiv integration. It also uses `chi` for HTTP routing, `kin-openapi` for API handling, and `koanf` with environment and file providers for configuration. The README does not document the full endpoint sequence for searches, user pages, or downloads, so the precise request mapping cannot be confirmed from the project instructions. The repository structure does confirm the main layers: a frontend interface, a Go HTTP server, Pixiv integration code, and filesystem-backed downloads.

By default, Core listens on `127.0.0.1` at port `4001`. The application is therefore local unless the host setting is changed. This default is useful for personal use because it does not directly advertise the service to other machines, but it also means users must deliberately change `PIXIVBIU_SERVER_HOST` before accessing Core from another device.

Installing Core and opening the first local session

The README's installation path for normal users is the GitHub Releases page. Download the archive for the target system, extract it, and run the `pixivbiu` executable. No package-manager command or universal installer is documented.

Start the extracted executable from a terminal:

The default browser address is:

http://127.0.0.1:4001

A first successful use is the point at which the PixivBiu interface loads from that address. The README does not document a separate registration command, login command, or mandatory setup token, so users should not expect a documented command-line onboarding sequence.

For desktop use, the README directs users to the separate Desktop releases page. The Desktop package wraps Core rather than replacing the server design. It is the simpler choice for a person who wants an application on a supported desktop system, while Core is more appropriate when the browser interface and server process need to be managed independently.

The documentation does not specify which processor architectures are supplied for each operating system. Users should check the release assets before downloading, especially when their system is based on ARM rather than x86. It also does not document a portable configuration backup or a documented upgrade command, so users should preserve the data directory before replacing a Core installation.

Docker deployment with persistent application and download volumes

Docker is the documented option when Core needs to run continuously on a server or when the application should be isolated from a desktop session. The README provides a direct `docker run` example:

docker run -d --name pixivbiu -p 4001:4001 \
  -v pixivbiu-data:/data -v "$PWD/downloads:/downloads" \
  ghcr.io/txperl/pixivbiu:latest

The `pixivbiu-data` volume is not just a generic container directory. The Compose documentation says it contains configuration, an authentication token, and the image cache. Keeping this volume is therefore important if the container is recreated. The second mount exposes downloaded files under `/downloads` on the host.

The repository includes a Compose file that uses the published `ghcr.io/txperl/pixivbiu:latest` image. Before starting it, the host downloads directory must be writable by the container's non-root user, uid 65532:

git clone https://github.com/txperl/PixivBiu.git
cd PixivBiu
mkdir -p downloads && sudo chown 65532:65532 downloads
docker compose up -d

After startup, the README and Compose file identify `http://localhost:4001` as the access address. The Compose configuration includes `restart: unless-stopped`, maps `4001:4001`, and leaves proxy and log settings in environment variables. It also provides commented configuration for building a local image instead of pulling the published one.

The permissions step is specific to a host bind mount. A named Docker volume can initialize ownership from the image, while a host directory keeps its existing host ownership. Omitting the `chown` step can therefore produce a service that starts but cannot write downloaded files.

Configuration choices that affect network exposure and downloads

PixivBiu places some settings in the application settings page and keeps operational settings in environment variables or configuration files. The README identifies the following common variables:

- `PIXIVBIU_SERVER_HOST` controls the listening address. The default is `127.0.0.1`; `0.0.0.0` listens on external interfaces. - `PIXIVBIU_SERVER_PORT` controls the listening port and defaults to `4001`. - `PIXIVBIU_LOG_LEVEL` accepts `debug`, `info`, `warn`, or `error`. - `PIXIVBIU_DOWNLOAD_UGOIRA_FORMAT` accepts `webp`, `gif`, or `none` for animated-work output. - `PIXIVBIU_APP_LANGUAGE` accepts `auto`, `en`, `zh-CN`, `zh-TW`, or `ja`. - `PIXIVBIU_PIXIV_PROXY` accepts a proxy URL in the form `scheme://host`; an empty value means direct connection.

The proxy setting is relevant for deployments where direct access to Pixiv is unavailable. The Compose example uses `http://host.docker.internal:7890` as a Docker Desktop example. Its Linux section includes a commented `extra_hosts` entry for `host.docker.internal`, because Docker's host gateway behavior differs by platform.

Changing the server host does not by itself add authentication, TLS, reverse-proxy access controls, or account separation. The README does not provide those deployment recipes. Users who set `PIXIVBIU_SERVER_HOST` to `0.0.0.0` should therefore treat the service as a separately secured network component, not as a ready-made public gateway.

For complete setting definitions, the project points to `docs/CONFIGURATION.md`. The Docker-specific instructions are in `docs/DOCKER.md`.

Source builds, embedded assets, and maintenance signals

Source builds require Go 1.26 or later, bun, and `make`. The documented build command is:

git clone https://github.com/txperl/PixivBiu.git
cd PixivBiu
make dist
./bin/pixivbiu

`make dist` builds the frontend and backend and places the frontend inside the resulting `bin/pixivbiu` binary. For local development, the README says to run `make dev` for the backend and `cd frontend && bun run dev` for the frontend. The repository therefore supports both packaged execution and a separate frontend development process.

The Go module declares `go 1.26.1` and `toolchain go1.26.6`. Those toolchain requirements can matter for contributors and for users building custom images, even though ordinary users can use the published Core or Desktop releases.

The repository is not archived. Its last push was on 2026-10-16, and recent releases include `v3.1.5` on 2026-10-05, `v3.1.4` on 2026-09-29, and `v3.1.3` on 2026-09-23. These are signs of recent project activity, but the README does not provide a compatibility matrix for Pixiv accounts, proxy configurations, operating systems, or Docker platforms. It also does not document a database migration procedure, backup schedule, or rollback command.

The MIT license permits use of the project's source under its terms, but it does not grant permission for Pixiv content. Downloaded artwork remains subject to Pixiv's Terms of Service and creator copyright. Any deployment that stores or shares those files needs a separate rights review.

Where PixivBiu is limited and when the standard Pixiv client is enough

The main limitation is the gap between a personal client and a managed multi-user service. Core can be hosted on a server, and Docker makes persistence straightforward, but the documented configuration does not describe reverse-proxy authentication, TLS termination, per-user data isolation, account rotation, or audit controls. The project should not be treated as a documented collaboration platform simply because it can be reached through a server port.

PixivBiu is also a poor fit for commercial redistribution. Its own disclaimer limits intended use to personal study and research and specifically asks users not to redistribute downloaded works. The MIT license covers the software repository, not the ownership rights of every image retrieved through it.

Using the direct Pixiv website avoids the Go server, the `pixivbiu` executable, the data volume, the download directory, proxy configuration, and the decision of whether to expose port 4001. PixivBiu adds value when the user specifically needs its search filters, browsing categories, original-image workflow, animated-format choice, or Core and Docker deployment model.

For an internet-facing install, the decision should be based on access control, data ownership, and the intended use of downloaded files. The README does not document a rollback procedure, so upgrading should be paired with retaining the existing Docker volume or a copy of the Core data directory until the new version has been checked.

Editorial conclusion

PixivBiu fits individual users who want a local or self-hosted Pixiv interface and direct control over original artwork downloads. It is a poor fit for organizations seeking documented commercial redistribution, shared multi-user governance, or compliance controls, because the README limits the project to personal study and research and does not document account isolation or rollback. Verify first that your network can reach Pixiv, that downloaded content is permitted by Pixiv's terms and creator rights, and that the host and volume permissions match the selected Core or Docker deployment.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. txperl/PixivBiu on GitHub