Plan 55 Phase 4. EXTENSIONS.md said `permissions` is "**enforced** by the SDK gate: require_permission(slug, "docker") raises unless docker is declared". That sentence is true about the function and misleading about the system: the gate only fires where something calls it, and nothing routes Docker through it. The SDK exposes no docker, shell, filesystem or network helper at all, and hands out `db` as raw SQLAlchemy, so an extension that wants any of them imports the host module directly and no in-process check is involved. Declaring `docker` does not stop an extension using Docker, and not declaring it does not either. Both documents now state which capabilities are actually mediated -- today `agent.command:<action>` and nothing else, because the SDK is the only route to an agent -- in a per-capability table, and say plainly what declaring does instead: it tells the operator at install time what the extension claims to need, and lets them refuse. SECURITY.md gains an Extension Trust Model section next to the agent one. It leads with the part that matters most and was never written down: an extension is in-process code running with the panel's privileges against the panel's database, nothing sandboxes it, and no permission string changes that. Signing and sha256 pinning are described for what they are -- integrity of what you installed, not containment of what it does -- along with the unsigned-prompts, bad-signature-fails split, and the pip opt-in. It also explains why the new detail page reports "cannot be observed" rather than a zero count for unenforceable permissions: absence of evidence is not evidence of absence, and a "never used" badge there would imply a boundary that does not exist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ServerKit Documentation
Welcome to the ServerKit documentation. This guide will help you install, configure, and use ServerKit effectively.
Quick Links
| Document | Description |
|---|---|
| Installation Guide | Complete setup instructions for Docker and manual installation |
| Architecture | System design, request flow, and diagrams |
| Deployment Guide | Production deployment, CLI commands, and configuration |
| Local Development | Run the panel locally for development |
| API Reference | REST API documentation with examples |
| Multi-Environment Guide | Set up prod/dev WordPress pairs with shared database |
| Multi-Server & Agent | Install the agent and connect remote servers (see also pairing) |
Getting Started
1. Installation
Choose your preferred installation method:
- Docker Installation (Recommended) - Get started in minutes
- Manual Installation - Full control over the setup
- One-Line Install - One-line installer for Ubuntu, Debian, Fedora, and RHEL/Rocky/AlmaLinux
2. Initial Setup
After installation:
- Access ServerKit at
http://your-server-ip - Create your admin account (first user becomes admin)
- Enable Two-Factor Authentication
- Configure Notifications
3. Start Managing
- Add your first application from the Applications page
- Configure domains and SSL certificates
- Set up monitoring alerts
- Enable security scanning
Feature Guides
Application Management
ServerKit supports multiple application types:
| Type | Runtime | Process Manager |
|---|---|---|
| PHP / WordPress | PHP-FPM 8.x | Nginx |
| Python (Flask/Django) | Python 3.x | Gunicorn |
| Node.js | Node 18+ | PM2 |
| Docker | Containers | Docker Engine |
Each application includes:
- Environment variable management (encrypted)
- Log viewing and streaming
- Start/stop/restart controls
- Domain and SSL configuration
Multi-Environment Support
ServerKit supports multi-environment linking for WordPress and other applications:
- Production/Development Pairs - Link apps as prod/dev environments
- Shared Database - Both environments can share the same MySQL database with different table prefixes
- Environment Badges - Visual indicators (PROD/DEV/STAGING) in the UI
- Quick Navigation - One-click switching between linked environments
- Credential Propagation - Automatically share database credentials between linked apps
Common use case: WordPress theme development
- Production WordPress serves live traffic
- Development WordPress shares the database (separate tables)
- Develop themes in dev without affecting production
See the Multi-Environment Setup Guide for detailed instructions.
Domain & SSL
- Nginx Virtual Hosts - Automatic configuration generation
- Let's Encrypt SSL - Free certificates with auto-renewal
- Custom Certificates - Upload your own SSL certificates
Database Management
Supported databases:
- MySQL / MariaDB
- PostgreSQL
Features:
- Create/delete databases
- User management
- Basic query interface
Monitoring & Alerts
Real-time monitoring includes:
- CPU, RAM, disk usage
- Network traffic
- Server uptime history
- Process monitoring
Alert channels:
- Discord webhooks
- Slack webhooks
- Telegram bot
- Generic HTTP webhooks
Security
- Two-Factor Authentication - TOTP-based (Google Authenticator, Authy)
- Malware Scanning - ClamAV integration
- File Integrity Monitoring - Detect unauthorized changes
- Firewall Management - UFW rule configuration
Scheduled Tasks
- Visual cron job editor
- Execution history
- Enable/disable jobs
- Common schedule presets
Configuration
Environment Variables
ServerKit is configured via environment variables. See .env.example for all options.
Required variables:
SECRET_KEY=your-secret-key
JWT_SECRET_KEY=your-jwt-secret
Database options:
# SQLite (default)
DATABASE_URL=sqlite:///serverkit.db
# PostgreSQL (production)
DATABASE_URL=postgresql://user:pass@localhost/serverkit
Notification Setup
Configure webhooks in Settings > Notifications or via environment:
DISCORD_WEBHOOK_URL=https://discord.com/api/webhooks/...
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/...
TELEGRAM_BOT_TOKEN=your-bot-token
TELEGRAM_CHAT_ID=your-chat-id
CLI Reference
ServerKit includes a management CLI:
# Service Management
serverkit start|stop|restart|status
serverkit logs [backend|frontend]
serverkit update
# User Management
serverkit create-admin
serverkit reset-password
serverkit list-users
# Database
serverkit init-db
serverkit migrate-db # Apply schema updates
serverkit backup-db
serverkit restore-db <file>
# App Management
serverkit list-apps # List all installed apps
# Cleanup Commands
serverkit cleanup-apps # Delete all apps and containers
serverkit cleanup-apps --delete-volumes # Also delete Docker volumes
serverkit factory-reset # Complete reset (delete everything)
# Utilities
serverkit generate-keys
serverkit config
See Deployment Guide for complete CLI documentation.
API Reference
ServerKit provides a REST API for automation and integration.
Base URL: http://localhost:47927/api/v1
Authentication: JWT Bearer tokens
Quick example:
# Login
curl -X POST http://localhost:47927/api/v1/auth/login \
-H "Content-Type: application/json" \
-d '{"username": "admin", "password": "password"}'
# Use token
curl http://localhost:47927/api/v1/system/stats \
-H "Authorization: Bearer <token>"
See API Reference for complete documentation.
Troubleshooting
Common Issues
Container won't start:
docker compose logs backend
sudo lsof -i :47927
502 Bad Gateway:
sudo systemctl status serverkit
sudo tail -f /var/log/serverkit/error.log
ClamAV not working:
sudo freshclam
sudo systemctl restart clamav-daemon
See Installation Guide - Troubleshooting for more solutions.
Additional Resources
- Main README - Project overview and quick start
- Roadmap - Development plans and upcoming features
- Contributing Guide - How to contribute
- GitHub Issues - Report bugs or request features
Support
- Bug Reports: GitHub Issues
- Feature Requests: GitHub Issues with
enhancementlabel - Security Issues: Please report privately via GitHub Security Advisories
ServerKit Documentation
Version 1.6.7