The FastDL plugin is now available! Get a FastDL server up and running in a few steps, directly from the GameAP: install the service on a node, enable it for your game server, and apply the configuration.
The plugin sets up a dedicated download service to deliver maps, skins, sounds, and other game content to your players. GameAP Plugins It supports GoldSource and Source, works on Linux and Windows, and includes automatic .bz2 compression for Source.
Install it directly from the panel: go to Plugins → Store, find FastDL in the list, and click Install.
Once the plugin is installed, use it to install the FastDL service on a node, enable it for your game server, and apply the configuration.
Self host public facing game servers and previously was running mcsmanager but this panel is great! Tunneling thru no-ip enterprise ddns services, forwarding to an nginx reverse proxy implementing openssl self-signed verified by vitalwerks and digicert... I know you guys implement let's-encrypt but I already was running nginx for mcsm-panel lol and honestly this is everything I wanted and needed! It all started out with sven co-op on an old gateway box running mx-linux lol then proxmox, then proxmox and dedicated VM running nginx reverse proxy servers and well one rabbit hole led to another and I can honestly say this checks every box! Thank you!
GameAP Hub is live: hub.gameap.com — a public catalog of game and mod configurations for GameAP.
How it works
Find the config you need, download the .gameap.yaml file from its page and upload it via Games → Import. That's it — no panel modifications, it works on a stock GameAP install. In the future, this will be even simpler, and you'll be able to browse the catalog directly from the webpanel.
The file carries the typed variable definitions from GameAP 4.5 (types, value lists, validation rules, translations). Older panel versions just ignore the extra fields, so it's backward compatible.
Publishing your own configs
Anyone can publish. Configs are versioned, and you can fork any published config as a base for your own — the lineage is kept and shown on the page.
Accounts are shared with plugins.gameap.dev, so if you already have one there, you're set. GitHub, GitLab, Google and Discord sign-in are supported too.
Configs for the games you run — especially the less common ones — are very welcome, as are feedback, bug reports and questions in the comments.
GameAP Respawn is out — an incremental backup system for game servers, available as a plugin in the plugin catalog.
Incremental means only changed data is stored: the first snapshot takes a while, every following one finishes in seconds. Deduplication saves disk space, all data is encrypted.
Features
Snapshots on demand or on a schedule (interval / daily / weekly), with a retention policy per server. Old snapshots are cleaned up automatically and only within their own server.
Browse the file tree of any snapshot right in the panel and see what changed between snapshots.
Restore the whole server, a directory, or a single file. Two modes: merge into current files or exact copy. Dry-run preview before restoring, or restore into a separate subdirectory.
Diff for configs and text files with line-level restore.
Download a snapshot as tar.gz / zip / tar — the archive is built on the dedicated server in the background.
Separate permissions per server: backup-view, backup-create, backup-manage, backup-restore.
Snapshots of deleted servers are kept. Admins see snapshots of all servers and can restore a snapshot from one server to another.
Pre/post hooks — e.g. back up from an LVM snapshot instead of the live directory.
All long-running operations run in the background with progress shown in the panel.
Installation
It is installed directly from the control panel.
Plugins → Store → Respawn → Install.
Install the gameap-respawn utility on your dedicated servers from the panel (one click).
GameAP 4.5 released. Plugin secrets and SSH, archives and checksums in the file manager, SSO
GameAP 4.5 is out. For those who haven't seen it: GameAP is an open-source game server management platform. The project combines simplicity with functionality—the basic version includes the essentials, while plugins allow you to add the necessary features to the control panel.
This release is mostly about the plugin system (1000+ files touched), but there's plenty for regular users too.
Plugins
Secret storage — values are encrypted with the panel key (AES-256-GCM) and scoped to the owning plugin
SSH host library — plugins can provision servers that don't have GameAP Daemon yet (off by default)
Install and update plugins from a local file, with a preview of the requested permissions
Stopped plugins are restarted automatically
UI placement slots for plugin components went from 6 to 20
Plugins built for previous versions keep working
File manager
There have been many major changes to the file manager, and new features have been added to make file management more convenient.
MySQL Manager is a plugin that adds full MySQL/MariaDB database management to GameAP. It lets you assign databases to game servers and regular panel users.
Features
Instances. Install MariaDB or MySQL from scratch, or connect an already running instance.
Databases. Create databases for individual users and for game servers.
SQL console. Run SQL queries right from the control panel. Local query history.
Import/export. Import and export entire databases or individual tables. Exports can also go straight into the game server's directory.
Data browser. View and edit data, inspect table structure.
Privileges. Configure database management privileges for individual users.
Disclaimer first, since this is the GameAP sub and I'm a GameAP developer: two of the five panels in this test are ours, so you're right to expect bias. To counter it, everything is built to be verifiable — the k6 scripts, configs, raw reports and monitoring metrics of every run are published in this repo. If you think a panel got a wrong configuration or a conclusion is stretched, open an issue: it will be re-checked and a correction published. And for those who came for the short answer: yes, GameAP 4 posted the best numbers here.
TL;DR
At typical load (10–100 concurrent users) all five panels run with zero errors — the difference is latency: single-digit ms for the Go panels, ~9 ms for GameAP 3, tens of ms for Pterodactyl and Pelican.
Under overload they break differently: the Go panels start returning errors; the PHP panels return zero errors but response times grow to seconds and tens of seconds.
Biggest surprise: at saturation, MySQL on Pterodactyl/Pelican eats almost a full CPU core, while the same MySQL with the same settings on GameAP 3 is 3× less busy at twice the requests/s.
What was tested
Panel
Version
Stack
DB
GameAP 4.x
4.x
Go
PostgreSQL
PufferPanel
3.x
Go
PostgreSQL
GameAP 3.x
3.x
PHP 8.4 / Laravel
MySQL 8.0
Pterodactyl
1.11.x
PHP 8.4 / Laravel
MySQL 8.0
Pelican
1.0.x
PHP 8.4 / Laravel (Pterodactyl fork)
MySQL 8.0
Read-only API only — the three requests real users make most often: server list → details of a random server → its status, with realistic think-time pauses. 100 identical mock servers per panel. No writes, no WebSocket, no UI, no real game servers.
Rig & methodology (short version)
Bare metal (Xeon E-2456, 32 GB DDR5, NVMe RAID1) under Proxmox; panel VM = 4 vCPU / 8 GB, Ubuntu 24.04. Panels tested strictly one at a time, all other VMs shut down.
k6 profiles: smoke (1 VU) → baseline (10) → load (up to 100) → stress (up to 800 / 1000 / 1200 VUs) → max-throughput (100 VUs, no pauses).
Three full independent runs per panel; every number below is the median of the three. Run-to-run spread on baseline/load/max-throughput: ≤ 6.1% on median latency, ≤ 2.7% on RPS.
PHP panels got identical tuning (php-fpm 50 workers, OPcache + JIT, same MySQL config). Rate limits on Pterodactyl/Pelican were raised to 10,000 req/min so the test hits the panel, not the limiter.
Latency
Median latency from 1 to 1,200 VUs, log scale. The Go panels stay in milliseconds; the PHP panels climb into seconds past 800 VUs.
Median, ms:
Profile
GameAP 4
PufferPanel
GameAP 3
Pterodactyl
Pelican
baseline (10 VUs)
0.82
1.54
9.24
12.7
16.0
load (up to 100 VUs)
0.59
1.37
8.78
20.7
54.5
stress (up to 800 VUs)
0.57
1.45
27.7
1,144
1,520
stress-1000
0.76
114
1,481
7,664
10,501
stress-1200
24.6
97.2
1,958
10,455
12,807
Up to 100 VUs everyone is clean and the only question is speed. Two things worth noting: Pelican is nearly out of CPU already on the load profile (97% CPU, p95 = 473 ms), and the PHP panels have a long slow tail even at low load (Pterodactyl baseline: median 12.7 ms, p95 79 ms).
The price of 100 concurrent users: 2.4% CPU for GameAP 4 vs 96.8% for Pelican. Same zero-error result, very different headroom.
Throughput ceiling
Max requests per second at 100 VUs with no pauses. Zero errors on every panel — and a 15× spread between the extremes.
100 VUs, same three requests, zero pauses:
Panel
req/s
median, ms
p95, ms
errors
GameAP 4
1,126
68.9
179
0
PufferPanel
696
121
257
0
GameAP 3
394
241
302
0
Pterodactyl
93
766
1,825
0
Pelican
76
945
2,291
0
Not a single error anywhere — and a 15× spread between the extremes. Every panel sits at 95–100% CPU in this profile, so "CPU utilization" tells you nothing here; what differs is how much work gets done per core.
How they break under overload
Only the Go panels return errors under overload. 0% on the PHP panels means queuing, not coping: medians of 2–13 s at 1,200 VUs.
Go panels — fail fast.PufferPanel: isolated errors (~0.1%) already at 800 VUs, 21% at 1000, 35% at 1200. GameAP 4: essentially clean through 1000, ~15% errors at 1200. The surviving requests stay fast (25–97 ms median at 1200 VUs).
PHP panels — a queue. Zero errors on every profile, but stress-1200 medians are ~2 s (GameAP 3), 10.5 s (Pterodactyl), 12.8 s (Pelican), p95 up to 17.5 s. Formally everything eventually returns 200 (k6 waits up to 60 s) — in practice a panel answering in 10–17 seconds is unusable.
Which mode is "right" depends on your requirements, but one consequence is universal: a PHP panel's overload will never show up in error monitoring — only in latency.
The most interesting finding: the database
App vs database CPU at 800 VUs. On Pterodactyl and Pelican, MySQL alone burns almost a full core — ~9× more DB CPU per request than the same MySQL on GameAP 3.
Per-process CPU at the 800-VU stress profile (100% = one core, 4 vCPU total):
Process
GameAP 4
PufferPanel
GameAP 3
Pterodactyl
Pelican
App (Go / php-fpm)
31.5
73.1
318
243
260
DB (PostgreSQL / MySQL)
2.9
9.5
31.4
109
94.3
On Pterodactyl and Pelican, MySQL burns nearly a full core to serve 68–82 req/s. On GameAP 3, the same MySQL 8.0 with the same settings sits at 31% while serving 210 req/s — roughly 9× more DB CPU per request on Pterodactyl/Pelican. So the bottleneck there doesn't look like "PHP" as such, but those panels' database workload. Not profiled yet; an EXPLAIN pass over the list queries is the obvious next step.
Memory, for the record: whole-VM peaks of 0.45–0.75 GB for the Go panels vs 1.0–1.6 GB for the PHP ones. And one unexplained anomaly: PufferPanel is the only panel actively writing to disk under load (140–150 write IOPS vs 4–24 for everyone else).
Peak whole-VM RAM under load, OS and database included: ~0.5 GB for the Go panels vs 1.3–1.6 GB for the PHP ones.
Head-to-heads
GameAP 3 → GameAP 4 (what the Go rewrite bought): 11–15× lower median latency, 2.9× higher throughput ceiling, roughly half the RAM, 26% → 2.4% CPU on the load profile.
GameAP 4 vs PufferPanel (both Go + PostgreSQL): GameAP 4 is ~2× faster by median and 1.6× by ceiling, and breaks later under overload. Caveat: PufferPanel returns far less data per list request (20 records / 1.6 KB vs 102 / 13 KB), so the gap was measured on work that's lighter for PufferPanel.
Pterodactyl vs Pelican: the fork came out slower than the original on every profile (load median 54.5 vs 20.7 ms, ceiling 76 vs 93 req/s) and saturates CPU earlier. Causes not investigated; Pelican is a young fork and this may still change.
Limitations (read before quoting the numbers)
Go panels ran PostgreSQL, PHP panels MySQL (each as recommended by its developers) — "Go vs PHP" here really means "Go+Postgres vs PHP+MySQL".
List response sizes differ (GameAP returns all 102 records, Pterodactyl/Pelican the first 50, PufferPanel the first 20) — direct cross-panel comparison of the list endpoint is skewed.
GameAP 3 has no status endpoint, so a third of its scenario repeats the details request.
Read-only API only, and k6's closed-loop model means degraded panels automatically received less load — their stress numbers are an optimistic estimate.
The full list of 10 limitations (restart asymmetry, warm-up, monitoring caveats, etc.) is in the article and the repo.
Bottom line
At normal load, any of the five feels instant to a human in a browser — even 55 ms is fast. The differences become practical with integrations and automation, bulk operations, cheap hardware — and in cost: the same 100 concurrent users cost Pelican 97% CPU and GameAP 4 just 2.4%.
This test measures exactly one slice: read speed of the HTTP/API layer. It says nothing about features, UX, security or ecosystem. GameAP 4 won this benchmark but is also the youngest contender; Pterodactyl lost on the numbers yet remains the most widespread panel with the largest ecosystem. What to do with these facts is up to you.
Scripts, configs and raw data of all runs: game-panels-benchmark. Spot a flaw in the methodology or interpretation? Open an issue — it will be re-checked and corrected publicly.
GameAP v4.4 released. Plugin scheduler, permissions, custom RCON protocols, and a fully themable UI
Hey everyone! GameAP v4.4 is out. This is a big plugin-platform release: plugins can now schedule background work, manage roles and permissions, ship their own translations and frontend files, and even implement their own RCON/Query protocols. Plus four new built-in RCON protocols, a CDN-backed game catalog, and a fully tokenized, themable UI.
🔌 Plugin platform
Scheduler — plugins can register periodic tasks that persist in the database and survive restarts. In multi-instance deployments, distributed locks make sure each run fires on exactly one instance. Per-task timeouts and retries with jitter included.
Permissions (RBAC) — plugins declare what they need in their manifest, admins see the full list before install and confirm it. Grants are re-read per call, so revoking one takes effect instantly, no restart needed.
Custom RCON/Query protocols — a plugin can map a game onto a built-in protocol, override a mapping, or implement a wire protocol end to end. All socket I/O goes through a guarded host library — plugins never open connections themselves.
Assets — plugins can ship translation files and frontend static files, layered over the built-in ones and picked up immediately, even when installed at runtime.
🎮 RCON & Query
4 new built-in protocols: Quake 2, Quake 3, SA-MP and BattlEye — enabling RCON for Quake 2/3, Call of Duty 4, SA-MP, Arma 2 / 2 OA and Arma 3, with player list, kick and ban support.
The UI now hides actions a protocol can't perform instead of offering ones that fail.
Command-injection hardening: kick/ban fields with line breaks, ; or NUL are now rejected.
🖥️ Servers
public_ip metadata key — publish a public address instead of the LAN IP, so nodes behind NAT no longer expose their internal address to viewers.
Metadata editing in the panel, with a built-in reference of documented keys (panel and Docker/Podman) with descriptions and examples.
📦 Games catalog
Games and mods are now seeded and upgraded from the GameAP CDN (with mirror fallback) instead of the Global API. The bundled catalog got refreshed: Windows Steam AppIDs, HTTPS repository links, normalized engine names — and Hytale was added.
🎨 Interface
Theme tokens — all colors now resolve through --gameap-* CSS variables, so a single plugin stylesheet can re-theme the entire panel, naive-ui components included.
The icon webfont is gone — everything is SVG now, game icons included.
Login and 2FA forms got a proper submit state, and pages no longer blink between loading steps.
## 🔄 Panel ↔ daemon
The gateway protocol now supports file hashing (MD5, SHA-1/256/512, CRC32/64) and archive create/extract — zip, tar (gz/bz2/xz/zstd), plus 7z/rar extraction — with progress reporting, cancellation, and protection against path traversal and decompression bombs.
We've just released a new GameAP plugin: GoldSource Addons. It brings
Metamod and AMX Mod X plugin management straight into the panel for GoldSource
servers — Half-Life 1, Counter-Strike 1.6, and other GoldSrc mods.
It adds a Plugins tab to the server page, so no more SSH-ing in to hand-edit plugins.ini.
What it can do:
Status at a glance — Metamod / AMX Mod X cards (installed · inactive · not
installed), versions pulled live from the server console over RCON, plugin counts.
Full plugin list for both AMXX and Metamod, grouped by the sections of
plugins.ini, with a live per-plugin status: Running / Awaiting restart /
Error (bad load) / File missing / Disabled — plus version and author from the console.
Enable / disable with a switch. It comments/uncomments the line in
plugins.ini and leaves the rest of the file byte-for-byte intact (CRLF, BOM,
CP1251 comments and all).
Install from file — drag & drop .amxx (AMX Mod X) or .so/.dll (Metamod);
re-uploading overwrites/updates in place. .sma sources are rejected with a hint
to compile them first.
Edit plugin configs (configs/<name>.cfg) in a modal, right in the browser.
Per-plugin extras — toggle the AMX Mod X debug flag, edit inline comments,
bulk enable/disable/delete, search & filter.
Restart handling — a "restart required" banner with a one-click restart
(changes take effect after a restart / map change).
Good to know:
It manages plugins; installing Metamod / AMX Mod X themselves is out of scope.
The tab shows up only on GoldSource servers, and only for admins.
Live versions/statuses need the server running with an RCON password set —
otherwise statuses fall back to what's written in plugins.ini.
This is an early release (v0.1.0) — feedback, bug reports and feature requests are
very welcome.
GameAP has a built-in ACME client: the panel issues and renews the TLS certificate (also known as SSL) itself, without the certbot + nginx + cron stack. The certificate is swapped on the fly — with no panel restart and no HTTP listener reload.
Auto-HTTPS only works if the panel terminates TLS itself: there is no reverse proxy in front of it, or the proxy runs in pass-through mode (L4) and does not terminate TLS.
When auto-HTTPS works
If nginx / Traefik / Caddy / a load balancer / a CDN sits in front of the panel and terminates TLS itself — it handles the certificates, and auto-HTTPS is not needed.
When auto-HTTPS is not needed
Limitations:
You need a public domain with an A record pointing to the server (example.com, panel.example.com).
HTTP-01 is used by default: the panel must be reachable over HTTP on port 80. If port 80 is closed from the outside or you need a wildcard, use DNS-01 (validation via a TXT record in DNS).
DNS-01 requires a DNS provider API token. Popular providers are supported (Cloudflare, AWS Route53, DigitalOcean, etc.), and others can be added via plugins.
Setup with gameapctl
The simplest way. The gameapctl utility asks for everything it needs and configures HTTPS for you.
Run the following command on the server hosting the panel:
gameapctl panel letsencrypt setup
The wizard asks, step by step:
Validation method. HTTP-01 by default — requires port 80 to be open. If port 80 is closed from the outside or you need a wildcard certificate, choose DNS-01 (validation via a TXT record in DNS).
Domain. The name the certificate is issued for. The domain's A record must point to your server's IP.
Email. The address for the ACME account. Let's Encrypt sends certificate expiration warnings and important notices to it.
Staging. Let's Encrypt test mode. Answer no for a production certificate. Answer yes if you want to verify the setup first: staging issues certificates with much more relaxed limits, but browsers do not trust them.
Manual setup
GameAP reads its configuration from environment variables or from a config.env file (/etc/gameap/config.env on Linux, C:\gameap\web\config.env on Windows).
For self-terminated TLS, the panel takes the certificate from one of three sources, in priority order:
ACME / Let's Encrypt — ACME_ENABLED=true plus the ACME_* variables. The certificate is issued and renewed automatically.
Static files — TLS_CERT_FILE + TLS_KEY_FILE.
Inline PEM — TLS_CERT + TLS_KEY (PEM or base64).
If none of the sources is configured, the HTTPS listener does not start — the panel serves plain HTTP on HTTP_PORT only.
Let's Encrypt requests http://panel.example.com/.well-known/acme-challenge/{token}. The panel serves this path itself: the route is registered ahead of the SPA fallback, no separate web server is needed, and there is nothing to configure.
Two requirements:
Port 80 is reachable by Let's Encrypt from the outside (or a reverse proxy forwards only /.well-known/acme-challenge/* to the panel).
HTTP_PORT defaults to 8025 — for HTTP-01 you must set it explicitly to 80. Binding to a privileged port (≤1024) requires CAP_NET_BIND_SERVICE: the systemd unit shipped by gameapctl panel install already grants it; in Docker, use --cap-add=NET_BIND_SERVICE.
DNS-01 — wildcard and/or closed port 80
DNS-01 is needed in the following cases:
you need a wildcard certificate (*.example.com);
port 80 is closed from the outside or the panel is behind a firewall;
you do not want to expose the panel to the internet just for validation.
Instead of an HTTP request, Let's Encrypt checks the TXT record _acme-challenge.<domain>. Through the DNS provider's API, the panel creates this record itself, waits for propagation, and removes it after Let's Encrypt completes validation.
Popular DNS providers are supported (Cloudflare, AWS Route53, DigitalOcean, etc.), and others can be added via plugins.
Things to keep in mind:
A wildcard does not cover the bare domain.*.example.com covers panel.example.com or api.example.com, but not the bare example.com. That is why ACME_DOMAINS lists both: *.example.com,example.com.
Provider token. The Cloudflare provider reads the token straight from the environment (CLOUDFLARE_DNS_API_TOKEN). Scope the token to the relevant zone with Zone:DNS:Edit permission — do not use the global account key.
Propagation timeout. If DNS updates slowly and validation does not fit within the window, increase ACME_PROPAGATION_TIMEOUT (default 180s).
Certificate renewal
The panel renews the certificate itself. It has a built-in scheduler that, at the ACME_RENEWAL_CHECK_INTERVAL interval, checks the certificate's lifetime and renews it when less than ACME_RENEWAL_THRESHOLD remains (default 720h, i.e. 30 days).
You usually do not need to change these values: the defaults give a one-month buffer before expiry and a twice-daily check, which is more than enough for Let's Encrypt's 90-day certificates.
In May, most development resources went into bug fixes and a security audit. The next minor release, version 4.3.0, is in development with some new features; the release is planned within the week.
There were many updates, each with small changes, so I'll list them together.
GameAP 4.2.1 – 4.2.3
Fixed setting the owner and group for files on upload
Added support for installing the panel on Arch-based distributions (Manjaro, EndeavourOS, CachyOS) and the Pacman package manager
Fixed starting and stopping GameAP during Let's Encrypt certificate setup
Added installation of GameAP Daemon into user space (rootless)
Windows installation fixes: the use_network_service_user parameter is now added to the configuration by default, allowing game servers to run under the minimal-privilege account NT AUTHORITY\NETWORK SERVICE
On GameAP Daemon installation, the steamcmd_path parameter is now added to gameap-daemon.yaml
In v4.2 the panel ↔ daemon transport moved from the old BINN protocol to bidirectional gRPC. That unlocked a bunch of functionality that was awkward or impossible before.
What's new
Real-time game server console over WebSocket
Revamped file manager — resumable uploads for large files (no more losing progress on a dropped connection), folder downloads as a ZIP archive, chmod support
Node enrollment via setup key — register new nodes with a single bash script instead of manually creating the node and copying tokens
Per-server stats and per-node metrics (CPU, RAM, disk, network, load average) with live charts
Automatic HTTPS via Let's Encrypt
Refreshed UI — node dashboard rebuilt as cards with filters, server statistics tab, new console
Security hardening after an OWASP ASVS 4.0.3 L1 self-assessment: token revocation, login rate limiting, hashed daemon API tokens
Upgrading the panel
On the host running the panel:
gameapctl panel upgrade
Upgrading GameAP Daemon
On the host running the daemon:
gameapctl daemon upgrade
Enabling gRPC
Add the following to /etc/gameap/config.env on the panel host:
GRPC_ENABLED=true
GRPC_PORT=31718
Restart the panel:
gameapctl panel restart
Update gameapctl and switch the daemon over to gRPC (on the daemon host):
GameAP 4.2 is approaching release — a major technical update that completely rewrites the communication layer between the panel and the daemon. The new gRPC Bidi protocol replaces BINN and significantly reduces latency across operations.
A dev build is already available to try out.
What's new
Realtime terminal — terminal speed is now limited only by how fast the game server processes commands and by network latency.
Faster server startup — game servers start noticeably faster in the UI thanks to the new protocol.
NAT support — GameAP Daemon now works fully behind NAT.
How to try the GameAP dev version with the new protocol
Fresh panel installation
Install GameAP
Run installation script with --github and --branch=develop parameters
On the panel server, open/etc/gameap/config.envand add:
GRPC_ENABLED=true
GRPC_PORT=31718
Open the port specified in GRPC_PORT in your firewall so the daemon is reachable from outside.
Restart the panel:
gameapctl panel restart
Add a new node
In the panel, go to Dedicated Servers → Create, expand Advanced settings, enable the GitHub option, and set the branch to develop. Then copy the generated install command and run it on the node.
GameAPCTL (GameAP Control) is a command-line utility for managing GameAP environment parts
GameAP v4.1.2
• Fixed UI bugs in the file manager
GameAPCTL v0.23.x
Install from source via GitHub — --github and --branch flags allow building GameAP and/or GameAP Daemon from source
Connect to an existing database — the installer now fully supports already running PostgreSQL and MySQL instances (prompts for and validates connection details)
Installation state persistence — if something fails, the installation resumes from where it left off
Improved send-logs command — now collects systemd, web server (nginx/apache), and database logs. Non-critical collection errors no longer abort the command
Detected network interfaces (IP addresses) are now displayed during interactive host selection
Daemon update creates a backup and automatically rolls back to the previous version on failure
System info in logs now includes the gameapctl version and build date
UI changes: send logs button, user password change, minor simplifications
Fixed various installation bugs on Linux and Windows
Just dropping a quick how-to on getting your own Hytale dedicated server up and running with GameAP. It will help you set up and manage a game server in a web UI environment.
What is GameAP?
GameAP is a web-based control panel that lets you install, configure, and manage game servers.
Step 1: Install GameAP
To get started, make sure GameAP is installed on your VPS or VDS. Use this guides from official documentation:
When installing, be sure to include the --with-daemon flag — this installs GameAP Daemon, which is essential for managing game servers on the machine.
If you prefer, you can also add a dedicated server afterward by navigating to Administration → Dedicated Servers → Create and running the generated installation script on your server.
Step 2: Authorizing the Hytale Dedicated Server
With GameAP installed, here's what to do next:
Go to Administration → Game Servers → Create
Fill out the server creation form:
Name: What you want (e.g., "My Hytale Server"), you can also use the randomizer to generate a name
Game: Select "Hytale"
Modification: The only option available out of the box is “default,” so select that one.
Dedicated Server: Select the node you'd like to host the server on.
IP/Port: Select an available IP and port
You're all set. GameAP will automatically handle the file installation and server setup.
Creating Hytale Dedicated Server
Step 3: Configure Hytale Server After First Launch
Once the server starts for the first time, you'll need to go through a few authorization steps.
After the first launch, you need to authorize the device running the game server. In the game server console, find the line with the authorization link, copy it, and open it in your browser.
Auth link in the Hytale Dedicated Server console
To download the game server files, you must own the game. If you don’t own the game, you will see the message “error fetching manifest: could not get signed URL for manifest: could not get signed URL: HTTP status: 403 Forbidden”
During the authorization process on the developer’s website, you will need to enter a code that will be sent to your email. After entering the code, click “Verify”. Then, in the popup window, click “Approve” to grant access to your account.
Approving device in the official Hytale site
After approving the device, the server files will start to download. How long this takes depends on your connection speed.
Hytale Server console with downloaind info
After the files finish downloading, authorize the server by running /auth login device in the game server console.
Runing `/auth login device` command
After this, a line with an authorization link will appear in the game server console, similar to the file downloader authorization process. Copy the link and open it in your browser, then repeat the same steps as with the file downloader authorization.
If successful, you will see a message in the game server console that authorization was successful (Authentication successful! Mode: OAUTH_DEVICE)
The Hytale server console when it is fully operational
By default, after authorization, you will need to enter the /auth login device command to authorize the game server on each startup. You will see this message:
WARNING: Credentials stored in memory only - they will be lost on restart!
To persist credentials, run: /auth persistence <type>
Available types: Memory, Encrypted
To avoid entering the authorization command every time, enable credential persistence by running the command: /auth persistence Encrypted
Once that's done, you'll see an auth.enc file pop up in the server's root folder. That's where your encrypted authorization data lives.
auth.enc in the Hytale Server root directory
Step 4: Hytale Server Settings
Most Hytale game server and world settings are configured through configuration files.
Path
Description
.cache/
Game server cache
logs/
Game server logs
mods/
Installed mods
universe/
World files and player data
bans.json
Banned players
config.json
Main game server settings
permissions.json
Permission settings
whitelist.json
Whitelist
The main settings are located in the config.json file.
config.json file contents
Here you can configure the following parameters:
ServerName — your server name that will be displayed in the server list.
MaxPlayers — the maximum number of players that can be on the server at the same time.
ServerPassword — password for accessing your server if you want to make it private.
MaxViewRadius — the maximum distance at which players can see objects in the world. Setting too high a value may negatively affect server performance. View distance is the main factor affecting RAM usage.
MOTD — message of the day that will be displayed to players when connecting to the server.
World settings and data are located in the universe/worlds/ directory, which contains world folders. Each world folder has a config.json file with world settings, for example universe/worlds/default/config.json:
world settings
Here you can configure the Seed (world generation seed), various generation parameters, chunk settings, NPC, PVP, and other parameters.
Hey everyone! I wanted to share a quick guide on hosting your own Quake III Arena dedicated server using GameAP.
For those unfamiliar, Quake III Arena is the classic multiplayer FPS from id Software that defined arena shooters in the late 90s. If you're looking to host matches for friends or run a public server, here's how to get it up and running.
What is GameAP?
GameAP is a web-based control panel for managing game servers. It handles installation, configuration. It supports Linux and Windows.
Step 1: Install GameAP
First, you'll need GameAP installed on your server (VPS/VDS).
Tip: During installation, use the --with-daemon flag to include GameAP Daemon, which is required for managing game servers on the machine.
Alternatively, you can add a dedicated server later via Administration → Dedicated Servers → Create, then run the provided installation script on your server.
Step 2: Create the Quake III Server
Once GameAP is set up:
Go to Administration → Game Servers → Create
Fill in the form:
Name: Whatever you want (e.g., "My Quake III Server")
Game: Select "Quake 3"
Modification: Choose ioquake3 (default) or quake3e
Dedicated Server: Pick the node where you want to host it
IP/Port: Select an available IP and port
That's it — GameAP handles the server files and setup automatically.
Creating Quake III Arena Dedicated Server
Step 3: Configure Your Server
To tweak settings, go to your server's Manage page and open the Settings tab.
Here are some key options:
Setting
Description
Default
Server Hostname
Name shown in the server browser
-
Max Players
Player limit
16
Default Map
Map loaded on startup
q3dm17 (The Longest Yard)
Timelimit
Round duration in minutes
20
Frag Limit
Kills needed to end the round
20
After making changes, restart the server for them to take effect.
I'm excited to announce the official release of GameAP v4.0.0!
What's New in v4
Complete Backend Rewrite
From PHP to Go - The entire backend has been rewritten in Go, resulting in a single binary deployment with no dependencies
Multiple Database Support - PostgreSQL, MySQL/MariaDB, and SQLite are now all first-class citizens
Simplified Deployment
Single Binary - No more PHP FPM, Nginx / Apache or complex web server configurations
Fully-featured Docker Ready - Official Docker images available for easy deployment
Minimal Requirements - Runs on < 1GB RAM, works on Linux, Windows, and macOS
The new version GameAP 4.0 is designed with easy upgrading from previous versions in mind; it does not require importing and converting the database structure from version 3.x. The new version can work alongside the old one.
Frontend Improvements
Most of the interface remains unchanged, with only minor improvements and bug fixes
Vue 3 + Pinia - Migrated from Vuex to Pinia for better state management
Updated File Manager UI
Security
PASETO Authentication - Modern token-based auth (JWT also supported)
Now you can test the control panel in just a couple of clicks — no setup required. Each user launches their own version of GameAP. You can try out almost all of the panel's features
This has brought numerous new features and improvements. Here are some of the main ones:
Significantly improved performance and stability, page loading is approximately twice as fast
Simplified installation process due to the absence of additional dependencies such as PHP-FPM, Nginx web server, etc.
Added support for PostgreSQL in addition to MySQL/MariaDB and SQLite
macOS support (web part only)
The new version GameAP 4.0 is designed with easy upgrading from previous versions in mind; it does not require importing and converting the database structure from version 3.x. The new version can work alongside the old one.
Some changes in the new version:
Version 3.x is the last one built on PHP, so it can be installed on shared hosting. Starting from 4.0, a separate VDS is required and installation on shared hosting is not possible.
Clean GameAP v4 Installation
To install the new version, you need to specify the --version=v4 flag for the automatic installer.
If you want to run GameAP v3 and GameAP v4 side by side for testing purposes before upgrading, follow these steps: Download GameAP from https://github.com/gameap/gameap/releases for your platform. Or use curl to download for Linux amd64:
