Install the panel first, verify it locally, then add controlled remote access
Calagopus Panel is an open-source game server management panel with a Rust and Axum backend and a browser-based React frontend. This guide explains how to approach installation without guessing commands, ports, paths, or system requirements that must come from the current Calagopus documentation. We will cover installation planning, configuration, startup, and local verification before introducing Localtonet. Once the panel works on its local address, an HTTP tunnel can provide a public HTTPS address without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Understand the Calagopus Panel deployment model
Calagopus is a self-hosted management panel designed for administering game servers. Its project documentation describes a backend built with Rust, Tokio, and Axum, together with a frontend built using React, Mantine, and Tailwind. The project also uses container-based game-server management and supports Pterodactyl-style eggs. These architectural details are useful when deciding where to deploy the panel, but they do not establish a specific listening port, local URL, bind address, or installation command.
The official Calagopus website identifies Docker and traditional installation as supported deployment approaches. The project repository, however, directs users to the official installation documentation instead of presenting a complete installation procedure in its README. That distinction matters. Repository files such as Compose definitions or environment examples may offer useful context, but selecting individual files and improvising an installation around them can miss required initialization, migration, security, or upgrade steps.
Use the current Calagopus installation documentation as the authority for prerequisites and commands. Choose one documented deployment method, follow it from beginning to end, and record the resulting web endpoint. Do not assume that an example from an older release, a community guide, or another game-server panel remains compatible with the version you are installing.
Prepare the host before installing
Start by identifying the machine that will run Calagopus and the deployment method you intend to use. Because the supplied installation evidence does not state exact operating-system versions, package requirements, CPU or memory minimums, filesystem paths, or network defaults, those values must be checked in the current official documentation. This article intentionally does not invent them.
For a Docker-based deployment, confirm that the host satisfies every container-runtime and Compose requirement listed by Calagopus. For a traditional installation, follow the documented operating-system, database, runtime, service-management, and permission requirements. The Calagopus website also states that ARM64 is supported and that its Docker Compose setup can run on a Raspberry Pi, but hardware suitability still depends on the panel workload and the game servers being managed.
Before making changes, decide where persistent data and backups will live. If you are migrating an existing panel, create and verify a recoverable backup according to the source panel's procedures. Also review the Calagopus release and migration documentation for version-specific cautions. A database migration or panel conversion should never be treated as reversible unless the relevant documentation explicitly says so and you have independently tested restoration.
The available evidence does not establish a universal Calagopus command, port, URL, bind address, environment file, database credential, or installation directory. Obtain those details from the current official Calagopus documentation for your selected deployment method. Copying plausible values from another panel can produce an insecure or nonfunctional installation.
Install, configure, and start Calagopus
The following workflow is a set of verification checkpoints, not a replacement for the official Calagopus installation procedure. Commands and required fields can change between releases and deployment methods. Keep the official documentation open, execute its steps in the documented order, and use these checkpoints to confirm that no major stage has been skipped.
Select one official installation method
Choose the current Docker or traditional installation path from the Calagopus documentation. Check that the instructions apply to your operating system, architecture, and intended release. Do not combine Compose instructions with traditional service or database instructions unless the documentation explicitly requires it.
Install the documented prerequisites
Prepare the container runtime, database components, system packages, permissions, storage, and other dependencies specified for the selected method. Use only the versions and commands supported by the current documentation.
Apply the required configuration
Complete the documented application, database, storage, and service settings. Generate or enter real secrets through the supported workflow, keep them out of shell history and screenshots, and never copy placeholder credentials into a production deployment.
Run initialization and start the panel
Execute the documented initialization, migration, or startup procedure for the chosen installation type. Confirm that every required container or service remains running rather than relying only on a successful command exit.
Complete the first-run setup
Open the panel through its documented local address and complete the guided first-run workflow. Configure administrative access carefully and confirm that you can sign out and authenticate again before considering remote access.
Verify the panel on the local network
Local verification separates application problems from tunnel problems. If the interface does not work locally, adding a public endpoint will not repair the panel, its database, or its container configuration. Test from the Calagopus host first. If the documented bind address permits access from another machine on the LAN, test there as a second check.
Record the exact scheme, host or local IP address, and port that produced the working interface. The scheme may be HTTP or HTTPS depending on the documented deployment and any reverse proxy you configured. Do not change it merely because the future public Localtonet address uses HTTPS. The Localtonet tunnel's local target must match the service that is actually listening.
Confirm that the interface loads completely, not just that the first HTML response appears. Sign in, navigate between several panel pages, and verify that the browser does not report failed application requests. Review the panel or service logs for repeated startup failures, database errors, permission problems, or restart loops. If the installation uses multiple containers or services, verify all required components rather than checking only the frontend.
| Value to verify | How to establish it | Why it matters |
|---|---|---|
| Local scheme | Use the scheme shown by the working documented installation | The tunnel target must correspond to the actual local web service |
| Local IP or hostname | Confirm where the panel is reachable from the Localtonet client device | The client must be able to connect to the target over the local network |
| Listening port | Read it from the active configuration and verify it with a real browser request | Guessing a common web port can send the tunnel to the wrong service |
| Panel authentication | Sign out and sign back in through the local interface | A remotely reachable administrative panel needs functioning access control |
| Service health | Inspect the documented status and log mechanisms | A stable local service is required before troubleshooting remote access |
A complete endpoint has a scheme, a reachable local IP address or hostname, and a port. The Calagopus evidence supplied for this guide does not define those values, so your working installation is the authority. The Localtonet client must run on the same device or another device that can reach that endpoint.
Expose the working panel with a Localtonet HTTP tunnel
After Calagopus works locally, you can create an HTTP tunnel with Localtonet. Our client establishes an outbound connection to a Localtonet relay server, so the workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The resulting tunnel provides a public URL and remains available only while the selected client device is connected and the tunnel is running.
An HTTP tunnel is appropriate for the Calagopus browser interface because it forwards web traffic to the verified local web endpoint. This configuration does not automatically publish the TCP or UDP ports used by individual game servers. Those are separate services and would require their own protocol-appropriate configurations based on the documented port and transport requirements of each game.
Exact dashboard availability, relay-server choices, process options, and plan coverage can vary. Obtain current server or region values from the dashboard rather than copying a hardcoded value from an article. The complete current workflow is also available in our HTTP tunnel documentation.
Install and run the Localtonet client
Install our client on the Calagopus host or another device that can reach the verified panel endpoint. Keep the client running because it establishes the outbound connection used by the tunnel.
Authenticate or select the client device
Use the device-specific authentication token through the supported client workflow, then select that device for the tunnel. Treat the token as a secret and never place it in screenshots, public configuration examples, support posts, or source control.
Select an available relay server
Choose an available server or region from the current dashboard. Do not hardcode a server code from an old tutorial because availability can change.
Create the HTTP tunnel configuration
Configure the tunnel to target the exact local IP address and port verified during Calagopus testing. For the public address, HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain process types where supported. Check current documentation before configuring custom-domain DNS.
Start the tunnel and test the public URL
Creating a tunnel does not start it. Press Start, open the assigned public URL, and confirm that the Calagopus sign-in page and authenticated interface behave correctly. Test from a network other than the host LAN when possible.
Stop or delete access when appropriate
Stop the tunnel when remote panel access is not needed, or delete it if the configuration is no longer required. The public endpoint is available only while the selected client is connected and the tunnel is running.
Protect an internet-accessible administration panel
Remote convenience changes the panel's exposure boundary. Before sharing or bookmarking the public address, verify that Calagopus authentication is enabled and that administrative credentials are unique and appropriately protected. Review the panel's current security documentation for supported controls. Apply least privilege to user accounts and avoid giving routine users administrative permissions.
Keep Calagopus, its dependencies, and the host operating system updated through their documented upgrade procedures. Back up persistent data before upgrades and test restoration rather than assuming a backup is usable. Review application logs for unexpected authentication activity or repeated failures. If remote access is needed only during maintenance, stop the tunnel after the session instead of leaving it running indefinitely.
Localtonet provides connectivity to the configured local target. It does not remove the need for Calagopus authentication, least-privilege accounts, safe credential handling, host maintenance, and application updates. Never expose an unfinished first-run wizard, an unauthenticated administrative interface, or a test deployment containing default or placeholder credentials.
Keep panel access and game traffic separate
The Calagopus web interface is an HTTP application, but managed game servers may use raw TCP, UDP, or both. Publishing the panel does not make those game services reachable. Conversely, exposing a game port does not provide access to the panel interface. Treat each service as an independent network target with its own protocol, local address, port, authentication model, and exposure decision.
| Service | Likely tunnel family | Required evidence before configuration |
|---|---|---|
| Calagopus web interface | HTTP tunnel | Verified local web scheme, reachable IP address, port, and working authentication |
| TCP-based game service | TCP tunnel | The game's documented TCP port and the local server address |
| UDP-based game service | UDP tunnel | The game's documented UDP port and the local server address |
| Game using both transports | Combined UDP/TCP or separate configurations as appropriate | Authoritative documentation confirming both protocols and their exact ports |
No game ports are specified by the evidence used for this installation guide, so none should be assumed. Determine them from the documentation for the particular game image, egg, or server configuration. Expose only the services that users genuinely need and stop obsolete tunnels when workloads are removed.
Frequently asked questions
What command installs Calagopus Panel?
There is no single command established by the supplied evidence. Calagopus supports Docker and traditional installation approaches, and the correct commands depend on the current official documentation, deployment method, operating system, architecture, and release. Follow one documented method without combining instructions from another path.
Which local port does Calagopus use?
The supplied project evidence does not state a universal listening port. Read the port from your documented configuration and verify it by opening the panel locally. Use that confirmed value as the Localtonet HTTP tunnel target rather than assuming a common HTTP port.
Must Localtonet run on the same machine as Calagopus?
Not necessarily. The Localtonet client can run on the Calagopus host or another device that can reach the panel's local IP address and port. The selected client must remain connected, and the tunnel must be running for the public endpoint to remain available.
Does the HTTP tunnel also expose managed game servers?
No. The HTTP tunnel targets the Calagopus web interface. Individual game servers may require TCP, UDP, or combined UDP/TCP connectivity. Configure those separately only after confirming the exact protocol and port from authoritative documentation for the game service.
Does creating a Localtonet tunnel make it active immediately?
No. Creating the configuration does not mean the tunnel is running. Start it with the Start button, verify the assigned public URL, and stop or delete the tunnel when it is no longer required.
Can Localtonet fix a Calagopus installation that does not work locally?
No. Resolve installation, database, startup, permission, and application errors before creating the tunnel. Localtonet forwards traffic to the configured local service, so that service must already be reachable and healthy from the client device.
Access your verified Calagopus panel with Localtonet
Finish the official Calagopus installation, confirm the complete local web endpoint, and secure the panel before exposing it. Then use our HTTP tunnel workflow to provide controlled remote access without configuring inbound router port forwarding.
Get Started Free →
