Calagopus Game Server Panel on Ubuntu 24.04 on Azure User Guide

Overview

Calagopus is a free, open source, self hosted game server management panel, a ground up reimplementation of Pterodactyl Panel written in Rust. It gives you one clean web console to create, start, stop and monitor container based game servers, manage the files, players, backups and schedules on each server, and hand scoped access to the people on your team, all across the daemon nodes you connect to it. It reuses Pterodactyl style eggs, offers a supported migration path from Pterodactyl and Pelican, and exposes real backend and frontend extension APIs for themes, auth providers and plugins.

The cloudimg image delivers Calagopus fully installed and wired to its database and cache on Ubuntu 24.04, so a working panel is running within minutes of launch instead of after hours of manual Rust, PostgreSQL, Redis and systemd setup. Backed by 24/7 cloudimg support.

Calagopus is licensed under the MIT License. All product and company names are trademarks or registered trademarks of their respective holders. This image repackages the upstream open source release with cloudimg's provisioning and support.

What is included:

• Calagopus 1.1.3 (MIT), the prebuilt Rust panel binary at /usr/local/bin/calagopus, serving both the REST API and the bundled React web interface on port 8000
• PostgreSQL 16 for the panel's persistent state and Redis for its cache, session and rate-limit layer, both preinstalled and running locally
• A per-VM administrator password, a per-VM application encryption key and a per-VM database password, all generated on first boot and written to a root-only file, so no default or shared login ships in the image
• Public self registration disabled and telemetry disabled by default, both re-enabled from the admin settings whenever you want them
• calagopus.service, postgresql.service and redis-server.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point and is ample for the panel itself; the panel uses well under 1 GiB with PostgreSQL and Redis alongside it. NSG inbound: allow 22/tcp from your management network and 8000/tcp from the people who will use the panel. Add 443/tcp if you put the panel behind HTTPS.

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Calagopus by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and a custom 8000 rule for the panel. Then Review + create and Create.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name calagopus \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Open the panel port so you can reach the web console:

az vm open-port --resource-group <your-rg> --name calagopus --port 8000 --priority 900

Step 3 — Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 — Confirm the panel is running

The panel is a single Rust binary managed by calagopus.service. It talks to a local PostgreSQL for state and a local Redis for caching. All three units are enabled, so they come back automatically after a reboot.

systemctl is-active calagopus postgresql redis-server

Check the versions that shipped in this image:

sudo bash -c 'set -a; . /etc/calagopus/panel.env; set +a; /usr/local/bin/calagopus version | head -1'
sudo -u postgres psql -tAc 'SHOW server_version' | awk '{print "PostgreSQL", $1}'
redis-cli --version

Confirm the panel answers on the loopback interface:

curl -s -o /dev/null -w 'panel HTTP / -> %{http_code}\n' http://127.0.0.1:8000/

Step 5 — Retrieve your per-VM administrator credentials

On the first boot of each VM, calagopus-firstboot.service generates a fresh application encryption key, a fresh PostgreSQL password and a unique administrator password, then writes them to a root-only file. Nothing is shared between deployments and nothing is baked into the image.

sudo cat /root/calagopus-credentials.txt

Both the credentials file and the environment file that holds the encryption key are readable only by root:

sudo stat -c '%a %U:%G %n' /root/calagopus-credentials.txt /etc/calagopus/panel.env

Back up /etc/calagopus/panel.env. The panel encrypts stored values with the APP_ENCRYPTION_KEY it contains, and uses it to sign login sessions. Without that key those values cannot be decrypted, even from a database backup.

You can confirm the login works end to end from the command line, using the credentials the file holds:

CU=$(sudo grep '^calagopus.admin.username=' /root/calagopus-credentials.txt | cut -d= -f2-)
CP=$(sudo grep '^calagopus.admin.pass=' /root/calagopus-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'API login -> HTTP %{http_code}\n' -H 'Content-Type: application/json' \
  -X POST --data "{\"user\":\"$CU\",\"password\":\"$CP\",\"captcha\":null}" \
  http://127.0.0.1:8000/api/auth/login

Step 6 — Sign in

Browse to http://<vm-public-ip>:8000/ and sign in with the username and password from the credentials file. Calagopus signs you in in two steps: enter the username, select Continue, then enter the password. That account is the administrator of the panel.

There is deliberately no Create account link: public self registration is disabled on this image so that nobody who reaches your instance can create an account before you do. Step 10 explains how to reopen it or add users directly.

Step 7 — The panel console

After signing in you land on Servers, the main console. A freshly launched panel has no servers yet, because a game server runs on a daemon node you attach in the next step. The left sidebar is where you manage your own account, security keys, API keys, SSH keys, command snippets and sessions.

Step 8 — The admin dashboard

Select Admin in the sidebar to reach the administration area. The Overview tab shows a live system dashboard: CPU, memory, kernel, the PostgreSQL and cache versions in use, and cache statistics, so you can see the panel is healthy at a glance. From the admin sidebar you reach Settings, Nodes, Servers, Users, Roles, Nests and Eggs, and more.

Step 9 — Add a game daemon node

The panel manages game servers that run on one or more daemon nodes. The node is a separate machine (or this same VM, if you also run the daemon on it) that actually hosts the game containers. To attach one:

1. In the admin area open Locations and create a location (a region or logical grouping for your nodes).
2. Open Nodes, select Create, and fill in the node's address and resource limits.
3. Follow the on-screen configuration to install and connect the node's daemon agent on the target machine.
4. Once the node reports in, open Servers, select Create, choose a nest and egg for the game you want to host, pick the node and an allocation, and the server is provisioned.

A connected node is not required for the panel itself to be up and healthy; the panel is the product this image ships, and you attach as many nodes as your game-hosting operation needs.

Step 10 — User management and the security model

The image is hardened so that a freshly launched instance is safe before you have touched it:

• No account ships in the image. The captured image contains no panel database at all. The database, the encryption key and the administrator are all created on first boot with per-VM random secrets.
• The panel cannot start against a default configuration. calagopus.service only starts once first boot has written /etc/calagopus/panel.env, so there is never a window where a default or empty configuration is exposed.
• Self registration and telemetry are disabled by default, and re-enabled from the admin settings when you want them.
• Only SSH and the panel port listen externally. PostgreSQL and Redis are bound to the loopback interface, and no swap is baked into the image.

Confirm the security posture on your own instance:

ss -tlnH | awk '{print $1, $4}' | sort -u
swapon --show; echo "(no swap configured -> exit $?)"
sudo -u postgres psql -d panel -tAc "SELECT key || ' = ' || value FROM settings WHERE key IN ('app::registration_enabled','app::telemetry_enabled','app::url') ORDER BY key"

The panel database is created fresh on first boot, with the schema migrated and exactly one administrator, the account whose password is in your credentials file:

sudo -u postgres psql -d panel -tAc "SELECT count(*) || ' tables migrated' FROM information_schema.tables WHERE table_schema='public'"
sudo -u postgres psql -d panel -c "SELECT username, email, admin FROM users"

To add colleagues, sign in as the administrator, open Admin then Users, and select Create. You can assign roles under Roles to scope what each person can do. If you would rather let people sign themselves up, re-enable registration under Admin then Settings.

Step 11 — Add a custom domain and HTTPS

The panel serves plain HTTP on port 8000. For a public deployment, put it behind a reverse proxy that terminates TLS. Point a DNS A record at the VM's public IP, allow 443/tcp in the NSG, then install nginx and Certbot and proxy to the panel:

sudo apt-get update && sudo apt-get install -y nginx certbot python3-certbot-nginx
sudo tee /etc/nginx/sites-available/calagopus >/dev/null <<'NGINX'
server {
    listen 80;
    server_name panel.your-domain.example;
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
NGINX
sudo ln -sf /etc/nginx/sites-available/calagopus /etc/nginx/sites-enabled/calagopus
sudo systemctl reload nginx
sudo certbot --nginx -d panel.your-domain.example

Then set the panel's application URL to the new address, under Admin then Settings, so links and passkey origins match what browsers use.

Step 12 — Maintenance

Ubuntu's unattended upgrades are enabled, so security patches for the operating system arrive automatically. The two periodic settings below are what drive them:

cat /etc/apt/apt.conf.d/20auto-upgrades
systemctl show -p UnitFileState --value unattended-upgrades.service

The panel writes its logs to /var/log/calagopus, and you can follow the service directly through the journal:

sudo ls -1 /var/log/calagopus/ 2>/dev/null | tail -5 || echo "no panel logs yet"
sudo journalctl -u calagopus -n 5 --no-pager

To back up the panel, dump its PostgreSQL database and keep a copy of the environment file that holds the encryption key:

sudo -u postgres pg_dump panel | gzip > /var/backups/calagopus-$(date +%F).sql.gz
sudo cp /etc/calagopus/panel.env /var/backups/calagopus-panel-env-$(date +%F)

Store those somewhere off the VM. The environment file contains your encryption key, so treat it as sensitive. To upgrade Calagopus itself, follow the upstream release notes; cloudimg publishes refreshed images as new upstream versions are released, so redeploying from a newer image and restoring your database is usually the simplest path.