Sitoi/dailycheckin: self-hosted daily sign-in scripts for 16 Chinese services

What Sitoi/dailycheckin automates, and who it is written for

The README lists a fixed catalogue of daily sign-in tasks: KGQQ (全民K歌), YOUDAO, TIEBA, BAIDUWP, BILIBILI, V2EX, ACFUN, IQIYI, SMZDM, ALIYUN, ENSHAN, FNNASCLUB, AOLAXING, IMAOTAI, MIMOTION and BAIDU. Each one performs the same kind of action a user would do by hand: claim daily flowers, collect storage space, sign a forum thread, take a lottery draw, or submit pages for indexing. The value is repetition removal, not new capability. If you check in to Bilibili every morning for the experience points, the BILIBILI task does the same sequence.

The audience is narrow on purpose. Every task assumes you already hold an account on that specific site and can extract a cookie or token for it. Nothing here creates accounts, solves captchas on your behalf, or works around a login you do not have. The README's status table is the honest part of the project: it marks each task with a colour, and MIMOTION (Xiaomi step counting) carries the brown marker the README defines as 看脸, roughly "depends on luck". Several rows show check dates from 24.02.20 while others show 25.09.28, which tells you maintenance attention is uneven across the list.

One package, many tasks: how the scripts are organised

The repository is a single Python package named dailycheckin, declared in pyproject.toml at version 25.12.9, with setup.py exposing a console entry point. Dependencies are deliberately small: pycryptodome, requests pinned to the 2.25.1 series, rsa and urllib3 pinned to the 1.26 series. That pinning is a design decision worth noticing. requests 2.25.1 and urllib3 1.26.2 are old lines, and the tight pins mean the package will not silently pick up newer HTTP client behaviour, which is good for reproducibility and awkward if you want to share a virtualenv with a project that needs a newer urllib3.

Each service is a module inside the dailycheckin package, and the entry point dispatches to them. The practical consequence is that adding a site means adding a module, which is why the task list grows in release-sized steps rather than continuously. The release history reflects that: 25.9.28, 25.9.29 and then 25.12.9, with FNNASCLUB (飞牛 Nas) appearing with a 25.12.09 check date. The last push to the default branch was on 2026-07-09, so the project is not archived but has been quiet for roughly two months as of this writing.

Installing DailyCheckIn with pip and running a single task

The README states the project supports PyPI installation, and pyproject.toml declares the package name as dailycheckin. The Python floor is 3.9.0, set in setup.py. A minimal local install therefore looks like this:

python3 -m venv .venv
source .venv/bin/activate
pip install dailycheckin

After that, the installed console script is the entry point referenced by setup.py. The README does not print the full command line here, so check the documentation site at sitoi.github.io/dailycheckin for the exact invocation and the environment variables each task expects. What you should see after a successful run is a per-task result plus a notification if you have configured one of the 11 channels listed in the README.

The container route is the one most people use, because the repository ships a docker/ directory and a docker_start.sh script at the top level. The README names Docker, Qinglong (青龙面板), Synology and local execution as supported deployment targets. The Docker image is published as sitoi/dailycheckin on Docker Hub, which is where the README's pull-count badge points.

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

The exact volume mount for your configuration file is not spelled out in the README; the docker/ directory and docker_start.sh in the repository are the authoritative source. Read those two before you run the container, because a container that starts without a mounted config will run with no accounts and report nothing useful.

Notifications are a first-class feature, and that shapes the config

The README devotes a separate section to notification targets: dingtalk, WeCom group robot, WeCom app message, telegram, Bark, server chan, server chan TURBO, pushplus, Cool Push, qmsg and Feishu. Eleven channels for a sign-in script is more than you would expect, and it tells you how the author expects the tool to be used. Nobody watches a cron job. The notification is the only evidence the run happened, and the only way you learn that a task failed because the site changed its response format.

This has a config consequence. A working deployment needs at least one notification channel configured, otherwise a broken task is indistinguishable from a task that ran and found nothing to do. If you are evaluating the project, configure the channel first and the accounts second. The README lists the channel names but does not document the credential format for each one in the repository text; that detail lives on the documentation site.

Multi-account support is stated in the feature list and is the other reason the config is non-trivial. Running three Bilibili accounts means three credential sets for the same task, and the README does not describe how they are separated in the configuration file. Expect to read the docs page for the specific task before you add a second account.

Where DailyCheckIn breaks, and when it is the wrong tool

Every task here talks to a private endpoint of a consumer website. Those endpoints are not contracts. When Bilibili or iQiyi changes a response field, the corresponding module fails, and the fix has to come from a maintainer or a contributor. The README's own status table is the evidence: rows carry different check dates, one row (MIMOTION) is marked 看脸, and the legend includes a blue state meaning the script can run only after an update. That is a project telling you plainly that some tasks are ahead of others.

The second limitation is dependency age. requests is pinned to the 2.25.1 series and urllib3 to the 1.26 series in pyproject.toml and requirements.txt. If you install dailycheckin into a shared environment alongside a library that requires a modern urllib3, pip will either refuse to resolve or you will end up with a broken combination. Use an isolated virtualenv or the container, not your system Python.

The third is scope. There is no Genshin Impact task in the README's list despite the search traffic that phrase attracts, and no generic HTTP check-in framework. If your target service is not one of the 16 named, this project does nothing for you. Writing your own module is possible since the package is MIT-licensed and the source is plain Python, but at that point you are maintaining a fork, not using a tool.

DailyCheckIn compared with a general automation scheduler

The obvious alternative is a general scheduler such as Qinglong itself, or plain cron plus your own scripts. Qinglong is not really a competitor here: the README lists it as a supported deployment target for DailyCheckIn, so the two compose. The real alternative is writing the sign-in calls yourself.

The difference is where the maintenance burden sits. A hand-written script for one service is maybe fifty lines of requests code, and you own the cookie handling, the retry logic and the notification formatting. DailyCheckIn owns all of that for 16 services and gives you one config surface and one notification path. The trade is that you inherit 16 services' worth of breakage instead of one, and you cannot fix a broken task without either waiting for a release or patching the installed package.

A second alternative is a browser automation stack. Those drive a real browser session, which survives some changes that break direct HTTP calls, but they need a heavier runtime and are harder to run on a small NAS. DailyCheckIn's approach is direct HTTP with the pinned requests and urllib3 versions, which is lighter and faster and correspondingly more brittle to endpoint changes. Pick based on whether you value a small footprint or resistance to interface drift.

Licence, upkeep and the real cost of running this

DailyCheckIn is MIT licensed, per the LICENSE file and the licence badge in the README. MIT is permissive: you can modify the modules, run them commercially, and redistribute, provided the copyright notice and permission notice travel with the code. Nothing in the repository text imposes additional terms on the tasks themselves. That said, the MIT licence covers the code, not your relationship with Bilibili or iQiyi. Automating sign-in may conflict with a site's terms of service, and that risk sits with you, not with the licence. This is not legal advice; read the terms of the services you point it at.

The upkeep cost is the release cadence. The listed releases are 25.9.28, 25.9.29 and 25.12.9, so fixes arrive in bursts tied to specific site changes. The last push to main was on 2026-07-09. Between releases, a task that breaks stays broken. Budget for reading the status table each time you upgrade, and for the possibility that a task you depend on is the one that has gone stale.

Editorial conclusion

Adopt DailyCheckIn if you already have accounts on the listed Chinese services and a host that can run Docker, Qinglong or Python 3.9 and above, and you accept that each task depends on a reverse-engineered endpoint that the site owner can break without notice. Do not adopt it if you need an SLA, if your accounts are business-critical, or if none of the 16 tasks match a service you use. Before committing, check the status table in the README for the tasks you care about (MIMOTION is marked as untested and several entries carry older check dates), then run one task in a scratch container and confirm the notification arrives.

Frequently asked questions

Official sources

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