The thing that actually runs your game servers -_-
The Airlink Daemon is a lightweight agent that runs on each node server. It listens for commands from the panel, manages Docker containers, streams console output, handles file operations, and exposes SFTP access. It does the dirty work so the panel can stay pretty -_-
What it handles:
- Container lifecycle (create, start, stop, kill, delete)
- File system operations (list, read, write, upload, download, zip/unzip)
- SFTP credential management
- Live console streaming over WebSocket
- Container stats and status monitoring
- Backup creation, restore, and download
- Minecraft server query (player lists)
- Security radar scanning
- HMAC-signed authentication (nobody gets in without the key)
- Bun v1.0 or later
- Git
- Docker (running and accessible to the daemon process)
cd /etc/
git clone https://github.com/AirlinkLabs/daemon.git
cd daemonsudo chown -R www-data:www-data /etc/daemon
sudo chmod -R 755 /etc/daemonbun install
bun run build- Log into your Airlink Panel as an admin
- Go to Admin → Nodes → Create
- Copy the configure command and paste it in the terminal
./airlinkdOr with the built binary:
bun run startThe daemon is now listening for panel commands. It will obediently do whatever the panel tells it to -_-
The daemon reads its configuration from command-line arguments or environment variables:
| Argument | Env Variable | Description |
|---|---|---|
args[0] |
remote |
Panel URL (e.g. http://192.168.1.10:3000) |
args[1] |
key |
Authentication key (must match the panel's node key) |
args[2] |
port |
Port to listen on (default: 3002) |
Every request to the daemon goes through a multi-layer auth pipeline:
- IP Allowlist — only approved panel IPs get through
- Basic Auth —
Authorization: Basic <base64(Airlink:<key>)> - HMAC-SHA256 — request signature verification with nonce-based replay protection
The panel signs every request. The daemon verifies every signature. No signature, no service -_-
See the API Specsheet for the full HMAC protocol details.
The daemon exposes 37 HTTP routes and 3 WebSocket endpoints. See the API Specsheet for the complete route catalog.
Quick reference:
| Category | Endpoints | Description |
|---|---|---|
| System | GET /, GET /stats, GET /healthz |
Daemon identity, stats, health check |
| Containers | 9 routes | Install, start, stop, kill, delete, status, stats, command |
| Backups | 5 routes | Create, restore, delete, download, upload |
| Filesystem | 13 routes | List, read, write, upload, download, zip, rename, etc. |
| SFTP | 3 routes | Credentials create/revoke, status |
| Minecraft | 1 route | Player list query |
| Radar | 2 routes | Security scan, zip results |
| WebSocket | 3 endpoints | Console, status, lifecycle events |
# Install deps
bun install
# Run tests
bun test
# Typecheck
bunx tsc --noEmit
# Build for production
bun run build┌──────────────┐ HTTP/HMAC ┌──────────────┐ Docker API ┌──────────────┐
│ Browser │ ──────────────────▶ │ Panel (Bun) │ ──────────────────▶ │ Daemon (Bun) │
│ │ ◀─── session/cookie │ Port 3000 │ ◀─── JSON responses │ Port 3002 │
└──────────────┘ └──────────────┘ └──────┬───────┘
│
┌─────▼──────┐
│ Docker │
│ Containers │
└────────────┘
The panel is the brain. The daemon is the hands. Together, they run your game servers -_-
- Panel: github.com/airlinklabs/panel
- Website: airlinklabs.xyz
- Docs: airlinklabs.xyz/docs/quick-start
- Discord: discord.gg/ujXyxwwMHc
MIT — see LICENSE for details.