Resources
Live CPU, memory, disk, Docker storage and service health for this server.
Memory Distribution
CPU Usage by Container
Disk Usage Explorer (scanning...)
| Name | GB | MB | % | Bar |
|---|
Docker disk by container
(scanning...)Docker cleanup
| File | Type | GB | MB | % | Bar |
|---|
Services
Container Resource Usage
Server & security
Configure the domain, SSL certificate, and security for your ServerPilot dashboard.
Enter the domain where ServerPilot will be accessible.
Email for Let's Encrypt SSL registration (required for certificate issuance).
Obtain an SSL certificate via Let's Encrypt for your dashboard domain.
Redirect HTTP to HTTPS for ServerPilot's domain only. Other sites on port 80 are not affected. You can toggle this on/off.
Return a plain 404 for domains that do not match an enabled site, instead of exposing the dashboard login.
Require a 6-digit authenticator code during dashboard login.
Edit the main Nginx config, run nginx -t, or apply safe automatic repairs (for example server_names_hash_bucket_size).
Review current dashboard sessions and revoke stale devices.
Allow dashboard login with a one-time code delivered by Email Sender.
Terminal
Session closes after 10 minutes of inactivity. Re-authentication required to connect.
How deployment works
Repository and container imageDockerfile, build context, port and image naming
Each application is linked to exactly one synchronized repository. Configure a valid Dockerfile path, build context and container port.
The workflow must publish ghcr.io/{owner}/sp-{repository}-{application}:{version-tag}. ServerPilot resolves and deploys the immutable digest, never latest.
GitHub Actions workflowBuild and publish one image per application
Copy the workflow generated by ServerPilot into .github/workflows/. It runs for semantic version tags and uses the Dockerfile and build context configured for that application.
The workflow publishes the required OCI labels and must never include runtime variables or secrets inside the image.
Environments and runtime configurationTest, Staging or Production with isolated variables
Every application needs at least one environment. Each environment selects its server, domain, Nginx and SSL options, health check and automatic deployment policy.
At deploy time ServerPilot loads project variables first and environment variables second, so the environment overwrites duplicate keys. Secrets stay encrypted and are resolved only in memory.
Version, deployment and rollbackRelease detection, health checks and safe activation
A repository version is shared by every linked application, while each application has its own image artifact. ServerPilot waits for GHCR to return the image digest before deploying.
Deployments can be manual, triggered by a semantic version tag, or triggered by a published GitHub Release. ServerPilot verifies health, uses blue-green switching when Nginx is enabled, and rolls back to a previously successful digest.