BiliBiliToolPro: a self-hosted task runner for bilibili accounts

What BiliBiliToolPro automates, and for whom

BiliBiliToolPro is a scheduled task runner for bilibili accounts. The README describes it as an automated task execution tool that follows pre-configured commands within specified frequencies and timeframes. In practice that means a set of named jobs that call bilibili's open APIs on your behalf: a daily task that collects the full 65 points of upgrade experience through login, watching, sharing and coin-dropping; live room idling; manga check-in and reading; live check-in; converting silver seeds into coins; claiming the five B coin coupons that come with a premium membership; claiming premium membership benefits and manga privileges; and auto-entering the lottery draws in live rooms. There is also a batch unfollow job and a cookie test job.

The audience is narrow and specific. This is not a library you import. It is an application you deploy and point at one or more accounts, and it assumes you are comfortable running a container or a panel. The README lists six deployment routes, from free online containers to Helm charts, which tells you the project expects users who already have some hosting in place. If you have never run a Docker container or a Qinglong panel, the setup path will be the hard part, not the tool.

One thing the README states plainly and that should shape your expectations: the application is for learning and testing, the author does not take responsibility for it, and users are told to delete it after testing. That is a disclaimer, not marketing, and it is worth reading as a statement about the support you should expect.

How the scheduled jobs and cookie flow actually fit together

The mechanism is API calls, not browser automation. The README says the principle behind the automatic completion of tasks is calling a series of open APIs. Each task in the table is a group of functions and is the smallest unit the tool runs; the table pairs each task code with a recommended frequency, from manual runs for Login, UnfollowBatched and Test, to once a day for most jobs, to zero to four times a day for LiveLottery.

The scheduling layer is visible in the repository layout rather than the README prose. The Dockerfile copies projects named BlazingQuartz.Core, BlazingQuartz.Jobs and BlazingQuartz.Jobs.Abstractions alongside the application projects, and the topics list includes quartz-net. That points to a Quartz-based job scheduler with a Blazor front end (the topics also list blazor and serilog). The repository screenshots are named web-schedules.png, web-schedules-log.png and web-configs.png, which is consistent with a web UI for schedules, logs and configuration.

Cookie handling is the part that determines whether the rest works. Login is a manual task: you scan a QR code with the bilibili app, and that initialises the cookie on first run or refreshes it when it expires. The README notes that different platforms store the cookie in different places. On Qinglong, accounts are added as environment variables with keys named Ray_BiliBiliCookies__0, Ray_BiliBiliCookies__1, Ray_BiliBiliCookies__2 and so on. On other platforms the default is a cookies.json account configuration file containing a BiliBiliCookies array of cookie strings. That difference matters more than it looks: it decides whether your credentials live in a panel's environment store or on a filesystem you control, and it decides what you back up.

Deploying BiliBiliToolPro with Docker and running the first login

The README points to docker/README.md for the Docker route and podman/README.md for Podman, and the repository's Dockerfile shows the shape of the image: it builds on mcr.microsoft.com/dotnet/aspnet:10.0, sets the working directory to /app, and exposes port 8080. The build stage uses mcr.microsoft.com/dotnet/sdk:10.0 and restores the Ray.BiliBiliTool.Web project. So the container is a web application listening on 8080, which is where the schedule and log UI lives.

The Dockerfile declares that exposed port, so the container is reached on 8080. The image tag is not given in the repository files; use the tag that matches the release you want.

After the container is up, open http://localhost:8080 in a browser. You should see the web UI referenced by the repository screenshots: a schedules view, a run log view and a configuration view.

The first real use is the Login task, and the README is explicit that it is a manual task run on first use or when the cookie expires. Trigger it from the UI and scan the QR code with the bilibili app. On success the tool writes the cookie to its account configuration. On a non-Qinglong platform that means a cookies.json file shaped like this, which the README gives as the account configuration format:

{
  "BiliBiliCookies": [
    "cookie1",
    "cookie2",
    "...",
  ],
}

Once a cookie is present, run the Test task to confirm it is valid before enabling anything on a schedule. Only then turn on Daily, which the README says should run once a day and is the job that collects the 65 points of experience.

Where BiliBiliToolPro is the wrong tool

The lottery job is the clearest case of a feature that carries a cost the README itself flags. LiveLottery is described as entering the live room lottery draws, and the README adds that most draws require following the streamer and that users who mind this should not enable it. That is not a bug, it is a design consequence: the tool can only do what the draw requires, and what the draw requires is a follow. The project ships UnfollowBatched precisely to clean up the follows that accumulate, but the two jobs together mean you are following and unfollowing accounts on a schedule. If you do not want your follow graph churning, leave both off.

A second boundary is that this is an application, not a service with a published API. The README documents configuration through a configuration document and a questions document, not through an interface contract. If you want to trigger a bilibili check-in from your own code, BiliBiliToolPro is not the integration point; you would be calling bilibili's APIs directly.

Third, the disclaimer is not decorative. The README states the application is for learning and testing, that the author is not responsible for it, and that it should be deleted after testing. Any account action taken by a scheduled job is taken on your account, under your cookie, with your credentials stored on your infrastructure. If you need a tool with an accountable operator behind it, this is not that. If you need something whose failure mode is a loud error rather than a silent missed day, note that the README's answer to observability is log pushing rather than alerting on task failure.

Qinglong as the alternative deployment model

The README's own list of deployment options is the honest comparison here, because BiliBiliToolPro is designed to sit inside other people's schedulers as well as run standalone. Qinglong is the most different of the six routes. On Qinglong the tool does not own its scheduling or its account storage: accounts become environment variables named Ray_BiliBiliCookies__0, Ray_BiliBiliCookies__1 and so on, and the README links to qinglong/README.md for the setup steps. The Baihu panel gets its own guide in baihu/README.md, and Helm gets helm/README.md.

The practical difference is where state lives and who upgrades what. Running the Docker image yourself means you control the .NET 10 base image, the port, the volume and the cookies.json file, and you are responsible for pulling new tags. Running it inside Qinglong means the panel holds the environment variables and the scheduling, and the tool is one script among others in that panel. If you already run Qinglong for other automation, the environment variable route is less to maintain. If you do not, adopting Qinglong just to host this tool adds a second system whose own upgrade cycle you now own. The README presents the six routes as equivalent choices, which they are not: they differ in who holds the credentials and who owns the upgrade.

Licence, release cadence and what an upgrade costs you

BiliBiliToolPro is licensed under GPL-3.0, and the repository carries a LICENSE file at the root. For self-hosting that is straightforward: you can run it, and if you distribute a modified version you take on GPL-3.0's obligations. The repository does not describe any commercial or hosted offering, so the question of a separate commercial licence does not arise here. This is a description of the licence, not legal advice; if you plan to redistribute a modified build, read the licence text itself.

The release history shows a project that is being pushed to. Version 4.0.2 was released on 2026-09-19, 4.0.1 on 2026-09-10, and 3.8.1 on 2025-08-26. The last push to the repository was on 2026-09-19. The jump from 3.8.1 to 4.0.x, with 4.0.1 and 4.0.2 landing nine days apart, is the kind of sequence that usually means a major change followed by quick fixes, and it is the main upgrade risk: if you are still on 3.8.x, treat the move to 4.0.x as a major version change and read CHANGELOG.md before pulling. The README does not document a rollback procedure, so the safe approach is to keep your cookies.json or Qinglong environment variables outside the container so that a bad image can be replaced without redoing the QR login.

Upgrade cost is otherwise low. The image is self-contained, the configuration is documented in docs/configuration.md, and the README says almost every function has an exposed setting such as task switches, dates and IDs. The real recurring cost is cookie lifetime: whenever the cookie expires, Login has to be run manually again, and that is a human step no upgrade removes.

Editorial conclusion

Adopt BiliBiliToolPro if you already run Docker, Qinglong or a Kubernetes cluster and want daily bilibili tasks handled by a scheduled process rather than by hand; skip it if you need a documented REST API, an audit trail of every action, or a tool whose author accepts responsibility for how it is used. Before committing, read docs/configuration.md for the task switches, confirm where cookies.json is written on your platform, and decide whether LiveLottery is acceptable given that most draws require following the streamer.

Frequently asked questions

Official sources

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