Setting Up Your Server Panel

The server panel is the administrative control plane for a self-hosted Unturned™ game-server estate. It is the interface through which operators start and stop server instances, deploy game files, configure resource limits, manage player lists, view console output, and provision access for team members. It is also the component that, if misconfigured, can take down every server instance simultaneously, expose a root-equivalent shell to an improperly scoped user, or leave the estate in an unrecoverable state after a failed update.

57 Studios™ treats the server panel as a critical administrative tool that benefits from careful change management, well-documented permission boundaries, and a tested restore procedure prepared before the first production change is applied. This article documents the reference panel installation, the change management practices, the permission model, the TLS configuration, the backup and restore procedures, and the monitoring integration that together support a reliable, auditable administrative control plane.

Nothing in this article assumes that configuration changes are risk-free. Every configuration change to the panel carries a documented probability of unintended side effects. The documented practice is to understand that probability, reduce it through staging and testing, and have a verified restore path ready for the cases where the unintended side effect occurs.

Prerequisites

• A self-hosted server estate with storage architecture documented per Data Redundancy and Storage Architecture
• Network infrastructure documented per Network Infrastructure and Switching
• A documented Linux host for the panel software (Ubuntu 22.04 LTS or Debian 12 are the documented reference distributions; the panel software's own documentation takes precedence on supported versions)
• A documented domain name with DNS records pointing to the panel host
• A documented certificate authority — either a Let's Encrypt ACME account or an internal CA — for TLS provisioning
• Root or sudo access on the panel host for the initial installation

What you'll learn

• What a server panel does and the documented role it plays in game-server lifecycle management
• The panels in active use among professional operators: Pterodactyl, RocketNode, AMP, and TCAdmin
• The documented installation phases: prerequisites, panel software install, daemon setup, network binding, TLS certificate, and first admin user
• Change management best practices: staging, configuration baselines, tested restore procedures
• Permission boundaries: separating panel-user accounts from system-level access
• TLS configuration: Let's Encrypt vs internal CA
• Backup of panel configuration: nightly DB export, settings export, user table export
• Standard restore procedure walkthrough
• Health-check endpoints and monitoring integration
• Audit logging
• Selecting the right panel for the documented estate profile

What a server panel does

A server panel is a web-based administrative interface that translates operator actions into system-level operations on the underlying server nodes. The core functions of a server panel as they apply to an Unturned estate are:

Game-server lifecycle management: starting, stopping, restarting, and killing individual game server instances or groups of instances. The panel issues the underlying systemctl or direct process commands; the operator never touches the command line for routine lifecycle operations.

File management: uploading, downloading, editing, and deleting files within each server instance's documented file tree. The panel enforces documented path restrictions so that a panel user with access to server instance A cannot access the files of server instance B or the underlying host's system files.

Console access: attaching to the live console output of a running game server and sending commands to the game server's stdin. This is the primary tool for in-game administration without a direct SSH connection to the host.

Resource allocation: setting CPU affinity, memory limits, and disk quotas per server instance. The panel enforces resource limits at the container or cgroup level, preventing a single server instance from exhausting the host's resources at the expense of other instances.

User and permission management: creating panel accounts for team members, assigning each account to the documented server instances it can manage, and setting the permission level (view-only, operator, administrator) for each assignment.

Automated scheduled tasks: configuring recurring actions (scheduled restarts, scheduled backups, scheduled update checks) that execute without operator intervention.

Did you know?

A server panel is not a server in itself. It is a management layer that communicates with a daemon process running on each node. The daemon is the component with actual access to the host's process management, filesystem, and network interfaces. The panel UI communicates with the daemon over an authenticated API. Understanding this separation is the foundation of the panel permission model.

Panels in active use: a matter-of-fact comparison

Four panels are in active use among professional self-hosted Unturned server operators. The selection of a panel is an operational decision based on the estate profile, the team's technical depth, and the documented features required. No single panel is the correct choice for all estates.

Panel	License	Deployment model	Documented strengths	Documented considerations
Pterodactyl	MIT (open source)	Self-hosted; Wings daemon per node	Mature open-source ecosystem; Docker-based isolation per instance; strong community documentation; no per-server licensing cost	Requires Docker on all node hosts; installation is multi-step (panel + wings + database + reverse proxy); configuration learning curve
RocketNode	Commercial SaaS	Hosted control plane; agent on self-hosted nodes	Minimal self-hosted infrastructure for the control plane; managed updates to the panel itself	Dependency on external SaaS availability; some operators prefer fully self-contained architectures
AMP (Application Management Panel)	Commercial (per-instance licensing)	Self-hosted	Strong game-specific template library; built-in module system; documented support for non-game server types	Per-instance licensing cost; commercial support dependency
TCAdmin	Commercial (per-server licensing)	Self-hosted	Long-established market presence; documented reseller ecosystem	Older architecture; per-server licensing; some operators find the UI less modern than alternatives

The documented 57 Studios reference is Pterodactyl for self-hosted estates that prioritize open-source auditability, Docker-based instance isolation, and a no-per-instance-licensing cost model. The comparison table above documents the panels matter-of-factly; the right choice depends on the specific estate profile and operational requirements.

Best practice

Before selecting a panel, document the specific administrative functions the estate requires and verify each candidate panel against that documented list. A panel that is technically capable but missing a required function (scheduled tasks, API access, multi-node support) will require workarounds that add operational complexity.

Installation phases

The panel installation proceeds through six documented phases. Each phase has a documented completion criterion; the next phase begins only when the current phase's criterion is met.

Phase 1: Prerequisites

The prerequisites phase provisions the documented dependencies on the panel host. For a Pterodactyl installation, the documented prerequisites are:

• PHP 8.1 or newer with documented extensions: cli, openssl, gd, mysql, mbstring, bcmath, xml, curl, zip
• Composer (PHP dependency manager)
• MySQL 8.0 or MariaDB 10.3 or newer for the panel database
• Redis for the panel's queue worker and session cache
• Nginx or Apache as the documented reverse proxy for the panel web application
• Node.js 16 or newer for the panel's asset build pipeline (install-time only; not a runtime dependency)

The prerequisites are installed from the distribution's documented package manager. Each installation is verified against the documented version requirement before the next step proceeds.

Pro tip

Perform the prerequisites installation on the staging panel host before the production host. The staging environment surfaces package-version conflicts and configuration edge cases before they affect the production panel. Document the exact package versions installed on the staging host; use the same versions on the production host.

Phase 2: Panel software installation

The panel software is installed from the project's documented release archive. The documented procedure follows the upstream installation documentation precisely; do not improvise steps or skip verification checkpoints.

The installation proceeds through:

1. Creating the documented panel user and directory (/var/www/pterodactyl for Pterodactyl)
2. Downloading the documented release archive and verifying its documented checksum
3. Running composer install to install PHP dependencies
4. Copying the documented environment configuration file (.env)
5. Generating the documented application encryption key (php artisan key:generate)
6. Running the documented database migrations (php artisan migrate --seed)
7. Creating the first administrative user (php artisan p:user:make)

The completion criterion for this phase is a verified first login to the panel web interface on localhost before the reverse proxy and TLS are configured.

Common mistake

Running the panel installation directly on the production host without first validating the procedure on a staging host. An installation that fails mid-way can leave the panel in an inconsistent state that requires a documented restore. Run the full procedure on staging first, document the exact steps and outputs, and use that documentation as the production installation runbook.

Phase 3: Daemon setup

For Pterodactyl, the Wings daemon is installed on each node host (not the panel host, unless the panel and the first node are co-located). Wings is the component that the panel communicates with to manage server instances on that node.

Wings requires Docker on the node host. The documented Docker installation follows the official Docker documentation for the node host's distribution. The Wings daemon itself is installed as a documented systemd service with the documented configuration file pointing to the panel's documented API endpoint and the documented authentication token issued by the panel.

The completion criterion for this phase is a documented green connection status on the node's entry in the panel's Nodes administration page.

Phase 4: Network binding

The panel web application listens on the documented loopback address by default. The reverse proxy (Nginx or Apache) is configured to accept external HTTPS requests on port 443 and proxy them to the panel's local listener. The Wings daemon listens on the documented port (8080 by default) and is accessible from the panel host on the node's documented management IP.

The network binding configuration documents the following:

• Panel web application: listen on 127.0.0.1:80 (local only; reverse proxy handles external traffic)
• Reverse proxy: listen on 0.0.0.0:443, proxy to 127.0.0.1:80
• Wings daemon: listen on the node host's documented management IP, port 8080 (or the documented alternative port)
• Wings daemon TLS: documented certificate for the Wings listener endpoint

The completion criterion for this phase is an externally verified HTTPS connection to the panel on port 443 from the documented management workstation.

Phase 5: TLS certificate

The TLS certificate secures the HTTPS connection between the operator's browser and the panel, and between the panel and the Wings daemon. Two documented certificate sources are in use:

Let's Encrypt (Certbot): issues a publicly trusted certificate for a domain name with documented DNS resolution. The certificate is renewed automatically through the ACME protocol. Appropriate when the panel is accessible from the public internet or from clients that do not trust a custom internal CA.

Internal CA: issues a certificate signed by the documented internal certificate authority. The certificate must be distributed to all clients that need to trust the panel TLS. Appropriate when the panel is accessible only from the documented internal management network and all clients are enrolled in the internal CA trust store.

The 57 Studios reference for the panel host is Let's Encrypt, because the panel management interface is accessed from the operations team's workstations which may not all be enrolled in the internal CA. The Wings daemon certificates use the internal CA because the panel-to-Wings communication is exclusively on the documented internal management network.

Best practice

Document the TLS certificate expiration dates and renewal procedures for both the panel and the Wings daemon certificates in the operations console binder. Let's Encrypt certificates expire every 90 days; automated renewal with Certbot reduces the operational overhead but does not eliminate the need to monitor renewal status. A panel that becomes unreachable because a certificate expired is an avoidable operational incident.

Phase 6: First administrative user and initial configuration

The first administrative user is created during the software installation phase (Step 7). The initial configuration through the panel web interface documents the following:

1. Create the documented Locations (geographic groupings for nodes)
2. Create the documented Nodes (one per node host, pointing to the Wings daemon)
3. Allocate the documented IP/port ranges for server instances
4. Create the documented Server Eggs (Pterodactyl's term for game server templates, including the Unturned egg)
5. Create the documented first server instance and verify that it starts and stops correctly

The completion criterion for this phase is a documented running Unturned server instance visible in the panel, accessible from the documented player-facing IP and port.

Change management best practices

The server panel controls every server instance on the estate. A misconfigured network binding can make the panel unreachable. A misconfigured Wings daemon configuration can disconnect every node. A misconfigured server instance allocation can exhaust host resources. The documented change management practices are the operational framework that makes panel administration predictable.

Test in staging before applying to production

Every panel configuration change is tested in a documented staging environment before it is applied to the production estate. The staging environment mirrors the production configuration: same panel version, same Wings version, same server instance templates, same network topology (at a smaller scale). A change that produces the documented expected result in staging is applied to production with documented confidence.

The staging panel is a dedicated installation, not a test mode in the production panel. It runs on separate hardware or a separate virtual machine. The staging panel's Wings nodes are separate from the production Wings nodes.

Pro tip

After completing a staging test, write a documented change ticket with three fields: what the change is, what the expected result is, and what the tested rollback procedure is. Bring the change ticket and the rollback procedure to the production change window. If the change in production does not match the expected result, execute the rollback procedure immediately rather than attempting to diagnose the discrepancy under pressure.

Maintain a documented configuration baseline

A configuration baseline is a documented snapshot of the panel's configuration at a known-good state. The baseline is the reference point for rollback. Without a baseline, "rolling back" means guessing at what the configuration was before the change.

The documented baseline captures:

Baseline component	Documented capture method	Documented cadence
Panel database	mysqldump export	Nightly automated
Panel environment configuration (.env)	File copy to documented backup location	After each administrative change
Wings daemon configuration (config.yml) per node	File copy to documented backup location	After each administrative change
Server instance allocation list	Panel API export or panel database dump	Nightly automated
Panel user and permission table	Panel database dump (included in full DB export)	Nightly automated

The baseline files are stored in the documented configuration-backup directory and synchronized to the backup-storage tier documented in Data Redundancy and Storage Architecture.

Keep a tested restore procedure on hand for every configuration change

Before every configuration change is applied, the documented restore procedure for that change must be written, reviewed, and tested in staging. A restore procedure that has not been tested is a hypothesis, not a documented procedure. The operational record is consistent: untested restore procedures fail at the moments when they are most needed.

A documented restore procedure for a panel configuration change follows the format:

1. What is being changed (specific configuration parameter, file, or database record)
2. What the current value is (captured before the change is applied)
3. What the new value will be (the planned change)
4. How to verify the change is correct (the documented expected result)
5. How to revert the change (the exact steps, including the command or UI action, to restore the previous value)
6. How to verify the revert is complete (the documented expected result after revert)

The restore procedure is executed in staging before the production change window and the results documented. The staging test confirms both that the change produces the expected result and that the revert produces a clean known-good state.

Common mistake

Applying a panel configuration change and then writing the restore procedure based on what you remember the previous configuration to have been. Memory is not documentation. The current configuration value must be captured before the change is applied, not reconstructed afterward.

Permission boundaries

The panel permission model is the documented boundary between what panel users can do and what the underlying host operating system can do. A correctly configured permission model ensures that a panel user who makes an error (or whose account is compromised) cannot take actions beyond the documented scope of their role.

Panel-user account tiers

The documented 57 Studios panel permission model defines four account tiers:

Account tier	Documented permissions	Documented use case
Read-only viewer	View server status, console output, resource utilization; no control actions	On-call monitoring without intervention authority
Server operator	Start, stop, restart assigned servers; view and send console commands; view file tree	Routine operations staff
Server administrator	All operator permissions plus file management, scheduled task management, backup management	Senior operations staff
Panel administrator	Full panel administration including node management, user management, server creation/deletion	Documented restricted to senior engineering staff

The documented principle is to provision each panel account with the minimum permission tier required for the documented role. Panel administrator accounts are documented as the most sensitive; the number of panel administrator accounts is kept at the documented minimum (typically two: the primary administrator and a documented backup administrator).

Separating panel-user accounts from system-level access

A panel account grants access to the panel's documented function set. It does not — and must not — grant access to the underlying host's operating system. The separation is enforced at multiple layers:

Wings daemon containment: Pterodactyl's Wings daemon runs each server instance in a Docker container. A panel user with file management access to a server instance can read and write files within that container's documented file tree. The container's filesystem is isolated from the host's filesystem; the panel user cannot traverse out of the container to the host's system directories.

Panel host access control: the panel host's SSH service is restricted to documented key-based authentication from the documented management IP range. Panel accounts have no SSH access to the panel host; SSH access is granted only to the documented operations engineers with documented key pairs registered in the documented authorized_keys configuration.

Daemon API authentication: the Wings daemon authenticates requests from the panel using a documented token issued at node registration. The token grants the panel the ability to manage server instances on that node; it does not grant the panel general root access to the node host's operating system.

Best practice

Audit the panel user account list quarterly. Remove accounts that are no longer active (former team members, decommissioned integrations). Rotate the documented Wings daemon tokens annually. Document each account and its documented permission tier in the operations console binder and review the list against the current team roster at each quarterly audit.

Two-factor authentication for administrative accounts

All panel administrator accounts must have two-factor authentication (2FA) enabled. The documented 2FA method is a TOTP authenticator application (Authy, Google Authenticator, or equivalent). SMS-based 2FA is not used for administrative accounts in the reference 57 Studios configuration because SMS delivery is subject to documented SIM-swap and number-porting attacks that are outside the operator's control.

Server operator and server administrator accounts are documented as strongly recommended to use 2FA. The panel supports enforcing 2FA across all accounts at the administrator level; the reference configuration enforces 2FA for all accounts with server administrator tier or above.

TLS configuration in depth

The TLS configuration for the panel covers two distinct encrypted connections: the operator-to-panel HTTPS connection and the panel-to-Wings HTTPS connection.

Operator-to-panel TLS (Let's Encrypt)

The Let's Encrypt certificate for the panel's public domain is provisioned and renewed using Certbot with the documented Nginx plugin. The Certbot renewal is managed by a systemd timer that runs twice daily; the certificate is renewed automatically when it is within 30 days of expiration.

The documented Nginx TLS configuration applies the following settings:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:!DH+3DES:!ADH:!AECDH:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
add_header Strict-Transport-Security "max-age=31536000" always;

The TLS 1.0 and TLS 1.1 protocols are disabled; only TLS 1.2 and TLS 1.3 are permitted. The Strict-Transport-Security header enforces HTTPS for all subsequent connections from clients that have previously connected to the panel.

Panel-to-Wings TLS (Internal CA)

The Wings daemon on each node host presents a TLS certificate signed by the documented internal CA. The panel is configured to trust the internal CA's root certificate for Wings connections. The documented advantage of using an internal CA for Wings certificates is that the certificates do not expire on the 90-day Let's Encrypt cycle — internal CA certificates are issued with a 2-year validity period, reducing the documented renewal overhead for the Wings daemon across all node hosts.

The internal CA's root certificate is installed in the documented trust store on the panel host at provisioning time.

Pro tip

Maintain a documented certificate inventory that lists every certificate in use on the panel infrastructure, its issue date, its expiration date, the CA that issued it, and the documented renewal procedure. Review the inventory monthly. A certificate expiration that catches the operations team by surprise is a documented avoidable incident.

Backup of panel configuration

The panel configuration backup is the documented recovery foundation for the panel itself (separate from the game-server save-state backup documented in Data Redundancy and Storage Architecture). The panel configuration backup captures the administrative state of the panel: which servers exist, which users have access to what, what the scheduled tasks are, and what the node configurations are.

Nightly database export

The panel database is exported nightly using a documented mysqldump script:

#!/usr/bin/env bash
# panel-db-backup.sh
BACKUP_DIR="/var/backups/panel-db"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
FILENAME="panel_db_${TIMESTAMP}.sql.gz"

mysqldump \
  --single-transaction \
  --quick \
  --lock-tables=false \
  --user=pterodactyl \
  --password="$(cat /etc/panel-db-password)" \
  pterodactyl \
  | gzip > "${BACKUP_DIR}/${FILENAME}"

# Verify the export completed
if [ $? -eq 0 ]; then
  echo "Panel DB backup complete: ${FILENAME}"
else
  echo "ERROR: Panel DB backup failed" >&2
  exit 1
fi

# Expire backups older than 30 days
find "${BACKUP_DIR}" -name "panel_db_*.sql.gz" -mtime +30 -delete

The script runs as a documented systemd timer at 02:00 daily. The exported file is synchronized to the backup-storage tier by the documented ZFS send/receive pipeline.

Environment configuration and Wings configuration backup

The panel's .env file and each Wings node's config.yml are copied to the documented backup directory after each administrative change:

cp /var/www/pterodactyl/.env \
   /var/backups/panel-config/pterodactyl.env.$(date +%Y%m%d_%H%M%S)

# On each Wings node:
cp /etc/pterodactyl/config.yml \
   /var/backups/wings-config/config.yml.$(date +%Y%m%d_%H%M%S)

These configuration-file backups are not subject to automated expiration; the full history is retained to support rollback to any previously documented configuration state.

Standard restore procedure walkthrough

The following walkthrough documents the procedure for restoring the panel from a nightly database backup following a panel host failure. The procedure is documented at the operations console and tested in staging quarterly.

Step 1: Provision a replacement panel host

Provision a new host with the documented operating system (Ubuntu 22.04 LTS or Debian 12) and the documented panel prerequisites. This step follows the Phase 1 and Phase 2 installation procedures documented above.

Step 2: Restore the panel database

# Transfer the most recent backup to the new host
scp /var/backups/panel-db/panel_db_YYYYMMDD_HHMMSS.sql.gz \
    ops-user@new-panel-host:/tmp/

# On the new host:
gunzip -c /tmp/panel_db_YYYYMMDD_HHMMSS.sql.gz \
    | mysql --user=pterodactyl --password pterodactyl

Step 3: Restore the environment configuration

cp /var/backups/panel-config/pterodactyl.env.YYYYMMDD_HHMMSS \
   /var/www/pterodactyl/.env

Verify the application key in the restored .env matches the key used to encrypt the database. If the panel host is being restored from a backup of itself, the key will match. If the panel is being migrated to a new installation, regenerate and re-encrypt as documented in the Pterodactyl migration guide.

Step 4: Verify the panel reaches the restored state

php artisan cache:clear
php artisan view:clear
systemctl restart php8.1-fpm
systemctl restart nginx

Navigate to the panel web interface and verify:

• All documented server instances appear with their documented configurations
• All documented users appear with their documented permission assignments
• All documented nodes appear and show the correct Wings connection state

Step 5: Reconnect Wings nodes

The Wings daemon on each node host does not require reinstallation if the panel's application key has not changed. The node reconnects automatically when the panel comes back online. Verify the connection status for each node in the panel's Nodes administration page.

Elapsed time for a full panel restore from a nightly backup: documented at 25 to 40 minutes in the reference configuration, depending on the database size and the provisioning speed of the replacement host.

Did you know?

The game server instances on the Wings nodes continue running through a panel outage. The Wings daemon manages the instances directly; it does not require a live panel connection to maintain running instances. A panel host failure is an administrative outage, not a player-facing outage, as long as the Wings daemons remain operational.

Health-check endpoints and monitoring integration

The panel exposes a documented health-check endpoint at /api/health (Pterodactyl) or equivalent. The endpoint returns a documented JSON response indicating the panel application's health status, the database connection status, and the queue worker status.

The documented monitoring integration polls the health-check endpoint at the 60-second interval and alerts the operations team if:

• The HTTP response code is not 200
• The documented JSON response indicates any component is unhealthy
• The response latency exceeds the documented threshold (500 ms in the reference configuration)

Additionally, each Wings node exposes a health-check endpoint at its documented API port. The panel polls each Wings node's health at the documented interval; a Wings node that goes offline triggers a documented P1 alert.

Audit logging

The panel's audit log records every administrative action taken through the panel interface: user logins, server starts/stops, file operations, configuration changes, user account modifications, and node configuration changes. The audit log is the documented source of truth for "what changed and who changed it."

The documented audit log configuration retains log entries for a minimum of 90 days in the panel database and exports the log to the documented centralized log store daily. The centralized log store retains audit log entries for 12 months.

The documented fields captured in each audit log entry are:

Field	Documented value
Timestamp	UTC timestamp to millisecond precision
Actor	Panel username of the account that performed the action
Actor IP	IP address of the client that initiated the action
Action	Documented action identifier (e.g., server:start, user:update, node:configuration)
Target	The resource affected (server instance ID, user account, node ID)
Before state	Documented configuration value before the action (for configuration changes)
After state	Documented configuration value after the action (for configuration changes)
Result	Success or documented failure with error message

Pro tip

Review the audit log weekly during the first 90 days of a new panel installation. Patterns that indicate misconfiguration (repeated failed login attempts, unexpected configuration changes from unfamiliar IPs, unauthorized server stop/start cycles) surface in the audit log before they cause operational incidents. After the 90-day review period, establish a documented monthly audit log review cadence.

Game-server lifecycle via the panel: sequence diagram

The following sequence diagram documents the full lifecycle of a game server instance through the panel, from initial provisioning to decommissioning.

Frequently asked questions

Which panel should I choose for a new self-hosted estate?

The documented answer depends on the estate profile. For a new self-hosted estate with no existing panel infrastructure, Pterodactyl is the documented reference choice for estates that prioritize open-source auditability, no per-instance licensing cost, and Docker-based instance isolation. For an estate where the operations team is small and the preference is to minimize the infrastructure managed for the control plane itself, RocketNode's managed control plane reduces the panel-ops overhead. Document the required features first, then evaluate the panels against the documented list.

How do I secure the panel admin account?

Enable two-factor authentication using a TOTP authenticator application. Use a documented unique, high-entropy password generated by a password manager. Restrict administrative account login to the documented management IP range using the panel's IP restriction feature or the reverse proxy's allow/deny directives. Review the audit log for any login attempts from undocumented IPs.

Should the panel host and the Wings daemon node be on the same machine?

The documented recommendation is to run the panel and the first Wings node on separate hosts when the estate reaches production scale. Co-locating the panel and the first Wings node on the same machine is acceptable for a single-node development or staging environment. In production, a panel host that fails should not simultaneously take down a game-server node; the separation ensures panel administrative outages do not become player-facing outages.

How is panel software updated?

Panel software updates follow the documented procedure in the panel's official update documentation. The documented procedure for Pterodactyl updates includes: backing up the database before the update, pulling the new release, running composer install, running php artisan migrate, and restarting the queue workers. Wings daemon updates follow a separate procedure on each node host. Always test panel and Wings updates in staging before applying to production; panel and Wings updates are a documented change that requires the full change management process.

What happens to running game servers when the panel goes offline?

Running game server instances on Wings nodes continue operating through a panel outage. The Wings daemon manages the instances directly; it does not require a live panel connection to maintain running server processes. Operators lose access to the administrative functions (console, file management, start/stop) during the panel outage, but players on running servers experience no interruption.

How do I restore a panel that will not start after a failed update?

The documented restore procedure begins with reverting the panel codebase to the previous version (from the documented version archive or the panel's Git history), restoring the pre-update database backup, and restarting the panel services. The exact steps depend on the panel software and the nature of the failed update. The documented practice is to have the pre-update database backup verified before the update window begins, so the restore procedure can be executed immediately if the update fails.

What is the documented panel-to-Wings communication port?

The Pterodactyl Wings daemon listens on port 8080 by default. The port is documented in the Wings configuration file (/etc/pterodactyl/config.yml) and in the node configuration in the panel's Nodes administration page. The port can be changed from the default; document the configured port in the operations console binder. The panel-to-Wings connection is a documented HTTPS connection; the port must be open in the documented firewall on the node host.

How is the panel isolated from the game-server network?

The documented network topology places the panel on the management network segment, not the game-server network segment. The Wings daemon on each node host is accessible from the panel host on the management network IP of the node. Game-server instances (running in Docker containers) are accessible from the documented player-facing network on their allocated IP and port. The two network paths are documented as separate; player traffic never traverses the management network.

Can multiple administrators manage the panel concurrently?

Yes. The panel supports concurrent administrative sessions. The documented practice is to coordinate planned configuration changes through the documented change management process (change ticket, staging test, production window) even when multiple administrators have access. Concurrent changes applied without coordination can produce documented conflicting configuration states that are difficult to diagnose. The audit log records all changes with the actor's identity; in the event of a conflict, the audit log is the documented source of truth for the change sequence.

How often should the panel software be updated?

The documented cadence is to apply security updates within 48 hours of documented release and feature updates within the next scheduled change window after staging validation. Track the panel software's release announcements and security advisories through the documented official channels. Delayed security updates on the panel host are a documented operational risk; the panel has administrative access to every game server on the estate.

What is the restore time objective for the panel itself?

The documented restore time objective for the panel is 40 minutes from the decision to restore to a verified operational panel. The 40-minute figure includes: provisioning the replacement host (10 minutes with a documented host template), installing prerequisites (8 minutes), installing the panel software (5 minutes), restoring the database (5 minutes), restoring the environment configuration (2 minutes), verifying the restore (5 minutes), and reconnecting Wings nodes (5 minutes). The procedure has been tested in staging and the documented 40-minute figure reflects the tested duration.

Comparison: panel features at a glance

Feature	Pterodactyl	RocketNode	AMP	TCAdmin
Open-source license	Yes (MIT)	No	No	No
Self-hosted control plane	Yes	No (hosted)	Yes	Yes
Per-instance licensing cost	No	Plan-based	Yes	Yes
Docker-based instance isolation	Yes (Wings + Docker)	Agent-based	Module-based	Proprietary
Built-in 2FA support	Yes	Yes	Yes	Yes
Game-server template library	Community eggs	Built-in	Built-in modules	Built-in
REST API	Yes (documented)	Yes	Yes	Yes
Multi-node support	Yes	Yes	Yes	Yes
Audit logging	Yes	Yes	Yes	Partial
Scheduled tasks	Yes	Yes	Yes	Yes
Documented open-source auditability	Yes (full source)	No	No	No

Visual summary: panel architecture

                        OPERATOR BROWSER
                               |
                               | HTTPS (Let's Encrypt TLS)
                               v
                    +----------+-----------+
                    |    Nginx Reverse      |
                    |    Proxy (port 443)   |
                    +----------+-----------+
                               |
                               | Proxy to localhost:80
                               v
                    +----------+-----------+
                    |    Pterodactyl        |
                    |    Panel Application  |
                    |    (PHP, Laravel)     |
                    |    Database: MySQL    |
                    |    Queue: Redis       |
                    +----------+-----------+
                               |
               +---------------+---------------+
               |                               |
               | HTTPS (Internal CA TLS)       | HTTPS (Internal CA TLS)
               v                               v
    +----------+----------+         +----------+----------+
    |  Wings Daemon        |         |  Wings Daemon        |
    |  Node Host 1         |         |  Node Host 2         |
    |  Docker Engine       |         |  Docker Engine       |
    |  Management IP:      |         |  Management IP:      |
    |  10.0.1.21           |         |  10.0.1.22           |
    +----+---------+-------+         +----+---------+-------+
         |         |                      |         |
    +----+   +-----+                 +----+   +-----+
    |Srv1|   |Srv2 |                 |Srv3|   |Srv4 |
    |container   |                  |container   |
    | Unturned   |                  | Unturned   |
    | Port:27015 |                  | Port:27016 |
    +------------+                  +------------+

Appendix A: documented pre-change checklist

The following checklist is executed before every panel configuration change is applied to the production estate. The checklist is documented in the operations console binder and signed off by the responsible engineer before the change window opens.

1. Document the specific configuration parameter being changed, its current value, and its intended new value.
2. Verify the change has been tested in the staging environment and the test result documented.
3. Verify the restore procedure has been tested in the staging environment and the revert result documented.
4. Export a current panel database backup and verify the backup file is readable.
5. Copy the current .env and Wings config.yml files to the documented backup locations with timestamped filenames.
6. Notify the operations team of the change window, the expected duration, and the rollback trigger (the condition under which the rollback procedure will be executed immediately).
7. Confirm that no player events of documented significance (tournaments, events, scheduled saves) are scheduled during the change window.
8. Open a documented change ticket and record the start time of the change window.

Appendix B: documented panel security hardening checklist

The following hardening steps are applied to the panel host at installation time and verified at each quarterly security review.

Hardening item	Documented verification method
SSH limited to documented key-based authentication (password authentication disabled)	sshd_config: PasswordAuthentication no verified
SSH access restricted to documented management IP range	Firewall rule verified; sshd_config: AllowUsers verified
Panel admin accounts have 2FA enabled	Panel user list audit; 2FA status column verified
Panel reverse proxy enforces TLS 1.2 minimum	ssl_protocols directive verified in Nginx configuration
HSTS header present on all panel responses	Response header verified from external client
Panel web application runs as non-root user	ps aux verified; panel user documented
Wings daemon runs as documented non-root service user	ps aux verified on each node host
Panel database user has documented minimum permissions (SELECT, INSERT, UPDATE, DELETE on panel database only; no GRANT, no SUPER)	SHOW GRANTS FOR 'pterodactyl'@'localhost' verified
Panel application encryption key documented and backed up	Key documented in operations binder (encrypted storage); backup verified
Audit log retention configured for documented 90-day minimum	Panel audit settings verified
Certificate inventory current with documented expiration dates	Certificate inventory reviewed and signed off

Appendix C: documented panel software version tracking

The panel software version installed in the production environment is documented and tracked against the upstream release history. The following table is updated at each change window where the panel or Wings software is updated.

Component	Installed version	Release date	Upstream current version	Security update pending
Pterodactyl panel	Documented at installation	Documented at installation	Verified from upstream release page	Documented yes/no
Pterodactyl Wings (per node)	Documented at installation	Documented at installation	Verified from upstream release page	Documented yes/no
PHP	Documented at installation	—	Ubuntu/Debian repository current	Documented yes/no
MySQL / MariaDB	Documented at installation	—	Distribution repository current	Documented yes/no
Redis	Documented at installation	—	Distribution repository current	Documented yes/no
Nginx	Documented at installation	—	Distribution repository current	Documented yes/no
Certbot	Documented at installation	—	Distribution repository current	Documented yes/no

The version tracking table is reviewed monthly as part of the documented operations review. Security updates are applied within the documented 48-hour window from confirmed release. Feature updates are applied within the next scheduled change window after staging validation.

Panel-to-game-server isolation

The documented isolation between the panel administrative layer and the game server instances is one of the most important security properties of the reference configuration. Isolation means that an operator with panel access to a specific server instance cannot escalate that access into broader control of the host operating system, other server instances, or the panel itself.

Three mechanisms enforce the documented isolation:

Docker container boundaries: each game server instance runs in its own Docker container with a documented filesystem root separate from all other containers and from the host. File management access through the panel is scoped to the container's documented directory tree. A panel operator who has access to Server Instance A cannot access Server Instance B's files, even if both instances run on the same Wings node.

Panel permission scoping: the panel's permission model enforces server-instance-level access control at the API layer. A token or session with access to Server Instance A is documented as invalid for Server Instance B. The Wings daemon enforces this at the API request level; it rejects requests for resources not authorized for the requesting token.

Network namespace isolation: Docker places each container in its own network namespace. The container can communicate on its documented allocated IP and port; it cannot communicate with other containers' internal network addresses unless explicitly permitted through documented Docker network configuration. The documented reference configuration does not permit inter-container network communication; each instance is network-isolated from all others.

Best practice

Verify the documented isolation properties quarterly by attempting a documented cross-container access test from a panel account scoped to a single server instance. The test confirms that the isolation is enforced as documented; a test that succeeds (i.e., cross-container access is possible) is a documented security finding requiring immediate remediation.

Closing notes

The server panel is the administrative nerve center of the self-hosted Unturned estate. The documented practices in this article — staging tests before production changes, maintained configuration baselines, tested restore procedures, tightly scoped permission tiers, audited TLS, and integrated health-check monitoring — are not bureaucratic overhead. They are the operational foundation that makes the panel a reliable tool rather than a liability.

The documented time invested in setting up change management practices before the first production change is applied is the time that prevents unplanned incidents from becoming extended outages. A panel that goes down because a change was applied without a staging test and a documented rollback procedure is an avoidable incident. The documented practices in this article make it avoidable.

The 57 Studios reference configuration is reviewed annually against the documented state of the panel software ecosystem, the documented security advisory landscape, and the studio's operational experience. The annual review updates the reference configuration to reflect validated improvements and documents any practices that have been superseded by better alternatives.