Daidai Panel: a self-hosted panel for scheduled scripts and their logs

A panel for scripts, not for services

The project describes itself as a lightweight scheduled task management platform, similar to Qinglong Panel, and the architecture is stated plainly: Go with Gin, Vue 3 with Element Plus, and SQLite. The focus is on script hosting and automated task scheduling, supporting scheduled execution and visual management of Python, Node.js including .js and .mjs, Shell, TypeScript and Go scripts. The badges confirm the stack, with Go 1.25, Vue 3, Element Plus 2.x, SQLite 3 and a Docker-ready marker. What this is not is an application platform, and the difference matters for expectations. There is no service mesh, no job queue with retries across a cluster, no build pipeline. There is a web panel that stores scripts, runs them on a cron schedule, streams their output, and notifies you when they finish. The README also links a separate APP client repository, linzixuanzz/Dumb-Panel-APP, so the panel is designed to be driven from a phone as well as a browser, which is the shape of the tool the project is modelling itself on.

The feature surface, taken module by module

The README's expandable list is a specification rather than marketing, and it is worth reading for the details. The scheduling module supports standard cron expressions, quick-select time rules, enable and disable toggles, manual triggering, timeout control, a retry mechanism, pre and post hooks forming a task dependency chain, and multi-instance concurrency control. The script module gives an online editor with syntax highlighting, file create, rename, delete, upload and drag-and-drop moves, script version management, and debug runs with live output. The log module is an SSE stream that follows the newest output and pauses when you scroll up, with execution state tracking across success, failure, timeout and manual termination, execution duration statistics and automatic log cleanup. The environment variable module groups values, orders them by drag, masks sensitive ones and injects them at task run time, and it supports batch import and export in a format compatible with Qinglong. The dependency module installs Python packages with pip and Node.js packages with npm, and it also handles Linux system packages, detecting apk, apt, dnf, yum, microdnf and zypper, with an administrator-only web system command line in the toolbar.

Subscriptions from Git, and the rules that decide what becomes a task

The subscription module pulls scripts from a Git repository and syncs on a schedule, with SSH key or token authentication, and its filtering rules are the most detailed part of the documentation. The whitelist, blacklist and dependency rules correspond to the second, third and fourth arguments of Qinglong's ql repo command, with both comma and pipe usable as separators. A plain fragment matches by substring containment rather than as a glob, while a fragment containing ^ $ ( ) [ ] { } ? backtick or .* .+ is treated as a regular expression matched against the relative path in the repository, unanchored, with forward slashes for path separators, so a pattern like ^jd[^_] matches files such as jdCookie.js in the repository root. A backslash escapes a literal character, and a broken regular expression is reported when you save. The behavioural difference between the rules is the part that catches people out. The whitelist does not just decide which tasks are created, it also determines what is checked out to disk, and when a specific subdirectory is given the checkout follows it while the whitelist only decides whether a task is created. The dependency rules also take part in the checkout, pulling matched files into the script directory for the main script to call, but those files do not become scheduled tasks, so with an empty whitelist the dependency rules have no effect on task creation. The blacklist applies to both.

How a scheduled task is created from a subscription

There is one rule that decides whether a subscribed script becomes a scheduled task at all. A script must declare a cron expression in its header, and when it does not, the task is created using the default cron rule from the subscription settings, and if that setting is left empty no task is created, which is the behaviour since v3.2.9. That single convention is what makes a Git repository of scripts usable as a task source without a manifest file, and it is also the thing to check first when a subscription pulls files but no task appears. The rules also interact with the checkout, and the documentation is explicit about the corner cases. When a regular expression is used the checkout switches to the entire repository, because git's own checkout rules cannot express a regular expression, so more disk is used while the range of tasks created does not change. A regular expression in the whitelist only matters when no specific subdirectory has been given. And the dependency rules pull their matched files to disk without creating tasks, so the auxiliary libraries that a main script requires go there rather than in the whitelist. The README also notes that the whitelist entries participate in the actual checkout, so only files that hit the whitelist land on disk and become scheduled tasks.

Deploying it as one container on port 5700

The panel officially recommends Docker, and the compose file is the whole installation. The panel service is built from an image variable that defaults to the published one, named daidai-panel, with a restart policy of unless-stopped, a port mapping, and a bind mount for the data directory that survives upgrades:

name: daidai-panel

services:
  daidai-panel:
    image: ${DAIDAI_PANEL_IMAGE:-linzixuanzz/daidai-panel:latest}
    container_name: daidai-panel
    restart: unless-stopped

The default browser address is the host IP on port 5700, and the first visit to localhost:5700 enters administrator initialisation. Two compose files exist for other shapes, one for Debian and one for a production Watchtower setup, and the Dockerfile shows the same split in the image: a node frontend builder stage, a golang:1.25-alpine backend builder that produces both the daidai-server binary and a ddp command, and a final alpine:3.23 stage with nginx, nodejs, npm, git and su-exec. The final stage carries an INSTALL_FULL_TOOLS flag, since the full image additionally installs Go, the Docker CLI, wget and a native build toolchain, and the container can drop privileges with PUID and PGID, which the compose file documents for NAS deployments, including the warning that dropping privileges stops the Linux system package installation from working because it needs root. The Dockerfile also shows a version inconsistency worth noting, with the build argument VERSION set to 2.2.18 while the published releases are on the 3.3.x line.

The update path depends on Watchtower, and the version matters

The panel checks for system updates by asking Watchtower to do the work, and the documentation is unusually insistent about the Watchtower version because the failure is silent. Watchtower must be v1.20.0, released on 2026-07-21, or newer, otherwise the update check does not work. The reason is that the compose file uses the WATCHTOWER_HTTP_API_ENDPOINTS=update environment variable, which only exists from v1.20.0, with earlier versions recognising only the command line argument --http-api-update, and Watchtower silently ignoring environment variables it does not recognise. The container starts normally and the logs show no error, but the HTTP API port never opens and pressing update in the panel returns connection refused. The second trap is that Watchtower disables itself with the com.centurylinklabs.watchtower.enable=false label so that it does not manage itself, which means it does not self-update and the local latest tag stays on whatever day it was pulled. The fix for anyone who deployed Watchtower before v1.20.0 is to pull and rebuild it manually:

docker compose pull watchtower
docker compose up -d watchtower

docker logs daidai-watchtower 2>&1 | head -n 5

The documentation also warns that a mirror registry may cache an old latest tag, in which case a specific tag such as nickfedor/watchtower:1.21.2 can be pulled temporarily.

The demo site, and the warning attached to it

There is an online demo at the GitHub Pages site, and the README is careful to explain what it is before you put anything in it. The demo site is not a real running panel, it is the panel front end packaged on its own with simulated data in the browser, with no backend and no script execution. Your operations only exist in your own browser, refreshing the page restores the initial state, and nobody else can see them. The consequence is spelled out in bold: do not enter real cookies, passwords or push keys in the demo site, because there is no server to hold them and entering them achieves nothing. That warning is a good guide to the security posture of the real thing. The panel stores the credentials your scripts need in its database, it accepts them through a web form, and it can install system packages as root when it is running with default privileges, so the panel's own login is the thing standing between an attacker and your accounts. The security section is correspondingly serious: two-factor authentication with TOTP, an IP allowlist, login logs, multi-device session management with configurable maximum session counts for the web and app clients, and a separate CORS_ORIGINS variable for when the panel is exposed on a public domain, with private and LAN addresses already permitted.

Notifications, an Open API, and an MCP server for AI clients

Three integration surfaces are worth calling out. Notifications cover 22 channels, with Bark, Telegram, Server酱, WeCom, DingTalk and Feishu named, and they fire on task completion results, on system events, and with custom templates. The Open API uses App Key and App Secret authentication and is intended for third-party systems to drive the panel. The MCP service is the unusual one. A built-in MCP server lets AI clients such as Claude and Cursor connect and query tasks, read logs and inspect failed tasks, and if an administrator enables writes, also run tasks and change variables, with that disabled by default and a separate usage guide. The default-off design is the correct one for a feature that executes arbitrary scripts, and the fact that it exists at all says something about where the project expects its users to go. The remaining system features round out the picture: one-click backup and restore including view data, scheduled backups daily, weekly or monthly, customisable panel title and icon, real-time CPU, memory and disk monitoring with execution trend statistics, and system monitoring that also surfaced in the recent changelog entries, where v3.3.8 shows scheduled tasks and subscriptions displaying both the last and the next run time.

Editorial conclusion

Daidai Panel suits someone who runs a pile of small automation scripts on a home server or NAS and wants them scheduled, logged and configurable from a web interface rather than from crontab and shell scripts. It is the wrong tool for a job that needs more than a script and a schedule, and it is the wrong tool if your scripts hold credentials, because the panel is a web application with a login that has to be secured properly, and the README's own demo warning is about exactly that class of mistake. Verify first that the container can reach the network your scripts need and that the volume holding ./Dumb-Panel is backed up, since that directory is the panel's data, and note that the newest release is v3.3.8 from 2026-10-20 with the last push on the same day.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. linzixuanzz/daidai-panel on GitHub
4. README
5. Releases