ServerKit installation and host management with a modern control panel

ServerKit's single-server control surface

ServerKit targets administrators who want a graphical interface for applications, databases, Docker containers, and services on a VPS or dedicated server. Its documented feature set covers web apps, security, and deployment workflows. This is a server administration panel, not a general developer CLI, and not a cluster orchestrator. The project explicitly positions itself as an alternative to the complexity of Kubernetes and managed platforms, although the README does not provide a feature-by-feature comparison with either category.

The project is built with a Python and Flask backend and a React frontend. It is aimed at people who can already operate Linux servers but want less direct interaction with configuration files and service commands. The supported platforms listed for the one-line installation are Ubuntu 22.04 and later, Debian 12 and later, Fedora, and RHEL, Rocky, or AlmaLinux 9 and later. The README does not list a lightweight distribution such as Alpine Linux.

The repository layout contains installers, deployment assets, templates, documentation, and a `serverkit` executable. That separation is significant. ServerKit can be installed directly on the host, where it can work with systemd and host nginx, or run as a container, where those host-level responsibilities are deliberately unavailable. Choosing the installation topology is therefore the first adoption decision.

Flask, React, Gunicorn, and deployment feedback

Based on the repository layout and `docker-compose.yml`, the Flask backend owns the panel API, while the React frontend supplies the browser interface. The Docker topology packages both into one image. Gunicorn serves the API, React assets, and Socket.IO websockets from a single container on port 5000. This arrangement reduces the number of services required for a small deployment, but it also concentrates panel availability in one process topology.

Application deployment has two documented paths. A user can select one of the bundled templates, check server capacity, and follow a live build. The template walkthrough specifically shows the AgentSite template moving from the catalog to a live build. The second path connects an existing Git repository, reviews detected settings, and deploys it through the New Service wizard. Auto-deploy is included in that walkthrough after repository connection and settings review.

ServerKit also includes Nginx, Let's Encrypt, Docker, and Python integration, but the Compose deployment does not include nginx inside the container. An operator already running Caddy, Traefik, Nginx Proxy Manager, or another reverse proxy is expected to forward traffic to port 5000 and configure `SERVERKIT_PUBLIC_URL` and `TRUST_PROXY_HEADERS`. The README does not describe the internal deployment request format in enough detail to assess every supported application type.

Installing ServerKit directly on the host

The README calls the one-line installer the recommended option. It sets up ServerKit automatically on the documented Linux distributions. If the application is being put behind a domain, `PANEL_DOMAIN` can be supplied, and the installer attempts to obtain a Let's Encrypt certificate. Installation time still depends on the server, network, and required packages.

Run the documented installer as follows:

curl -fsSL https://serverkit.ai/install.sh | bash

The README also shows the host installer with `sudo`, and `docker-compose.yml` gives that form when managing the same machine:

curl -fsSL https://serverkit.ai/install.sh | sudo bash

The second form is the relevant choice for a panel that needs access to host systemd, nginx, host packages, and managed site vhosts. The first command appears in the Quick Start, but the README does not explain whether the script prompts for privilege elevation. That difference matters for a first installation and should be checked against `docs/INSTALLATION.md` before execution.

For a first real workflow after installation, open the panel, choose a bundled template, review the capacity check, and start the deployment. The documented demonstration expects the AgentSite template catalog, a deployment drawer, the capacity result, and a live build. That is a more informative initial path than deploying an arbitrary repository before confirming how settings are detected.

Running ServerKit through Docker Compose

The container route builds the frontend with Node 22, installs Python dependencies in a separate build stage, and combines the resulting assets and backend in the panel image. Before starting it, copy the example environment file and replace the example secrets.

git clone https://github.com/jhd3197/ServerKit.git
cd ServerKit
cp .env.example .env
docker compose up -d

After editing `.env`, the panel is available at the documented URL:

http://localhost:5000

The environment file requires unique production values for `SECRET_KEY` and `JWT_SECRET_KEY`, plus `SERVERKIT_ENCRYPTION_KEY` for encrypting stored secrets. It also documents SQLite as the default, with PostgreSQL recommended for production. Under Docker, the Compose configuration pins the database path to a persistent volume and gives `SERVERKIT_DATABASE_URL` precedence if another database is required. The container always listens on 5000, while the host port can be changed through `SERVERKIT_HTTP_PORT`.

The major limitation is architectural. `docker-compose.yml` states that a containerized ServerKit cannot manage its own host because it has no systemd, host nginx, or host package control. It is intended for demonstrations, driving other servers through agents, or running behind an independent reverse proxy. It cannot create or manage site vhosts on the machine hosting the panel.

ServerKit updates, rollback, and operating costs

ServerKit documents an update command through its CLI:

sudo serverkit update

The README describes this as an atomic blue and green update with pre-flight checks, a database backup, schema migration, and automatic rollback. Operators can preview an update with `--dry-run`, request the development channel with `--branch dev`, or select a release tarball with `--release [version]`. The documentation does not describe disk requirements, expected downtime, migration duration, or how application containers behave during the switchover.

The repository was not archived, and its last push was on 2026-10-11. Recent release records include `v1.11.20` and a development build named `v1.11.21-dev.90c8fb0`, both dated on 2026-10-11. Those records show recent project activity, but they do not establish long-term release stability or guarantee that every upgrade path will be smooth.

The MIT license permits use, modification, distribution, and sublicensing under its conditions. The README reports no subscription or seat fees. Server ownership still creates operational costs: backups, certificate renewal, storage growth, security updates, and recovery testing remain outside the zero-license-fee claim. Operators must also account for the panel's access to privileged host services, especially when using the direct installer.

Security scanning, database choices, and failure points

The Docker image can optionally include ClamAV through the documented `INSTALL_CLAMAV` build argument. It is disabled by default. Without it, malware scanning falls back to a built-in YARA and pure-Python matcher, and the panel reports `clamav_available=false`. This is graceful degradation rather than a hard startup failure, but operators should not mistake the fallback for ClamAV coverage.

Several deployment failures are foreseeable from the documented topology. Starting from the Docker image and expecting host systemd or nginx management will fail because those interfaces are not present. Placing the panel directly on port 5000 behind an existing proxy without setting the public URL and trusted proxy behavior can also produce incorrect client-facing URLs or request interpretation. The available `docker-compose.yml` does not show every environment variable or health check.

The database configuration also changes with topology. A relative SQLite path can disappear during container recreation unless it is backed by a persistent volume. The Compose comments therefore override `DATABASE_URL` with a persistent path and reserve `SERVERKIT_DATABASE_URL` for an external database. This complexity is manageable, but it must be understood before treating the panel database as disposable demo state.

Cloudflare, DNS, Let's Encrypt, and security management appear in the project's topics and feature set, but the README does not document a complete DNS provider setup or rollback procedure for every managed service. Those areas require direct inspection of the relevant documentation before production use.

ServerKit versus direct Linux administration and Kubernetes

The direct Linux alternative is to administer nginx, systemd, databases, containers, certificates, and application configuration through the operating system's files and commands. That approach avoids installing a privileged control panel and gives direct control over every service, but it also leaves interface design, status presentation, deployment checks, and routine operations to the administrator. ServerKit packages those tasks into a browser workflow, at the cost of another application and a new administrative surface.

Kubernetes follows a different approach. It describes application deployment through declarative resources and cluster controllers rather than direct host-level management. The README explicitly contrasts ServerKit with Kubernetes complexity and managed-platform cost. That comparison should not be interpreted as feature parity. The README does not demonstrate multi-node scheduling, failover, desired-state reconciliation, or cluster autoscaling in ServerKit.

The more relevant alternative for a small deployment may therefore be direct Linux administration when there is only one application or when the operator already has standardized scripts. ServerKit becomes more useful as the number of applications, databases, containers, and services on one VPS grows enough that a shared interface reduces repeated manual work. Its capacity check during template deployment also acknowledges that server capacity remains a deployment constraint.

Editorial conclusion

Adopt ServerKit for a single VPS or dedicated server when its detected workflow matches your applications and you want a graphical interface. Do not choose its container deployment for host management. Verify the supported operating system, generated secrets, deployment template, TLS arrangement, and update behavior before installing it on a server with existing services.

Frequently asked questions

Official sources

1. jhd3197/ServerKit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases