MiBeeHive: The "Hive" Toolbox I Built for My Studio

Coming from an operations background, later transitioning to development, the number of projects I maintain keeps growing. Various middleware, databases, monitoring components… each version upgrade is a manual labor: go to the official site to find the download link, compare version numbers, manually download to the internal network, then distribute to each machine. I used to write a bunch of Shell scripts to periodically pull the latest versions to the LAN — functional but not user-friendly: scripts scattered everywhere, adding new software required writing parsing logic by hand, and there was nothing to check when things went wrong.

Later, as the studio’s machines multiplied, system installation became another problem. Dozens of ARM64 mini PCs — installing them one by one with USB drives? No thanks. Plus daily container image management, syncing between various registries…

So I decided to write a complete system in Go, bundling version management, unattended system installation, and container management all into one tool. That’s MiBeeHive.

Why Build MiBeeHive

Put simply, I was forced into it. My studio’s daily operations had several pain points:

Version updates are too tedious. Prometheus releases a new version, VictoriaMetrics releases a new version, Grafana releases a new version… so many components to keep up with. Previously I used Shell scripts + cron to periodically fetch releases from the GitHub API, but each software source has different parsing logic, making maintenance a headache. And if a script breaks, you might not even know for days that new versions aren’t being pulled.

System installation is too inefficient. ARM64 devices don’t have ready-made Cobbler/MAAS solutions like x86 — lightweight PXE services are basically non-existent. Every time a batch of new devices arrives, it’s either manual installation or writing SD cards, extremely inefficient.

Container image management is too scattered. After building project images, pushing them to Docker Hub is slow and unreliable (domestic network situation, you know the drill). I wanted an internal Registry for caching and distribution, but management was another problem.

File sharing is too primitive. Transferring files on the internal network either uses scp or requires setting up NFS/Samba — complex configuration with no web interface. I just wanted to upload and download files through a browser.

I looked at existing solutions: Gitea Releases only manages its own repositories; Nexus/Artifactory is too heavy (Java-based, memory-hungry); various PXE solutions are mostly x86-focused; there are lightweight WebDAV servers, but they’re too limited in functionality.

My requirements were actually simple:

• One binary, download and run
• ARM64 priority, low resource usage (my NAS only has 469MB memory)
• Web interface for management, no SSH to change configs
• Cover version management, system installation, containers, and file sharing all in one

No existing solution fit. So I built my own.

What is MiBeeHive

MiBeeHive is a lightweight studio tool platform written in Go. The name comes from “hive” — Foraging, Provisioning, and Sharing, corresponding to the three core modules.

Overall Architecture

MiBeeHive revolves around three core modules, each with clear responsibilities:

flowchart LR
    subgraph Sources
        SRC@{shape: hex, label: "6 Software Sources"}
    end

    subgraph MiBeeHive
        FORAGE["Foraging<br/>Version Management"]
        PROV["Provisioning<br/>System Installation"]
        SHARE["Sharing<br/>File Sharing"]
        CTNR["Container<br/>Docker Management"]
        DASH["Dashboard"]
    end

    SRC -->|"Fetch"| FORAGE
    FORAGE --> DASH
    PROV --> DASH
    SHARE --> DASH
    CTNR --> DASH

    classDef src fill:#E3F2FD,stroke:#1565C0,color:#1565C0
    classDef mod fill:#FFF3E0,stroke:#E65100,color:#BF360C
    classDef hub fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    class SRC src
    class FORAGE,PROV,SHARE,CTNR mod
    class DASH hub

Foraging fetches versions from 6 public software sources; Provisioning provides PXE unattended system installation; Sharing shares files via WebDAV; the Container module manages Docker and Registry. The Dashboard aggregates the status of all modules.

Looking at the internal layers, the whole system is a clean data pipeline:

flowchart LR
    REQ["HTTP Request"] --> MW["Middleware<br/>JWT / TLS / Rate Limit"]
    MW --> HDL["Handler"] --> SVC["Service"] --> REPO["Repository"]
    REPO --> DB@{shape: cyl, label: "SQLite"}

    classDef layer fill:#FFF3E0,stroke:#E65100,color:#BF360C
    classDef store fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    class REQ,MW,HDL,SVC,REPO layer
    class DB store

Standard layering: Handler → Service → Repository → SQLite. The frontend is a Preact SPA embedded via go:embed in the binary — deployment requires just one file.

Users and devices connect through different channels:

flowchart LR
    BR["Browser"] --> API["REST API<br/>:9090"]
    PXE["PXE Device"] -->|"Network Boot"| PXES["PXE Endpoint"]
    DAV["WebDAV Client"] -->|"File Read/Write"| DAVS["WebDAV Service"]
    DK["Docker CLI"] -->|"push/pull"| REG["Registry"]

    API --> CORE["MiBeeHive Core"]
    PXES --> CORE
    DAVS --> CORE
    REG --> CORE

    classDef client fill:#E3F2FD,stroke:#1565C0,color:#1565C0
    classDef endpoint fill:#FFF3E0,stroke:#E65100,color:#BF360C
    classDef core fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    class BR,PXE,DAV,DK client
    class API,PXES,DAVS,REG endpoint
    class CORE core

Four access methods cover all scenarios: browser for management, PXE for system installation, WebDAV for file transfer, Docker CLI for image push/pull.

Foraging — Version Management

This module solves the problem of “how to quickly pull the latest versions of open source software to the internal network.”

flowchart LR
    SRC["Software Source"] -->|"Scheduled"| SCHED["Parse Version"]
    SCHED -->|"New Version Found"| DL["Download Queue"]
    DL -->|"SHA256 Verify"| STORE@{shape: cyl, label: "Local Storage"}

    classDef input fill:#E3F2FD,stroke:#1565C0,color:#1565C0
    classDef proc fill:#FFF3E0,stroke:#E65100,color:#BF360C
    classDef out fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    class SRC input
    class SCHED,DL proc
    class STORE out

Currently supports 6 types of software sources:

• GitHub Releases — Most commonly used, fetches latest release assets via API
• Go Proxy — Pulls Go compilation toolchain directly
• HashiCorp — Terraform, Consul, Vault and other products
• Grafana — Grafana, Loki, Tempo, etc.
• NPM — Frontend toolchain
• PyPI — Python packages

Each source is configured via Web UI, supporting API Token management, scheduled scheduling, automatic retries, and integrity verification. What previously required writing 6 sets of Shell scripts can now be done with a few clicks on the page.

Provisioning — System Installation

This module solves the problem of “bulk installing systems on devices.”

sequenceDiagram
    participant CLIENT as ARM64 Device
    participant DHCP as DHCP Service
    participant PXE as MiBeeHive PXE
    participant TFTP as TFTP/HTTP
    participant WEB as Web Admin UI

    Note over WEB,PXE: 1. Admin configures installation template via Web
    WEB->>PXE: Create preseed/kickstart/autoinstall config

    Note over CLIENT,DHCP: 2. Device network boots
    CLIENT->>DHCP: DHCP Request (PXE)
    DHCP-->>CLIENT: Return PXE server address
    CLIENT->>PXE: Request boot configuration

    Note over PXE,TFTP: 3. Deliver installation configuration
    PXE->>CLIENT: Return bootloader + kickstart URL
    CLIENT->>TFTP: Download kernel and initrd
    CLIENT->>TFTP: Download ISO (streaming)

    Note over CLIENT: 4. Unattended installation
    CLIENT->>CLIENT: Automatic partitioning, installation, configuration

Core capabilities:

• PXE Service — Devices boot over the network when plugged in, no USB drive needed
• OS Template Generation — Supports Debian preseed, RHEL kickstart, Ubuntu autoinstall — just fill in a form on the Web
• ISO Management — Auto-discovers latest ISOs of major distributions, streaming download saves disk space
• Configuration Preview — Preview the complete configuration file after generating a template, confirm before deploying

Previously, setting up 10 machines would take a whole day. Now, configure the template, boot the machines, and it’s basically hands-off.

Sharing — WebDAV File Sharing

This is the simplest and most practical feature: a WebDAV server with anonymous read-only + admin read-write access, supporting HTTPS.

No more scp for transferring files on the internal network — just drag and drop through the browser, or mount it as a local disk via a WebDAV client. Windows Explorer, macOS Finder, and Linux’s davfs2 can all connect directly.

Container Management

This module was added later. After building images for my own projects, I needed a place to manage and distribute them.

• Docker container CRUD, start/stop, log viewing, resource statistics
• Multi-Registry support, image synchronization
• Tag retention policies, automatic cleanup of old versions
• Application templates, one-click deployment of common services

Dashboard

Aggregated view of all modules:

• System status: Real-time CPU, memory, disk charts
• Module cards: Key metrics for each module at a glance
• Activity timeline: Recent fetch and download events
• Quick actions: One-click access to common features

Technical Choices

When choosing technologies, there were several hard constraints:

1. Single binary: Don’t want to install Java Runtime, Node.js, etc. on ARM64 mini PCs
2. Low memory: Target device only has 469MB RAM
3. Pure Go: No CGO dependency, easy cross-compilation
4. No heavy frameworks: No chi/gin/echo, no npm, no cron library

The final stack:

The frontend uses a Preact + HTM combination — no JSX, no compilation, no npm. Just write JavaScript directly. The entire frontend has 38 modules, embedded into the Go binary after building, requiring only a single file for deployment.

Actual Deployment

I run it on an ARM64 mini PC with 469MB of memory and 32GB of storage. MiBeeHive itself uses about 30-40MB of memory — very lightweight.

Systemd service configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

[Unit]
Description=MiBeeHive
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mibeehive
ExecStart=/opt/mibeehive/mibeehive
WorkingDirectory=/opt/mibeehive
Restart=on-failure
RestartSec=5

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/mibeehive
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Save to /etc/systemd/system/mibeehive.service, run systemctl enable --now mibeehive, and you’re done.

About the Name “Hive”

MiBeeHive — “Mi” is the abbreviation of my name Mickey, “Bee” comes from Mi-Bee Studio, and “Hive” is the hive. The three core module names are all bee-related:

• Foraging — “Forage” for the latest versions from various software sources
• Provisioning — “Build” the runtime environment for new devices
• Sharing — “Share” the resources in the hive with everyone

A bit cringey, but memorable.

Open Source

MiBeeHive is open source. If you’re interested, give it a try:

• MiBeeHive: https://github.com/Mi-Bee-Studio/MiBeeHive (AGPL-3.0 license)

Documentation is comprehensive, covering architecture, deployment, and API references.

Final Thoughts

This project is essentially a tool I built for myself to solve everyday problems. With limited personal energy, iterations will primarily focus on my own actual needs — I won’t deliberately pursue feature completeness.

If you happen to have similar needs, feel free to download it and give it a try. I’ll be glad if you find it useful.