Skip to main content
Pterodactyl Wings uses Docker as its container runtime to provide isolation, resource management, and consistent environments for game servers. Each server runs in its own Docker container with carefully configured security and resource constraints.

Why Docker?

Wings exclusively uses Docker for several key reasons:
  • Isolation - Each server runs in an isolated environment
  • Resource Control - CPU, memory, and I/O limits are enforced
  • Security - Containers provide security boundaries
  • Consistency - Same environment across different host systems
  • Image Management - Easy distribution of game server environments
Currently, Wings only supports Docker as an environment. The architecture allows for other environments in the future, but Docker is hardcoded in server initialization (server/manager.go:204-206).

Docker Environment Structure

Each server has a Docker environment that manages its container lifecycle.

Environment Type

Container Naming

Containers are named using the server’s UUID:

Container Creation

Wings creates containers with specific configurations for security and functionality.

Container Configuration

Key Settings:
  • TTY enabled - Allows interactive console access
  • Stdin open - Enables command sending
  • Exposed ports - Defined by server allocations

User Configuration

Containers run as a specific user for security:
This ensures server processes don’t run as root inside containers.

Host Configuration

Security Features:
  • Read-only root filesystem - Prevents tampering with container OS
  • Dropped capabilities - Removes unnecessary Linux capabilities
  • no-new-privileges - Prevents privilege escalation
  • tmpfs /tmp - Writable temporary directory in memory

Resource Limits

Docker enforces resource limits to prevent servers from consuming excessive resources.

Resource Types

Applying Limits

Limits are converted to Docker resource constraints:

In-Situ Updates

Limits can be updated without restarting the container:
CPU pinning and memory limits cannot be removed once applied - the container must be recreated.

Networking

Wings configures networking to expose server ports and control traffic.

Port Bindings

Server allocations are mapped to container ports:
Both TCP and UDP ports are exposed for each allocation.

Network Modes

Wings supports different network configurations: Bridge Mode (Default):
Force Outgoing IP: When enabled, creates a dedicated bridge network per server:

Internal IP Translation

The Panel uses 127.0.0.1 as a placeholder, which Wings translates:

Container Lifecycle

Container Attachment

Before starting, Wings attaches to the container for I/O:
The attachment goroutine:
  1. Polls container resource usage
  2. Reads console output
  3. Calls the log callback (sends to websockets)
  4. Automatically cleans up when container stops

Container Starting

The start sequence ensures everything is ready:
Attachment must occur before starting the container. Reversing this order causes a deadlock.

Container Destruction

When a server is deleted, its container is removed:

Image Management

Wings automatically pulls Docker images when needed.

Image Pulling

Fallback Behavior: If the image pull fails but the image exists locally (e.g., during registry outage), Wings uses the local copy and logs a warning.

Registry Authentication

Wings supports private registry authentication configured in config.yml:

Mounts and Volumes

Wings mounts the server’s data directory into containers:
Primary Mount:
Additional mounts can be defined for shared libraries or configurations.

Console I/O

Sending Commands

Commands are sent through the attached stream:

Reading Logs

Historical logs are retrieved from Docker:

Container Recreation

Containers are recreated on every start to apply configuration changes:
This ensures that environment variables, resource limits, and other settings are always current.

Next Steps

Architecture

Understand the overall system architecture

Server Lifecycle

Learn about server states and transitions

File Management

Explore filesystem operations