Sitoi/dailycheckin: a Python multi-account sign-in runner for Docker, Qinglong and Synology

The chore DailyCheckIn automates, and who ends up running it

Daily sign-in bonuses are small and repetitive. Bilibili gives experience and coins, V2EX gives copper coins, 有道云笔记 gives storage space, 爱奇艺 gives lottery draws, 阿里云盘 gives membership days and space, 恩山无线论坛 gives coins and points, and i茅台 is used for 生肖茅台 purchase applications. Doing any one of these by hand takes under a minute. Doing seventeen of them across several accounts every day does not, and the failure mode is silent: you simply stop earning.

DailyCheckIn exists to collapse that set of chores into one scheduled job. The README describes it as a daily check-in script for Docker, 青龙面板, 群晖 and local execution, and the repository ships a Python package plus a Docker image. The audience is narrow and identifiable: people who already keep a NAS, a home server or a Qinglong panel running, who are willing to paste account cookies into a configuration file, and who want the results pushed to a chat app rather than read from a dashboard.

It is not a general-purpose automation framework. There is no plugin SDK described in the README, and no way to add a site without editing the Python package itself. The value is the pre-built task list, not the engine.

How the task list, config and notifiers fit together

The repository layout is conventional for a Python CLI: a dailycheckin package directory, a docker directory with the image definition, a docs directory, a Makefile, pyproject.toml, requirements.txt and a top-level imaotai_login.py helper. Entry points are declared through setup.py, which registers a console script named dailycheckin, so the same code path serves both the PyPI install and the container.

Each sign-in target is a task with a short name that appears in the README table: KGQQ, YOUDAO, TIEBA, BAIDUWP, BILIBILI, V2EX, ACFUN, IQIYI, SMZDM, ALIYUN, ENSHAN, FNNASCLUB, AOLAXING, IMAOTAI, MIMOTION and BAIDU. The table also carries a 检查日期 column, which is the last date the maintainer verified that task. That column is the most honest part of the documentation: it separates tasks checked on 25.09.28 from ones last checked on 24.02.20, and it flags MIMOTION with a brown marker meaning 看脸, roughly "depends on luck".

Notifications are a separate list rather than a per-task setting: dingtalk, 企业微信群机器人, 企业微信应用消息, telegram, Bark, server 酱, server 酱 TURBO, pushplus, Cool Push, qmsg 酱 and 飞书. Eleven channels, all of them push-based. There is no described mechanism for querying historical results, so the notification is the record.

The dependency list is deliberately thin. pyproject.toml pins pycryptodome==3.17, requests~=2.25.1, rsa~=4.0 and urllib3~=1.26.2. That last pin matters: urllib3 1.26.x is the pre-2.0 line, and requests is held at the 2.25 series. Anyone who installs dailycheckin into an environment that already needs a modern urllib3 will hit a resolver conflict, and the project does not document a workaround.

Installing from PyPI or Docker and running the first task

The README points to the documentation site at sitoi.github.io/dailycheckin for setup, and the packaging files show two supported install routes. The Python route requires 3.9 or newer, per the REQUIRES_PYTHON value in setup.py.

For a local install, the package is published under the name dailycheckin and registers a console script of the same name:

pip install dailycheckin
dailycheckin

Running the bare command starts the configured tasks. On a first run with no configuration present, the process has nothing to sign into, so expect it to exit quickly rather than prompt you interactively; the README does not describe a first-run wizard.

The container route is the one the project name leads with. The repository has a docker directory and a docker_start.sh script at the top level, and the image is published on Docker Hub as sitoi/dailycheckin:

docker pull sitoi/dailycheckin
docker run -d --name dailycheckin sitoi/dailycheckin

Detached mode is the intended production shape, because the work is a scheduled job rather than a service you talk to. For the first run, drop the -d so the startup log prints to your terminal and you can see which tasks were skipped for missing credentials. The README does not document the environment variables the image reads, so take the variable names from docker_start.sh in the repository rather than guessing them.

If you run 青龙面板 instead, the README lists it as a supported deployment target alongside Docker and 群晖, and the docs site is where the panel-specific steps live.

The task table is a maintenance ledger, not a feature list

Sixteen of the seventeen tasks carry a green marker in the README table. That looks reassuring until you read the 检查日期 column next to it. BILIBILI, TIEBA, V2EX, ACFUN, IQIYI, KGQQ, YOUDAO, IMAOTAI and BAIDU were last checked on 25.09.28. SMZDM, ALIYUN, ENSHAN and AOLAXING were last checked on 24.02.20, roughly nineteen months earlier. FNNASCLUB carries 25.12.09. MIMOTION carries 25.09.28 with the 看脸 marker.

A green marker next to a verification date from early 2024 is a claim about the past, not about today. Chinese consumer sites change their anti-automation behaviour often, and a sign-in endpoint that worked in February 2024 can return a login wall or a captcha now without the maintainer noticing. Treat the 检查日期 column as your own triage list: if you only care about one or two tasks, check their dates before you invest time in the deployment.

The MIMOTION entry is the clearest admission in the whole README. 小米运动 step-count spoofing is marked as luck-dependent, which is an honest way of saying the maintainer cannot guarantee it works. The project does not publish a failure rate or a success metric, and none should be inferred from the marker.

The broader limitation is structural. Every task depends on an undocumented private API of a third-party site. There is no contract, no versioning and no deprecation notice. When a site changes, the task breaks and the fix lands in a future release or not at all. The release history shows this cadence: 25.9.28, 25.9.29 and 25.12.9, with gaps of weeks to months between them. The last push to the repository was on 2026-07-09, so the project is not abandoned, but the release rhythm is not a support commitment either.

Credentials, cookies and what you are actually trusting

Most of these tasks authenticate with a cookie or token copied out of a logged-in browser session, not with an OAuth flow. That is inherent to the problem: Bilibili, Tieba, V2EX and the rest do not publish sign-in APIs for third-party schedulers. The practical consequence is that the container holds live session credentials for every account you configure, and those credentials grant whatever the session grants, which for some accounts includes purchase and payment surfaces.

DailyCheckIn is a self-hosted tool. The credentials stay on your machine and go only to the target sites, plus whatever the notification channel receives. The project does not describe a remote backend, and the README shows no account system of its own. That is the right architecture for this class of tool, and it also means the security boundary is your own host: the Docker volume, the config file and any backup that includes them.

There is a second-order risk that is easy to overlook. Session cookies expire. When one does, the task fails, and the failure arrives as a notification rather than as a crash you would notice. If you route notifications to a channel you do not read, you will discover the expiry weeks later when you check a balance. The README lists eleven notification channels and no health endpoint, so the notification channel is the monitoring.

Where DailyCheckIn is the wrong tool

If you need one task for one site, this is more machinery than the job deserves. A fifteen-line Python script using requests, run from cron, does the same thing with no dependency pin conflicts and no container to update. DailyCheckIn earns its keep at the point where you have several accounts across several sites and want one schedule and one notification stream.

If your accounts are valuable enough that a lockout would hurt, think twice. Automated sign-in against consumer sites can trip risk controls, and the project does not describe rate limiting, jitter or per-account backoff. The README documents multi-account support as a feature (支持多个账号签到) without describing how accounts are spaced out in time.

If you need a supported product with a response time, this is the wrong category entirely. It is an MIT-licensed community project. The issue tracker is the support channel, and the release dates show that fixes arrive when the maintainer or a contributor gets to them.

Finally, if your environment is not container-friendly or you do not want a long-running host, none of the documented deployment targets fit. Docker, 青龙面板 and 群晖 all assume a machine that stays on.

How it compares with a general automation scheduler

The obvious alternative is a general-purpose scheduler such as a cron-driven Python or Node script, or a workflow tool that runs arbitrary code on a timer. The difference in approach is where the site-specific logic lives. With a general scheduler you write and maintain the HTTP calls, the cookie handling, the response parsing and the retry logic for each site. DailyCheckIn ships that logic already written for seventeen targets, and you supply credentials.

That trade is not free. A general scheduler never breaks because an upstream site changed, because it contains no site knowledge; you fix the one script that broke. DailyCheckIn can break all at once when a shared dependency or a shared helper changes, and it can also rot quietly per task, which is exactly what the 检查日期 column documents. You are trading maintenance effort for maintenance risk.

The second alternative is doing nothing and accepting the lost bonuses. For most of these sites the daily reward is small: the README describes KGQQ as roughly 120 flowers per day and V2EX as copper coins. The honest framing is that DailyCheckIn is worth deploying when you already have the host and the credentials, and not worth standing up a server for.

Licence, upgrades and the cost of staying current

The project is MIT licensed, copyright 2021 Sitoi, with the licence file at LICENSE in the repository root. MIT is permissive: you can use, modify and redistribute the code, including in closed-source form, provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice, and it says nothing about the terms of service of the seventeen target sites, which is a separate question you should answer for yourself before automating sign-in on any account.

Upgrade cost is low in mechanism and non-zero in attention. The package is on PyPI and the image is on Docker Hub, so an upgrade is a pip install or a docker pull. Because the tasks depend on live third-party endpoints, an upgrade is also the main way a broken task gets fixed, which means staying on an old version means accumulating silent failures. The version scheme is date-like (25.9.28, 25.12.9), so you can read recency straight off the tag.

The pin on urllib3~=1.26.2 and requests~=2.25.1 is the practical upgrade constraint. If you install into a shared virtualenv, check those two before you upgrade anything else. The README does not document a rollback procedure, so keep the previous image tag or wheel if you need one.

Editorial conclusion

Adopt it if you already run Docker or Qinglong on a machine that stays on, you are comfortable storing account cookies for Chinese consumer sites, and you accept that each task can break whenever the target site changes. Do not adopt it if you need vendor support, an SLA, or a single sign-on that does not involve copying session cookies. Before deploying, read the task table on the project documentation site and check the 检查日期 column for the tasks you intend to enable, then run the container once in the foreground so you can read the startup log.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Sitoi/dailycheckin on GitHub