Disclosure: Much of this work has been supported by ChatGPT (including this blog post). I can say I am seriously impressed at how well it works, especially how well it collaborates with me to accomplish the tasks that I want to achieve.
When I first spun up this server, the idea was pretty simple: I wanted somewhere I could host game servers for myself and friends.
It didn’t take very long for that idea to grow.
Over the past several days, I’ve been turning a DigitalOcean VPS into the foundation for what I’m calling the Smithesis Gaming Hub—a place where I can host different games, experiment with self-hosting, and learn a lot more about Linux, Docker, networking, and server administration along the way.
The basic infrastructure is finally in place, so this seems like a good time to document where things stand.
The Hardware
Everything currently runs on a DigitalOcean VPS with:
- 4 AMD vCPUs
- 8 GB of RAM
- 160 GB of NVMe storage
- Ubuntu Server 24.04 LTS
Eight gigabytes of memory obviously puts a limit on how many large game servers I can run simultaneously, but it’s surprisingly capable for what I’m doing right now.
If the project continues to grow, moving to 16 GB is an easy upgrade—and would give me considerably more room to experiment.
Bringing Everything Under Pterodactyl
One of the biggest improvements I’ve made is installing Pterodactyl to manage the game servers.
Before that, the servers were a mixture of native Linux services, LinuxGSM installations, and command-line management. It worked, but every game was effectively its own little administration project.
Pterodactyl gives me one web interface where I can manage all of them.
Behind the scenes, Pterodactyl Wings manages Docker containers for each game server. That gives me a much cleaner architecture:
Pterodactyl → Wings → Docker → Game Servers
Each game gets its own isolated environment while still sharing the resources of the VPS.
More importantly, I now have one place to start and stop servers, watch their consoles, manage files, adjust resource limits, and deploy new games.
Minecraft Bedrock
The first server migrated into Pterodactyl was Minecraft Bedrock.
Minecraft was already running on the VPS, so this wasn’t a fresh installation. I backed up the existing server and world, created a new Bedrock instance through Pterodactyl, moved the existing data into it, and verified that everything survived the migration.
Once I could connect and confirm that the world was intact, the old native service was disabled.
Minecraft currently has 2 GB of RAM available to it, which should be plenty for the relatively small server I’m planning to run.
Valheim
Next came Valheim.
Our Valheim world is called Caledonia, and it also survived the move into Pterodactyl.
The server uses Valheim’s crossplay support and currently has 3 GB of RAM allocated to it. Like Minecraft, the original installation has been retained as a rollback copy but is no longer running.
Keeping those old installations around temporarily has been part of my approach to the migration: don’t destroy the known-good version until I’m confident the replacement works.
Core Keeper—and Fewer Open Ports
Core Keeper ended up being one of the more interesting migrations.
Our world is called Degobah, and I’ve allocated 2 GB of RAM to the server.
But the interesting part isn’t really the memory allocation—it’s how players connect.
Core Keeper supports Steam Datagram Relay, or SDR. Instead of requiring players to connect directly to an exposed game port on my VPS, the server can establish itself through Steam’s relay infrastructure and players connect using a permanent Game ID.
After configuring and testing that setup—including making sure the world persisted properly across server restarts—I removed Core Keeper’s inbound game ports from the DigitalOcean firewall entirely.
Players can still connect, but those ports no longer need to be exposed to the public Internet.
That’s a philosophy I’d like to follow throughout this project:
If a service doesn’t need to be exposed to the Internet, don’t expose it.
It’s More Than a Game Server Now
The VPS has also gradually accumulated some other responsibilities.
I run Foundry Virtual Tabletop on it for tabletop RPG games. Foundry currently lives outside Pterodactyl and runs under its own Linux account with PM2 managing the process.
Then there’s the website you’re reading right now.
Smithesis Gaming Hub runs on WordPress in Docker, with its own MariaDB database.
Caddy acts as the reverse proxy in front of the web services and handles HTTPS, allowing several different applications to coexist on the same machine under their own domains and subdomains.
So what started as a machine for running a game server is now hosting the game servers, their management infrastructure, a virtual tabletop, and the website documenting the whole project.
I’m okay with where this is going.
Connecting the Website to the Game Servers
This is probably my favorite addition so far.
I wanted Smithesis Gaming Hub to be more than a blog about the servers. I wanted the website to actually know what was happening on them.
So I created a small custom WordPress plugin that connects to the Pterodactyl API.
The new Server Status page displays Minecraft Bedrock, Valheim, and Core Keeper and shows whether each server is currently online.
And these aren’t just decorative green dots.
When I stop a server in Pterodactyl, the website detects the actual change in server state and changes its status to Offline. Start it again, and the website returns it to Online.
I tested the entire process in both directions.
The integration is also entirely server-side. The API credentials aren’t sent to visitors’ browsers, and the results are briefly cached so that every page view doesn’t generate a pile of unnecessary API requests.
An API failure is treated separately as Unknown, rather than incorrectly telling visitors that a game server is offline.
It even works with Core Keeper despite the fact that its game ports aren’t publicly accessible, because WordPress is asking Pterodactyl for the server’s actual state rather than trying to probe an Internet-facing port.
It’s a fairly small feature, but it represents where I’d like to take the site.
Smithesis Gaming Hub isn’t just documenting the gaming server. It’s becoming the public-facing side of it.
Where Things Stand
At this point, three game servers have been migrated successfully:
Minecraft Bedrock is running.
Valheim is running.
Core Keeper is running.
They’re centrally managed through Pterodactyl, isolated in Docker containers, and operating behind a firewall that I’m trying to keep as restrictive as practical.
The old installations have been retained for now as rollback copies rather than immediately deleting them.
And Smithesis Gaming Hub can now communicate with the infrastructure and report the actual status of the servers.
That’s a pretty solid foundation.
What’s Next?
There’s still plenty I want to do.
The Server Status page is only at version one. I’d eventually like to explore displaying things like player counts, uptime, server information, and connection instructions, depending on what each game makes available.
I’m also looking at better monitoring for the VPS itself and want to do a complete audit of every listening service against the DigitalOcean firewall.
Then, of course, there are more games.
One of the advantages of having Pterodactyl in place is that experimenting with another dedicated server no longer means building an entirely new management setup from scratch.
And if 8 GB of RAM eventually becomes the limiting factor, there’s always that tempting 16 GB upgrade button waiting for me.
For now, though, the foundation of the Smithesis Gaming Hub is officially up and running.
And I suspect I’m just getting started.