Deploying a Docker Application

Docker apps on ServerPlane support two deployment modes: pre-built templates for popular self-hosted software, and custom deployments using your own Docker image or a Git repository containing a docker-compose.yml. All Docker apps are served through a web server that routes your domain to the container.

Pre-Built Templates

When you select "Docker" as the app type, the wizard presents a template picker with ready-to-deploy applications:

Template Description Mode
n8n Workflow automation tool Image
Uptime Kuma Self-hosted monitoring Image
Ghost Publishing platform Image
Gitea Lightweight Git hosting Image
Metabase Business intelligence & analytics Image
MinIO S3-compatible object storage Image
Portainer Docker management UI Image
WordPress (Docker) WordPress + MariaDB in containers Image
Plausible Privacy-friendly web analytics Git
Dify LLM app development platform Git

Selecting a template pre-fills the Docker image (or Git repo), internal port, volumes, and environment variables. You only need to provide an app name and domain.

You can also select Custom to deploy your own image or Git repository.

Deployment Steps

  1. Navigate to Apps > Deploy Application.
  2. Select a server with an "Active" status.
  3. Choose "Docker" as the application type.
  4. Configure the app:
    • App Name — a human-readable label.
    • Domain — DNS must already point to your server.
    • Template or Custom — pick a pre-built template, or select "Custom" and provide:
      • Docker Image — e.g., nginx:latest, myregistry/myapp:v2.
      • Git Repository — URL to a repo containing a docker-compose.yml.
      • Branch — defaults to main.
      • Docker Compose Directory — subdirectory containing the compose file (auto-detected if left blank).
      • Internal Port — the port the container exposes internally. Auto-detected from the image's EXPOSE directive if not specified.
    • Host Port — automatically assigned to avoid conflicts with other apps.
  5. Review and click Deploy.

Repo Analysis

When you provide a Git repository URL, the wizard can analyze the repository before deployment. It fetches the docker-compose.yml to show you:

  • Number of services and their images
  • Port mappings
  • Whether any service binds to port 80/443 (which may conflict with the web server)
  • Environment variables from .env.example

What Happens During Deployment

  1. Required server software is installed if not already present.
  2. Image-based deploys: the image is pulled, the internal port is auto-detected (if not explicitly set), and a compose configuration is generated.
  3. Git-based deploys: the repository is cloned and the compose file is located automatically. If a .env.example exists, it is copied to .env with platform-managed variables injected.
  4. The container(s) are started.
  5. A web server configuration is created to route your domain to the app.

Container Management

From the app's detail page, you can:

  • Start / Stop / Restart — controls the Docker Compose project.
  • Rebuild — rebuilds all containers from scratch and restarts them.
  • Pull — pulls the latest image(s) and recreates containers.
  • Prune — removes unused Docker images and volumes on the server.

Environment Variables

For image-based deploys, environment variables are configured automatically in the container setup.

For Git-based deploys, variables set through the Environment tab are written to a .env file that Docker Compose reads automatically.

Template-based deployments pre-configure secrets (database passwords, API keys) with randomly generated values.

Notes

  • The host port is auto-assigned to avoid conflicts between apps on the same server.
  • Private GitHub repositories are supported with automatic deploy key setup.
  • Environment variables can be managed through the Environment tab on the app detail page.
  • SSL can be provisioned after deployment via the Domains & SSL tab.
  • Multi-service apps (e.g., Dify, Plausible) may take longer to start. The deployment will continue even if the health check times out — check container logs from the terminal if needed.