baihu-panel and the case for a cron panel that treats memory as the scarce resource

The whole design starts with a 1C2G machine and a Python script

The project states its motivation more plainly than most, and the reason to read it is that the constraint explains the design.

The author is a user of another panel and was not happy with its performance. On his own 1C2G machine, a Python requests script running every 30 seconds could push CPU usage above 50 percent at moments. He wanted a panel with lower memory and performance overhead, so he built one. In the same scheduling scenario with the same code, the project's own figure is that CPU spikes do not exceed 20 percent.

Those two numbers are the core claim, and they explain most of the technical choices elsewhere in the project. A panel that keeps its state in a database and its logs out of the filesystem is not doing less work, it is doing the same work with less of it. The scheduler is written in Go, the interface is Vue 3, and the runtime is a single container.

The project is Apache-2.0 licensed, the primary language is Go, and the description calls it a lightweight, high-performance cron panel built with Go and Vue 3. The last push to the repository was on 2026-10-20, with the newest listed release v1.5.6 dated 2026-10-17.

Mise is what turns a scheduler into a multi-language platform

The distinctive feature is deep integration with Mise, a runtime manager, which the project uses to install and switch versions of Python, Node.js, Go, Rust, PHP and almost every other mainstream language on demand, together with dependency management for each of them.

The dependency table is worth reading because it shows how much is handled for you. Python uses pip with a built-in virtual environment and a Tsinghua mirror. Node.js uses npm in global install mode with the npmmirror registry configured. Go uses go install, Rust uses cargo install, Ruby uses gem install, Bun uses bun add -g, PHP uses composer global require, Deno uses deno install -g, .NET uses dotnet tool install -g, Elixir and Erlang use mix archive.install, Lua uses luarocks, Nim uses nimble, Dart and Flutter use pub global activate, Perl uses cpanm, and Crystal uses shards.

That last set is the point. A panel that runs a Python script and a Rust binary on the same schedule, in the same container, with the right versions of each, is doing something a plain cron panel on a host with one language installed cannot.

The isolation mechanism is mise exec, which the project describes as a complete environment isolation so that different versions of a dependency package do not conflict. The workflow is three steps in the interface: install a language and version from the programming languages page using mise, then open dependency management from the installed list and type a name with an optional version, and the system installs it into the matching environment automatically.

Logs that never touch the disk are the design choice that shows

One line in the feature list carries more weight than the rest of the scheduler features: logs are not written to files, so there is no problem with frequent disk I/O.

That is a deliberate departure from how these panels usually work, and it is the direct answer to the CPU problem in the motivation. A panel that appends every line of task output to a log file is doing synchronous or asynchronous writes on every run, and a script running every 30 seconds means those writes happen constantly. On a small disk and a small machine, that is the kind of thing that shows up as a CPU spike.

The execution log feature list does say that log content is stored compressed and that logs are cleaned up automatically, which sounds like it contradicts the no-files claim. Read together, the consistent reading is that logs are kept in the panel's own storage and compressed there, rather than as append-only files on the host filesystem that grow without bound and need rotating. The distinction matters, because the storage is the panel's problem rather than your disk's problem.

Other scheduler features are more conventional. Standard Cron expression support with a quick picker for common rules, an enable and disable toggle per task, manual trigger, and a timeout control. The scheduler library is robfig/cron, and the log compression uses klauspost/compress.

Secrets are encrypted at rest and injected only when a task runs

The secrets feature is marked new in the description, and it is the part with the most careful security wording.

Secrets are stored with AES-GCM encryption and the database does not hold plaintext. The key is kept only in memory and is unset immediately after being read at startup. Execution logs automatically search for and mask sensitive secret content, shown as a row of asterisks. And there is strict permission isolation: secrets are injected only when the scheduler dispatches a task, and are not visible in the terminal or the test environment.

That last point is the design decision that makes the rest worthwhile. A panel with a web terminal is a panel where a human types commands, and a human who can type commands can read environment variables. Making the secrets invisible in the terminal, while still injecting them into the scheduled run, closes the obvious hole.

The changelog for v1.3.0 from 2026-09-23 records end-to-end secure decryption using ECDH and AES-GCM, which suggests the key exchange between panel and agent is separate from the at-rest encryption, and v1.4.0 from 2026-09-29 records end-to-end encrypted push for Bark notifications. A related change in v1.1.25 from 2026-08-10 was a security vulnerability fix, which is a reminder that this area of a project is where the sharp edges are.

Plain environment variables are also supported and injected at execution time, kept separate from the encrypted store so that configuration and secrets are not mixed.

Deployment is one compose file with three mounted directories

The compose file at the repository root is short enough to read in full, and it tells you everything about the deployment shape.

services:
  baihu:
    build:
      context: .
      dockerfile: docker/Dockerfile
    ports:
      - "8052:8052"
    volumes:
      - ./data:/app/data
      - ./configs:/app/configs
      - ./envs:/app/envs
    environment:
      - TZ=Asia/Shanghai
    restart: unless-stopped

The port mapping is 8052, and the commented environment block shows the override variables you can set, including the server port and host, the database type with mysql, postgres and sqlite as the options behind the gorm drivers in the module file, the database credentials and table prefix, and a BH_SECRET value used to encrypt the secrets store.

Three directories are mounted out of the container, and the split is the interesting part. /app/data is the panel's own data, /app/configs holds configuration files, and /app/envs holds the environment files that supply task variables. Mounting them separately means you can rebuild or recreate the container without losing the state, and it means the envs directory is where your task credentials live on the host rather than inside an image layer.

The repository also ships docker-compose.dev.yml for development and docker-compose.ghcr.yml for pulling a published image, and a Makefile with targets that build the Vue frontend and package it as a web UI archive.

The feature set has grown into a platform, fast

The changelog is the best evidence for where this project is heading, because it shows a single maintainer shipping releases almost daily over the summer.

The visible list starts at v1.1.20 on 2026-06-28 and runs to v1.5.6 on 2026-10-17, and it covers a lot of ground. Node interconnect with variable synchronisation and OpenConnect, terminal out-of-memory protection, ZSTD log compression, dependency auto-completion in the terminal, a tag management system, Monaco multi-language syntax highlighting, two-factor login, a Windows GUI installer with a system tray daemon, and Windows platform adaptation including a ConPTY pseudo-terminal rework.

The v1.5.0 release on 2026-10-07 added a natively built-in MCP service, a ServerChan push channel, lazy loading and search for the file tree, and real-time incremental sync for agents. v1.5.4 added MCP dual transport with Streamable HTTP and SSE. v1.5.5 brought multi-identity single sign-on with parallel coexistence, a separate SSO route with credential decoupling, and mobile responsive work.

Feature areas now include a built-in message push and notification engine covering DingTalk, WeCom, Telegram and ServerChan, with system-level event triggers such as task failure alarms and service downtime notices, and automatic generation of cross-language call examples for script integration.

The v1.2.0 release on 2026-09-22 is the one the project marks as the point where the core blueprint was assembled, with a declarative application engine and an application marketplace, a YAML-driven orchestration definition running through to the underlying task scheduling, and multi-channel message push, forming what the description calls a complete automation lifecycle loop.

Where baihu-panel is the wrong choice

Three limits are worth naming plainly.

The first is support. The release history shows releases on 2026-09-22, 2026-09-23, 2026-09-29, 2026-09-30, 2026-10-01, 2026-10-07, 2026-10-09, 2026-10-12, then 2026-10-15 twice, 2026-10-16 and 2026-10-17. That is an impressive pace, and it is also a single maintainer shipping continuously, which means a panel you depend on for a production pipeline is one person's hobby project at full speed.

The second is that the runtime installation is on demand rather than pinned by the platform. Every language version is installed through Mise when you ask for it, and every dependency is installed at run time from a public registry. That is convenient and it is also the opposite of reproducible. A task that worked yesterday can fail today because an upstream package published a new version, and the isolation guarantees that two versions of a package do not conflict with each other do not guarantee that the same version is installed tomorrow.

The third is the memory and cache management, which the changelog treats as an ongoing engineering problem. The v1.5.6 entry describes separating static and dynamic content to exclude core base images such as /opt/mise-base from cleanup, avoiding read traffic spikes caused by cold cleanup of the base layer after high frequency tasks, adding a 30 second debounce cooldown, and raising the unlimited container reclamation threshold to 512MB and above. A project that needs to describe its own cache eviction strategy this carefully is a project where the cache is a real cost, and the memory story that motivated the project is the story the code is still living in.

Editorial conclusion

baihu-panel suits someone running scheduled Python or Node scripts on a small VPS where a heavier panel would compete with the workload for memory, and it suits a team that wants encrypted secrets injected only at scheduling time rather than sitting in a plaintext environment file. It does not suit a large installation that needs a supported product with a service level agreement, because the release history shows a single maintainer shipping several releases a week, and it does not suit a team that needs its language toolchains pinned by the platform rather than installed on demand. Before deploying it, read the memory management notes in the changelog for the version you pick, and check the port mapping and the three mounted volumes in the compose file, since the panel runs on 8052 with data, configs and envs kept outside the container.

Frequently asked questions

Official sources

1. engigu/baihu-panel on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases