← Lab Notes
June 4, 2026 HomelabNetworkingServers

Running a Minecraft Server on Real Hardware with AMP

A walkthrough of deploying a Minecraft Java server using CubeCoders AMP — covering installation, a hardware migration driven by I/O contention on shared NAS storage, and DNS configuration via Cloudflare to keep the home IP private.


Overview

AMP (Application Management Panel) by CubeCoders is a web-based game server management tool that lets you deploy, configure, and monitor game servers through a browser dashboard rather than managing processes manually. This post covers how I got a Minecraft Java server running through AMP, why I had to migrate it mid-way through, and how I set up DNS so players connect cleanly without me exposing my home IP.

Background

A coworker mentioned they were using AMP to host a Palworld server for friends. It sounded like a cleaner alternative to babysitting server processes by hand, so I decided to give it a shot for Minecraft. BreadLab already had the hardware to support it — the question was just where to run it and how to expose it properly.

How It Works

AMP installation
I initially installed AMP on an Ubuntu VM. The install process is straightforward — CubeCoders provides a script and the panel comes up quickly. From there, spinning up a Minecraft Java instance is a few clicks: pick the game, set your memory allocation, configure the port, start the server.
I exposed the AMP management panel itself through a Cloudflare tunnel so I could manage it remotely without opening any ports. Game server traffic is handled separately.
The migration
Players started reporting latency despite the VM having plenty of CPU and RAM headroom. After some digging, I suspected disk I/O contention. The VM was running on NFS-backed storage on my NAS — the same NAS handling iSCSI for other VMs and serving Jellyfin. SATA spinning disks under that kind of combined load were quietly becoming a bottleneck.
Rather than tune around it, I migrated AMP to a dedicated Windows workstation: i5 14th gen, 64GB RAM, local SSD, dedicated GPU. No shared storage, no competing workloads. AMP's Windows installation is just as simple as Linux — the installer handles most of the setup.
DNS setup
Players connect via mine.breadtoasting.com. This is handled with two DNS records in Cloudflare:

An A record pointing the subdomain at Cloudflare's edge
An SRV record that directs Minecraft clients to the correct port behind the scenes

The SRV record is the piece people commonly skip. Without it, players have to manually type the port every time. With it, mine.breadtoasting.com works in the vanilla client with no extra steps — and my home IP is never exposed to anyone connecting.

Results

The production server is running current release Minecraft Java Edition, vanilla, no plugins. Since migrating to dedicated local storage the latency complaints stopped entirely. The AMP dashboard makes day-to-day management — restarts, config changes, checking who's online — fast enough that I rarely need to touch the underlying machine directly.

Lessons Learned

Storage matters more than you'd expect. Minecraft isn't particularly I/O heavy in isolation, but on a NAS already under load from other services, that assumption breaks down. Dedicated local SSD storage eliminated the problem entirely and was the right call.
AMP is excellent for supported games, limited for everything else. For titles in its library it stays out of your way. For anything custom or unsupported, you're fighting the tool more than using it. Know that going in.
SRV records are worth the five minutes it takes to set them up. Clean hostname, no port exposed to players, home IP stays private. No reason not to do it from day one.
What's next: A modded instance is planned as a parallel server — AMP handles multiple instances reasonably well and I'll document that process when it's set up. Plugins on the production server are also on the radar, likely moving to Paper when that happens since it's plugin-compatible and performs better than vanilla under load.

Was this useful?