Self-Host Pumpkin Minecraft Server with Localtonet

Understand Pumpkin and the scope of this setup

A self-hosted Minecraft server has two separate layers. Pumpkin loads the world, handles players, and implements gameplay. The network path determines whether a player can reach that running server. We test those layers separately: first establish a working local game, then add a public route to it. A tunnel cannot repair an incompatible client, a broken world, or a server that has failed to start.

The official Pumpkin website describes one native executable with no Java runtime required for the server. This does not mean that the same download runs on every operating system or processor. You still need an artifact appropriate for the host, and your Minecraft client has its own requirements. The Pumpkin repository is the place to inspect the project, its code, and release-specific information.

Pumpkin now describes Java and Bedrock players joining the same world through built-in support, without an additional crossplay proxy or plugin. That capability is distinct from the networking configuration demonstrated here. We expose only the verified Java Edition TCP listener. A working TCP tunnel does not by itself expose a Bedrock UDP listener.

Prepare the host and collect the prerequisites

Use a machine you control and are authorized to run a public-facing service on. It must remain awake, online, and connected throughout play. For the simplest setup, run Pumpkin and the Localtonet client on the same host. A separate Localtonet device also works, provided it can reach Pumpkin over the local network.

Before starting, prepare the following:

• A suitable Pumpkin download: an executable offered by the official project for your operating system and CPU architecture.
• A writable server directory: a dedicated folder owned by the account that will run Pumpkin, with room for world growth and backups.
• A compatible Minecraft Java Edition client: match the game version supported by your selected Pumpkin build, rather than assuming every Minecraft release works.
• A terminal and local administrative access: enough to inspect startup errors and network listeners, without routinely running the game server as an administrator or root.
• A Localtonet account and client: installed on a device that can reach the server.
• A backup destination: preferably separate from the live server disk, not merely another directory inside the world.

There is no verified universal CPU, RAM, storage, or player-count requirement in the evidence for this guide. Size the machine through testing with your world and player workload. A small idle server is not a reliable predictor of memory use during exploration or sustained multiplayer activity.

Create a short setup record. Include the Pumpkin build identifier, download origin, server working directory, client version, configuration locations, world-data locations, Java listening address, and Java port. Later, add the Localtonet device, relay choice, and assigned public endpoint. Keep the device token out of this record if it will be shared.

Download Pumpkin, start it, and inspect its configuration

Download the appropriate native executable

Open Pumpkin's official website and follow its Download entry. Select an available artifact matching your host's operating system and architecture. If the project distinguishes release channels or build identifiers, record the one you choose. Do not download an executable from a reposted link or infer compatibility from an unrelated Minecraft server tutorial.

Place the downloaded executable in your dedicated server folder. If it arrives in an archive, extract it before launching. Use the actual artifact name in your terminal. The names pumpkin and pumpkin.exe below are illustrative local filenames, not a promise about current download naming.

On a compatible Unix-like host, an executable saved as pumpkin can be launched from that directory as follows:

# Run from the directory containing your downloaded executable.
# Replace "pumpkin" if your file has a different name.
chmod u+x ./pumpkin
./pumpkin

For a compatible Windows build saved as pumpkin.exe, open PowerShell in the server directory and run:

# Replace the filename if your download uses another name.
.\pumpkin.exe

These are operating-system execution examples, not claims that every current Pumpkin build supports both environments. A prebuilt native executable does not need java -jar. It also does not require a Rust compiler merely because Pumpkin is written in Rust. Building from source is a different workflow with its own toolchain requirements and is outside this binary-based tutorial.

Keep the first launch visible

Use a terminal rather than immediately installing a background service. Read the entire startup output. Look for configuration loading, world initialization, a listening endpoint, and any fatal error. If the process exits, retain the error message and solve it before adding Localtonet. Restarting repeatedly without reading the first failure often obscures the cause.

Run from the same working directory each time. Relative configuration and data paths can depend on that directory. Accidentally launching from a different folder can make a server appear to have lost its settings or created a new world. Record any explicit paths printed by the application instead of assuming all persistent files are beside the executable.

If the build presents a required agreement or initialization action, complete the displayed process before continuing. Do not copy a vanilla server's file layout, startup flags, or agreement procedure unless the Pumpkin build explicitly uses it.

Discover and edit the active configuration

Pumpkin's project materials describe TOML configuration, and its current site describes separate subsystem configuration files. Inspect the configuration files created or identified during startup, including any generated comments. Do not assume that a single server.properties file controls this server or paste a configuration block intended for another Minecraft implementation.

Identify the settings controlling the Java listener, client compatibility, authentication, player admission, administrator privileges, and world storage. Where a field's meaning is unclear, leave it unchanged until you have checked its description for your build. Similar-looking keys in older examples may have moved or changed meaning.

Before editing, stop the process using the build's documented graceful shutdown procedure and copy the original configuration. Change one concern at a time, retain valid TOML syntax, then restart from the same directory. Confirm that startup actually loads the file you edited. A valid file in the wrong directory has no effect.

Record the listening address and port

Use startup output and active configuration together to determine the Java TCP endpoint. If needed, inspect the host's listening sockets. On Linux, ss -ltnp lists TCP listeners; on Windows, Get-NetTCPConnection -State Listen provides listening addresses, ports, and owning process IDs. These are diagnostic tools, not Pumpkin commands, and visibility can depend on permissions.

# Linux: inspect listening TCP sockets.
ss -ltnp

# Windows PowerShell: inspect listening TCP sockets.
Get-NetTCPConnection -State Listen |
    Select-Object LocalAddress, LocalPort, OwningProcess

Match the socket to the Pumpkin process. A port owned by another server is not evidence that Pumpkin started correctly. If the output shows a wildcard bind such as 0.0.0.0, use a concrete reachable address for connection tests, not the wildcard itself.

Verify the Java Edition server locally

With Pumpkin still running, open a compatible Minecraft Java Edition client. Select Multiplayer, then Direct Connection or Add Server, and enter the verified address and port. For example, 127.0.0.1:25565 is appropriate only when the game client is on the Pumpkin host and Pumpkin is reachable through IPv4 loopback on that particular port.

Join the world rather than stopping at the server-list status. Confirm that login completes, terrain loads, and basic movement works. Watch the server console during the attempt. A successful status ping tests less than a completed player session, and neither proves that every gameplay feature you need is implemented.

If Localtonet will run on another machine, perform a second reachability test from that machine or its network context to Pumpkin's LAN address. A same-host loopback test does not prove this second route works.

Containers and virtual machines can introduce another network boundary. A client inside a container sees its own loopback, not necessarily the host's. This guide does not prescribe a Pumpkin container installation, but the same rule applies to any deployment: validate the destination from the environment where the Localtonet client actually runs.

Choose TCP for this Java Edition workflow

Our client establishes an outbound connection to a Localtonet relay. A TCP tunnel then forwards its public host and port to the local TCP service reachable from that client. This removes the need for inbound router port forwarding, a public IP address, or VPN setup for this workflow. It does not bypass organization policies or remove the need for permitted outbound connectivity and local service reachability.

Available tunnel options and relay choices can vary. Select values shown in your current dashboard rather than copying a region code, plan assumption, or public address from a screenshot.

Expose Pumpkin through a Localtonet TCP tunnel

Keep Pumpkin running and use the endpoint that passed the local test. The sequence below follows our documented common tunnel lifecycle. The supplied material does not include a current TCP-page screenshot or a separate field-by-field TCP procedure, so dashboard labels beyond the established concepts are not assumed. Our Localtonet documentation provides the current client installation and TCP tunnel guidance.

Verify from outside the host network

Ask an intended player on another network to connect, or test from a genuinely separate connection. In Minecraft Java Edition, enter the assigned public endpoint as PUBLIC_HOST:PUBLIC_PORT, replacing both placeholders. Do not add https://, and do not substitute the local port for the assigned public port.

Keep Pumpkin's console and our dashboard visible. Confirm the player completes login and enters the world. If the external test fails, repeat the local join before changing the tunnel. That quick comparison tells you whether the failure remains local or appears only on the public route.

The session depends on three things remaining available: Pumpkin, the selected connected Localtonet client, and the running tunnel. A sleeping laptop or a closed client interrupts remote access even if its configuration still appears in the dashboard.

Review access and administration before sharing the endpoint

Review the authentication, player-admission, and permission features documented for your Pumpkin build. If it provides an allowlist, configure it for intended players and test both an admitted account and an unlisted account. Do not assume that a familiar vanilla or Paper command has identical syntax or behavior in Pumpkin. The available evidence does not establish a stable administrative-command list, so no unverified allowlist or operator commands are supplied here.

Limit elevated game privileges to trusted administrators. Keep console access and the server directory private. Run the executable under an account with access only to the files it needs, and do not forward a management port merely because it is present. The tunnel target should be the game listener you tested.

Start without unnecessary plugins. Pumpkin has its own plugin ecosystem, and its site describes Bukkit/Paper compatibility through PatchBukkit as early with gaps. A plugin working on another server implementation is not proof that it is compatible here. Test extensions on a copied world before giving them access to a live server.

Keep the operating system, Pumpkin, and our client maintained, but separate security maintenance from blind upgrades. Protect backups because they can include player information and configuration. Avoid posting full logs publicly without reviewing them for credentials, identifiers, and private network details.

Operate, back up, and upgrade the server safely

Use a predictable session checklist

Start Pumpkin from its recorded working directory. Check for startup errors and verify the expected world and Java endpoint. Start the Localtonet client, confirm the correct device is connected, then start the intended tunnel. Check the current public endpoint before telling players where to join.

During play, monitor console errors, disk space, CPU, memory, and the host's connection. If players report slow gameplay while connections remain established, compare a local player with a remote player. Similar problems for both suggest server workload or game behavior rather than solely the public route.

For planned shutdown, notify players and allow them to disconnect. Stop the public tunnel, then use Pumpkin's release-supported graceful shutdown procedure and wait for the process to exit. Do not treat closing a terminal or forcibly terminating a process as a verified save operation. If you have not established how your build shuts down cleanly, do that on the disposable world before relying on it for persistent play.

Back up a consistent, stopped server

A straightforward backup method is to copy persistent data after a clean shutdown. Copying a world while files are actively changing can produce an inconsistent snapshot. Without a verified live-backup procedure for the selected build, use a maintenance window.

1. Stop public access, shut Pumpkin down gracefully, and confirm the process has exited.
2. Copy the entire server directory and any separately configured world, player-data, or plugin-data paths.
3. Retain the configuration and executable version used with that data.
4. Store a dated copy outside the live server directory, preferably on a separate device or backup service.
5. Test restoration into a separate directory without exposing it publicly or allowing it to write to the original world paths.

A backup is useful only if the restored copy loads. In the isolated test, join the world and check representative saved progress. Retain more than one recovery point so an unnoticed problem does not immediately replace your only good backup.

Treat upgrades as a migration test

Before replacing the executable, read the selected build's change notes and make a stopped-server backup. Keep the old executable with its matching data and configuration. Test the new build on a separate copy, verify that configuration still loads, and inspect warnings about renamed or removed keys.

Join locally, test the gameplay your group uses, and exercise any plugins before restoring public access. A successful launch is not proof of complete world or feature compatibility. Avoid running the old and new processes against the same world at the same time.

If the upgrade fails, restore the pre-upgrade world and configuration together with the old executable. Merely replacing the new executable with an old one may not reverse data changes already written by the newer build. Do not experiment with rollback on your only remaining copy.

Troubleshoot by symptom and network hop

The executable will not launch

Check that the artifact matches the host OS and processor architecture and has been extracted if necessary. On a Unix-like system, inspect executable permission. If the error names a missing runtime library, follow the requirement for that specific artifact rather than installing unrelated packages. Do not respond to an architecture error by repeatedly changing network settings.

Pumpkin starts and immediately exits

Read the first fatal error. Common categories to investigate are malformed configuration, unwritable data directories, a conflicting listener, or world-loading failure. Preserve the original files before changing them. Testing the same executable in a separate empty directory can help distinguish a basic launch failure from an existing configuration or world problem.

The local client cannot join

Confirm that Pumpkin is still running and owns the intended TCP listener. Check the exact client version, destination address, and port. If another machine is connecting, a loopback-only listener will not be reachable over the LAN. Review authorized host-level rules for the specific path rather than disabling the firewall globally.

Local play works, but public access fails

Check the selected Localtonet device first, then tunnel state, then the local target. A target of 127.0.0.1 on a different device points to that device, not the Pumpkin machine. Re-test from the client's network environment. Finally, ask the player to re-enter the current public host and assigned port, including any non-default port.

Pumpkin sees the connection but rejects login

Traffic is reaching the application. Inspect the disconnect reason, client compatibility, authentication, player-admission settings, and build-specific limitations. Recreating the tunnel is unlikely to repair a game-version mismatch or permission rejection. If it fails identically on the local path, focus on Pumpkin first.

Connections work, but play is slow or unstable

Compare local and remote behavior, monitor resource pressure, and check whether problems coincide with exploration, world saving, or particular plugins. For remote-only problems, inspect host connectivity and evaluate another available relay as a controlled test. Do not change the server version, configuration, relay, and plugins simultaneously, or you lose the ability to identify the cause.

The wrong world appears after a restart

Check the working directory and active world paths before assuming data loss. Stop the server and inspect the saved setup record. A different relative path can create or open another world. Preserve both directories until you establish which one contains the intended data.

Java works, but a Bedrock player cannot connect

This guide exposes only Java TCP traffic. Pumpkin's built-in multi-edition support does not make that public TCP endpoint a verified Bedrock endpoint. Confirm the current build's Bedrock configuration and local UDP behavior separately before creating an appropriate tunnel. No Bedrock port or bind setting is established by the evidence used here.

Frequently asked questions