Run the Wings management daemon locally, verify its HTTP API, and publish only the endpoint you intend to reach
Calagopus Wings is a Rust-based, Pterodactyl-compatible daemon for managing game-server workloads. This guide explains what Wings exposes, how to approach installation without guessing unsupported commands, how to verify the local HTTP service, and how to connect that working service to a public HTTPS address with Localtonet. We also separate the Wings API from its optional SFTP service and from the TCP or UDP ports used by individual game servers. That separation is essential because each service has different exposure and security requirements.
📋 What's in this guide
What Calagopus Wings is and what you should expose
Calagopus Wings is a rewrite of Pterodactyl Wings in Rust. Its stated goal is API compatibility with Pterodactyl while adding its own features and implementation changes. It is the node-side service in a game-server management architecture, not simply a conventional website. Its responsibilities can include accepting HTTP API requests, supporting WebSocket-based server interactions, managing files and server operations, and optionally providing SFTP or remote-shell functionality.
These interfaces should not be treated as one interchangeable network service. For the workflow in this guide, the relevant target is the Wings HTTP API server. Documented routes include GET /openapi.json and GET /api/stats. The OpenAPI route may be disabled through Wings configuration, so an unavailable /openapi.json response does not automatically prove that the daemon is stopped.
The API also should not be confused with a hosted game server. A Minecraft, Rust, ARK, Valheim, or other game instance has its own listening ports and transport requirements. Depending on the game, those may involve TCP, UDP, or both. The optional Wings SFTP or SSH listener is another separate service. An HTTP tunnel aimed at the Wings API does not automatically publish any of those additional listeners.
In this guide, “expose Wings” means connecting the verified Wings HTTP API to a Localtonet HTTP tunnel. It does not mean publishing every game-server port, the SFTP listener, the Docker socket, the host SSH service, or an entire private network.
Prerequisites and information to collect
Installation should begin with the system that will run Wings and its managed workloads. Wings is associated with game servers running in Linux containers, but the supplied installation evidence does not establish a complete operating-system support matrix, minimum package list, CPU architecture list, Docker version, memory requirement, storage requirement, or firewall baseline specifically for the current Wings release. Those details can change as the project evolves.
Before modifying a production node, open the current Calagopus Wings installation documentation and select the installation method documented for your environment. The project repository points readers to that documentation rather than presenting a canonical command sequence in its README. That matters because copying an unverified package command, binary path, service name, or container procedure from an older tutorial could leave the daemon incomplete or install a mismatched release.
Record the following deployment-specific values while following the official installation procedure. They will be needed for local verification and the later Localtonet configuration:
- The supported host operating system and architecture selected in the current Wings documentation.
- The installation method, such as a documented binary, service, or container path.
- The installed Wings version.
- The Wings configuration-file location supplied by the installation method.
- The API bind address and API listening port from the active configuration.
- Whether the local API uses HTTP or TLS in your installation.
- Whether
/openapi.jsonis enabled or disabled. - The authentication and authorization expected by the panel and API.
- Whether the optional SFTP listener and remote shell are enabled.
- The separate ports and transports assigned to each hosted game server.
You also need a Localtonet client running on the Wings host or on another device that can reach the Wings API over the local network. The client establishes an outbound connection to our relay server, so the workflow does not require inbound router port forwarding, a public IP address, firewall changes, or VPN setup. The tunnel is available only while the selected Localtonet client is connected and the tunnel is running.
| Component | Value you must obtain | Why it matters |
|---|---|---|
| Wings API | Actual local IP address, port, and HTTP or TLS mode | These values define the local target for the Localtonet tunnel. |
| Wings configuration | Active configuration path and API settings | Editing the wrong file can produce a false sense that a setting changed. |
| OpenAPI route | Whether API documentation is enabled | The /openapi.json route can be disabled and is therefore not a universal health check. |
| SFTP or SSH | Enabled state and configured listener | It is a separate non-HTTP service and should not be mixed into the API tunnel. |
| Game server | Per-game TCP and UDP ports | Players connect to game services, not to the Wings management API. |
| Localtonet client | Device-specific token and an available relay selection | The token identifies the client device, while the selected relay determines where the tunnel is established. |
A Localtonet device token is device-specific and must not be guessed, published, or embedded in a code example. Apply the same rule to Wings API credentials, panel secrets, SFTP credentials, private endpoints, and game-server administration passwords.
Install Calagopus Wings using the current official procedure
A safe installation guide must use commands, package names, paths, and service definitions that are established by the project's current documentation. The evidence available for this draft confirms that the repository delegates installation to the Calagopus documentation, but it does not establish an exact command sequence, supported package matrix, container command, default path, service-unit name, or default port.
For that reason, we will not invent a shell command or pretend that one method applies to every host. Use the current official installation page and complete the documented process for your selected environment. The following sequence explains how to carry out that process safely without replacing any project-specific instructions.
Select the documented installation path
Open the current Wings installation documentation and select only a method explicitly supported for your host. Do not infer that the presence of repository Docker files makes every container command, compose file, host distribution, or deployment layout production-ready for your situation.
Complete the documented prerequisites
Install the runtime, container engine, system packages, directories, users, permissions, and dependencies required by the selected official method. Use the versions and paths shown in the current documentation rather than values copied from an unrelated Pterodactyl deployment.
Install and configure the matching Wings release
Follow the project's documented download or deployment process. Record the installed version and the active configuration location. Keep a protected backup of the original configuration before making local changes.
Start Wings using the documented service mechanism
Use the startup mechanism specified for the selected installation method. The exact command and service name are intentionally not provided here because they are not established by the supplied evidence and can differ between installation paths.
Inspect startup status and logs
Confirm that the process remains running and review its startup output through the logging mechanism documented for your installation. Resolve configuration parsing, permissions, container, storage, or port-binding errors before attempting remote access.
Do not create a public tunnel as a substitute for a successful installation. If Wings stops immediately, repeatedly restarts, cannot reach its container runtime, or fails to bind its configured API listener, Localtonet cannot correct that local application problem. The local service must be healthy first.
Review the Wings configuration before remote access
Wings exposes a broad configuration surface. The repository documents API settings, system and disk-management behavior, SFTP limits, file history, backup behavior, archive formats, and concurrency controls. Not every option needs to change for an initial deployment, but several categories deserve review before the API becomes remotely reachable.
Confirm the API listener
Find the API listener in the active Wings configuration and record its bind address, port, and transport mode. This guide cannot provide a default because the supplied evidence does not establish one. If Wings listens only on a loopback address, the Localtonet client normally needs to run on that same host to reach it. If the client runs on another LAN device, the API must be reachable from that device using an address permitted by your local network design.
Do not change a loopback listener to a broad network listener merely because a generic tutorial suggests it. First decide where the Localtonet client will run. Keeping the client on the Wings host can reduce the need to expose the management API across the local network.
Decide whether OpenAPI documentation should be available
Wings includes a disable_openapi_docs configuration option. The documented value false leaves the /openapi.json endpoint available, while enabling the disabling option removes that convenient verification route. API documentation can help during development, but publishing an interface description may provide unnecessary detail on an internet-reachable management service.
If you disable the OpenAPI route, plan another authorized method for verifying the API. The documented /api/stats route is a candidate, but its required authorization and exact response are not established by the supplied evidence. Do not assume it is anonymous or use guessed credentials.
Review SFTP and remote-shell exposure
The Wings configuration includes an SFTP enabled setting, SSH host-key selection, password-authentication behavior, authentication attempt limits, cooldown behavior, connection limits, channel limits, and open-handle limits. It also includes a setting for the Wings remote shell. These are important operational controls, but they do not make SFTP part of the HTTP API.
If your deployment does not require a remotely reachable SFTP or shell service, do not publish one. If it does, assess that listener separately and use a suitable raw TCP workflow with the exact configured port. Never assume a port based on a different Wings, Pterodactyl, Pelican, or SSH installation.
Preserve remote-download network protections
Wings documents a list of blocked CIDR ranges for its remote-download pull endpoint. The listed ranges include loopback, private, link-local, carrier-grade NAT, multicast, and other special-purpose IPv4 and IPv6 networks. These restrictions help distinguish an intended external download from a request toward sensitive local or special-use addresses.
Avoid weakening these protections simply to make a download work. A tunnel creates a route to a service, but it should not be used to bypass application safeguards or network policy. Investigate the requested source, its address resolution, and the intended trust boundary instead.
Treat the Wings API as a privileged management interface. Preserve its application-level authentication, use least-privilege credentials, and limit who receives the public endpoint. Do not rely on an obscure URL as the only control protecting game-server administration.
Verify the Wings HTTP API locally
Local verification separates application failures from tunnel failures. Perform it from the Wings host first. If the Localtonet client will run elsewhere on the LAN, repeat the test from that client device before creating a tunnel.
Construct the local URL from the actual configuration rather than assuming a hostname or port. For a plain HTTP listener, the structure is http://LOCAL_ADDRESS:CONFIGURED_PORT. For a Wings listener configured with TLS, use the scheme and certificate expectations defined by that deployment. No exact address, port, TLS default, or verification command is supplied here because those details are not established by the available project evidence.
Confirm that the Wings process stays active
Use the status and logging method associated with your documented installation. A running process is necessary, although it does not by itself prove that the HTTP listener is accepting requests.
Check the configured listener
Verify that the active configuration contains the address, port, and protocol you intend to use. Check startup logs for a bind conflict or malformed configuration before testing a route.
Request an evidenced API route locally
Open the configured local base URL with /openapi.json if OpenAPI documentation is enabled. If it is disabled, use an authorized route appropriate to your deployment, such as the documented /api/stats route, without guessing authentication details.
Interpret the response carefully
A successful API response confirms routing to Wings. An authorization response can still show that the HTTP listener is reachable, while a connection refusal usually points to a stopped process, wrong address, wrong port, or inactive listener. A missing OpenAPI route can be expected when documentation is disabled.
Repeat the test from the Localtonet client device
This is required when our client runs on another machine. Use the Wings address reachable from that device. If the request fails there but works on the Wings host, fix the local bind address, routing, or host firewall policy before proceeding.
Record the exact working local address and port after verification. That pair is the tunnel target. Do not use the public panel URL, a game-server port, an SFTP port, or an address that works only from a different network namespace.
Connect the verified Wings API through Localtonet
Once the API works locally, Localtonet can expose it without inbound router port forwarding or a public IP address. Our client creates an outbound connection to a Localtonet relay server. An HTTP tunnel then points to the local IP address and port that you verified in the previous section.
HTTP tunnels can use a Random Sub Domain, Custom Sub Domain, or Custom Domain process type. All three serve the target at a public HTTPS address. Availability and exact domain requirements can vary, so consult the current dashboard and documentation rather than assuming that a particular domain option or relay region is included in every plan.
Install and run the Localtonet client
Run our client on the Wings host or on a device that can reach the verified Wings API. If Wings listens only on loopback, place the client on the same host unless you intentionally reconfigure the local listener.
Authenticate or select the client device
Use the device-specific authentication token associated with the client that will carry the tunnel. Keep this token private and verify that the intended device is connected.
Select an available relay server
Choose a currently available server or region in the Localtonet dashboard. Do not copy a server code from an old tutorial because available values must be obtained from the current product interface.
Create the HTTP tunnel configuration
Choose the HTTP tunnel family and enter the verified local IP address and API port as the target. Select the appropriate process type for the public HTTPS address. Do not substitute the SFTP port or a hosted game's port.
Start the tunnel
Creating a tunnel does not start it. Use the Start button and wait until the selected device is connected and the tunnel is running.
Test the assigned public HTTPS address
Append the same verified API route to the assigned public address and test it using the authentication expected by Wings. Compare the result with the local request. Stop or delete the tunnel when remote access is no longer required.
For the current product workflow and available interface options, consult our HTTP tunnel documentation. Use the values displayed in your dashboard instead of hardcoded relay codes, domains, or plan assumptions.
A saved tunnel configuration is not automatically online. The public endpoint works only while the selected Localtonet client is connected and the tunnel has been started. If either condition changes, the endpoint becomes unavailable even if Wings continues running locally.
Security checklist for a remotely reachable Wings API
Publishing a management API changes its reachability. It does not remove the need for authentication, authorization, patching, monitoring, and careful configuration. The safest design exposes the smallest required interface for the shortest required period.
If the panel and Wings communicate through a specific authentication mechanism, preserve that mechanism across the public URL. The supplied evidence does not define the credentials, headers, certificate validation, or panel fields for every deployment, so this article does not invent them. Follow the current Calagopus integration procedure for the exact panel-to-Wings relationship.
Treat WebSocket traffic with the same sensitivity as normal API requests. Server console data, operational events, and management interactions can be privileged. Before relying on WebSockets over the tunnel, verify the current behavior end to end with your installed Wings version and Localtonet configuration.
Routine operations and troubleshooting
Public address fails, but the local API works
Confirm that the Localtonet client is connected, the correct device token was selected, and the tunnel was started. Then compare the configured local target with the address and port that passed local verification. A common mistake is entering the panel port, SFTP port, or a game-server port instead of the Wings API port.
If our client runs in a container or on another machine, remember that 127.0.0.1 refers to that client environment, not necessarily the Wings host. Use only an address that is genuinely reachable from the client while respecting your local security policy.
The public route returns an authorization response
An authorization response can indicate that the request reached Wings successfully but did not contain valid application credentials. Do not disable authentication to make the test pass. Compare the request with the authentication method defined by the current Calagopus deployment documentation and protect every credential used during testing.
/openapi.json returns not found
Inspect the active Wings configuration for the OpenAPI documentation option. The route can be disabled. Also confirm that you are testing the correct base address and installed version. A missing OpenAPI document is not sufficient evidence that the complete API is unavailable.
The API works on the Wings host but not from the client device
This normally points to a local connectivity boundary rather than a relay issue. Check whether Wings is bound only to loopback, whether the destination address is correct, and whether host or network policy permits the client device to reach it. One option is to run the Localtonet client directly on the Wings host so that the API can remain locally bound.
Wings stops or restarts repeatedly
Troubleshoot Wings before the tunnel. Review the logs associated with your official installation method. Relevant categories can include malformed configuration, missing permissions, occupied ports, container-runtime connectivity, storage configuration, quota behavior, or unsupported host assumptions. Do not repeatedly reinstall using random commands because that can create multiple conflicting configurations.
Game players cannot connect through the API URL
The HTTP API URL is a management endpoint, not a universal game proxy. Determine the exact listening ports and protocols used by the individual game server. Localtonet supports raw TCP, UDP, and combined UDP/TCP tunnel families, but each tunnel must point to the correct local service. Do not guess a game's transport or port.
SFTP does not work through the HTTP tunnel
SFTP is an SSH-based service rather than an HTTP route. If remote SFTP access is required, confirm that the Wings SFTP service is enabled, identify its configured port, review password and public-key authentication policy, and assess its connection limits. It would require a separate raw TCP configuration rather than the Wings HTTP API tunnel.
| Symptom | Likely boundary | First check |
|---|---|---|
| Local request is refused | Wings process or listener | Process status, logs, configured address, and configured port |
| Local request works but public request fails | Localtonet client or tunnel | Connected device, tunnel Start state, and local target |
| Public response says unauthorized | Wings application authentication | Expected credentials and authorization method |
| OpenAPI route is missing | Wings API configuration | disable_openapi_docs and the active configuration file |
| Remote SFTP connection fails | Separate SFTP or TCP service | SFTP enabled state, configured port, and authentication policy |
| Players cannot join a game | Individual game-service networking | Game-specific TCP or UDP listeners, not the Wings API URL |
Frequently asked questions
What is the default Calagopus Wings API port?
The supplied evidence does not establish a default API port that is safe to publish here. Read the active Wings configuration and verify the listener locally. Use that exact configured port as the Localtonet HTTP tunnel target.
Can Localtonet expose Wings without router port forwarding?
Yes. Our client establishes an outbound connection to a Localtonet relay server, so the HTTP API can receive a public URL without inbound router port forwarding, a public IP address, VPN setup, or firewall changes. The client must remain connected and the tunnel must be running.
Does an HTTP tunnel also expose Wings SFTP?
No. SFTP uses an SSH-based listener and is separate from the HTTP API. If you need remote SFTP, identify its actual configured port, review its authentication controls, and configure a separate TCP tunnel only after deciding that public access is appropriate.
Will the Wings API tunnel make hosted game servers reachable?
No. The API tunnel publishes only the configured HTTP target. Each game server has separate TCP, UDP, or combined transport requirements. Create separate tunnels using the ports and protocols established by the actual game-server configuration.
Is /openapi.json always available?
No. Wings includes a configuration option that can disable OpenAPI documentation. If the route is intentionally disabled, use another authorized API verification method appropriate to your deployment rather than treating the missing document as proof that Wings is offline.
Should the Localtonet client run on the Wings host?
It can, and that is often the simplest arrangement when Wings listens only on loopback. The client can also run on another device that can reach the API. In that case, verify the API from the client device before creating the tunnel and avoid exposing the listener more broadly than necessary.
Does the public HTTPS URL replace Wings authentication?
No. The public URL provides connectivity to the configured local service. Preserve Wings application authentication and authorization, use least-privilege credentials, and do not treat the endpoint address itself as a secret access-control mechanism.
Why does this guide not provide a one-line Wings installation command?
The project repository directs installation questions to its current documentation, while the supplied evidence does not establish a canonical command, package list, service name, path, container procedure, or default listener. Providing those values without evidence would risk installing the wrong release or creating an unsafe configuration.
Connect your verified Wings API with Localtonet
After Wings is installed, running, and reachable through its configured local HTTP listener, create a Localtonet HTTP tunnel for that exact target. Keep API authentication enabled, start the tunnel only when needed, and manage the connection from our dashboard.
Get Started Free →
