Realm Panel

Spent today mostly cleaning up how the panel actually looks instead of adding new stuff. Started because the Activity Log page just looked off next to Settings, turned out it was using its own hardcoded hex colors instead of the actual design tokens, so I went through and fixed that. Then I noticed the whole Account section (API keys, SSH keys, permission templates, all of it) had the exact same problem, every page had basically copy pasted the same fake card styling by hand instead of using the real component. Fixed all five pages while I was at it.

Also turned Permission Templates into its own little “Environment” section with a sidebar, mostly so I have somewhere to dump future account wide settings later without having to rebuild the page again.

Got told the permission checkboxes looked bad (fair, they did, gray boxes that didn’t match anything) so rewrote those too, normal casing instead of uppercase everywhere, nicer list layout instead of a grid of boxes. That led me into the confirm dialogs since those had the same gray leftover style, so now every delete confirmation in the app actually matches the rest of the panel instead of being a random gray popup.

Ended the day renaming the URLs, /server became /instance and /account became /user, just cleaner and more consistent with how the rest of the panel is named. Sounds simple but had to make sure old links and bookmarks still work and that the 2FA redirect didn’t break, that part was hardcoded into a Laravel route so easy to miss.

Nothing groundbreaking today, just a lot of small stuff that was bugging me for a while.

✻ Brewed for 6s · 3 shells still running

❯ can u now implement a demo mode on a new branch…. just that the instance resets every hour.

so the node and the panel reset every 1 hour. accounts get reset back. players get admin but they cant ruin everything because panel gets resetted each hour
too, normal casing instead of uppercase everywhere, nicer list layout instead of a grid of boxes. That led me into the confirm dialogs since those had the same gray leftover style, so now every delete confirmation in the app actually matches the rest of the panel instead of being a random gray popup.

Ended the day renaming the URLs, /server became /instance and /account became /user, just cleaner and more consistent with how the rest of the panel is named. Sounds simple but had to make sure old links and bookmarks still work and that the 2FA redirect didn’t break, that part was hardcoded into a Laravel route so easy to miss.

Nothing groundbreaking today, just a lot of small stuff that was bugging me for a while.

Today’s pass on Realm’s server panel was all file manager: ripped out the old tree-sidebar explorer and replaced it with a flat table-row browser, matching the same table-ification sweep the rest of the panel got this week (allocations, databases, backups).

The old file manager was built around FileManagerTreeSidebar (643 lines), a persistent expandable tree on the side, drag-and-drop context (ExplorerDragContext, 261 lines), a separate context-menu component (FileTreeContextMenu, 401 lines), and its own icon/media/upload util files. All of that’s gone now. In its place:

• FileObjectRow — one row per file/folder in a 12-col grid: checkbox + icon + name, size, relative modified time, and a dropdown menu on the right. Right-click still works, it just dispatches a custom event to open the row’s own dropdown instead of mounting a separate tree context-menu component.
• FileDropdownMenu — replaces FileTreeContextMenu. Same actions (rename, copy, archive/extract, download, chmod, delete) but scoped per-row instead of per-tree-node.
• FileManagerBreadcrumbs — simple path breadcrumb bar, replacing the always-visible tree for navigation.
• SelectFileCheckbox — per-row selection, feeding the existing MassActionsBar for bulk delete/move.
• FileManagerContainer — rewritten around the new row list (585 lines touched, net smaller).

Also folded PullFileButton into NewDirectoryButton (renamed file, kept git history via rename-detection) and moved NewDirectoryButton + SftpDetailsButton off the old Dialog/asDialog HOC pattern onto the shared Modal component — same one now used by all the wizard modals across the panel, so file manager dialogs finally look consistent with everything else instead of being the last holdout on the old dialog system.

Net effect: 38 files touched, ~1,150 lines added, ~4,250 removed. Deleted six now-dead util files outright (archivePathUtils, fileExplorerDrag, fileMediaUtils, fileTreeIcons, fileUploadUtils, useFileEditingPresence) along with their routes in routes.ts. No behavior loss — same actions available, just row-based instead of tree-based, and finally matching the modal/table conventions the rest of the panel converged on this week.

Today was a full pass on Realm’s server panel: three feature threads (dashboard, AI, DNS) and a long UI-consistency sweep, capped off by one infra bug that had been silently breaking every dynamic setting in the panel.

Started with the dashboard: replaced the old card-style ServerRow list with a proper ServerTable — sortable by name and game type, with circular progress indicators for resource usage instead of flat bars. Added a public IP lookup service and a ServerInfoCard for the console page showing location, IP, and domain info at a glance.

Then built an AI provider helper: admin picks one provider (Claude, OpenAI, DeepSeek, Gemini, OpenRouter, or a custom OpenAI-compatible endpoint), drops in an API key, done. No multi-provider list to manage — one row in the DB, one config screen under Settings → Advanced. Wrote three concrete provider adapters behind a shared interface (AnthropicProvider talks the native /v1/messages API, GoogleProvider handles Gemini’s role mapping, OpenAiCompatibleProvider covers everything that speaks the OpenAI wire format) so future features can just call AiService::complete() without caring which backend is configured.

Also wired up Cloudflare zone management for subdomains, and gave the Console a log-upload + AI-summarize action.

What I built:

• ServerTable (sortable dashboard) + circular resource indicators, IP lookup + ServerInfoCard
• Single-provider AI helper: model, factory, three adapters, admin UI, wired into Console’s summarize feature
• Cloudflare integration for subdomain zone/record management
• A full step-wizard treatment (sidebar steps, numbered circles, review step) rolled out to every creation modal that used to be a plain form: Change Version, Invite Subuser, Allocation Firewall, Create Subdomain, Create Database, Create Backup
• Converted Allocations, Databases, and Backups from card grids to proper tables (header row, divide-y rows, right-click context menu on allocations instead of a button pile), with the “create new” action moved to plain text + hyperlink below each table instead of a header-bar button
• Restyled the base Modal component itself — dropped the floating X close icon, added consistent border/radius, gave it an optional title/footer API so simple confirm dialogs get the same content-pane-plus-footer-bar layout as the wizards
• Footer now shows the git commit hash + panel version with a fork icon instead of a static copyright line

The interesting part was two bugs that had nothing to do with what I was actively building.

First: Settings → Advanced looked like it saved, but nothing actually persisted — not the AI config, not the allocation port range. Chased it through three layers: my own save logic, then a native HTML required attribute silently blocking the shared form submit, and finally the real one — SettingsServiceProvider, the class responsible for merging DB-stored settings back into Laravel’s config() on every request, was never registered in config/app.php. Every dynamic setting in the entire panel — mail, OAuth, allocations, all of it — had silently never worked, completely unrelated to anything I’d touched that day.

Second: tried to delete a backup in the dev environment and got a 500. Wings was shelling out to a rustic binary that straight-up didn’t exist in the container — the Dockerfile never installed it, so every backup on this dev box had been failing since day one without anyone noticing (because dev servers don’t usually need backups). Added the install step to build/wings/Dockerfile, rebuilt the image, and the failed backup’s leftover DB row still needed a manual delete since its rustic repo was never initialized in the first place.

Neither of those two bugs was flashy, but both had been quietly breaking things for a while — the kind of thing you only find when you actually click through the feature end-to-end instead of trusting that tsc passing means it works.

Today I added deduplicated, encrypted backups to Realm, my game server panel. Previously every backup was a full .tar.gz archive — so backing up a 125MB server ten times ate over a gigabyte of disk, even though almost nothing changed between backups. Painful if you want frequent backups.

Now backups can run through rustic, a Rust backup tool that deduplicates and encrypts data. Ten backups of that same server now cost a fraction of the disk, because identical blocks are stored once and shared across every snapshot. You can turn it on per node, or set it as the panel-wide default — one dropdown in the node settings.

What I built:

• A new rustic backup adapter in Wings (the Go daemon), covering the full lifecycle:
  init the repository, back up on delete. Since rustic hasno Go bindings I shell out to the binary, with a per-repository lock so concurrent
  backups on a shared node repgo through env vars, neverthe process args, and the repo is daemon-owned so game containers never see the path
  or password.
• A backup_adapter column on nodes (plus migration) and the panel-side logic to pick
  the adapter, with a per-nodes a global backupdestination.
• A “Backup adapter” dropdowd hiding the Download buttonfor rustic backups since they live in a shared repo instead of as one downloadable file.
• A production Docker image that bundles the rustic binary, plus docs: a full setup guide and a config reference

The interesting part was tesd TypeScript was happy, but I spun up the whole dev stack and ran it against a real rustic binary and a real game
server anyway — and immediatiler couldn’t see. My deletecommand was missing a flag and crashed every time, my snapshot filter was silently
returning nothing (which broxpected the wrong outputshape, and the Dockerfile pinned a rustic version that didn’t exist. Two of those
would have shipped a featureothing. After fixing them, Iwatched the full create → restore → delete flow run clean through the real
panel-to-daemon path: a snapestored from it, and deleting it cleared the snapshot and reclaimed the space.

Not a flashy feature, but it means you can now keep way more backups for way less disk — and it was a good remindere near “it works.”

Today I added permission templates to Realm, my game server panel. Previously, when you wanted to give someone limited access to your server, you had to manually check off permissions one by one from a list of 60+ options every single time — annoying if you’re managing several servers with a team.

Now you can save a named template (like “Moderator” or “Console Operator”) with a specific set of permissions once, and apply it with a single click whenever you invite or edit a subuser. It shows up right alongside the built-in presets in the invite/edit UI.

What I built:

• A new subuser_permission_templates table, scoped per-account so each user manages their own templates
• A small Laravel API (create/list/update/delete) that validates permissions against the real whitelist so templates can never smuggle in a permission you’re not allowed to grant
• A new “Permission Templates” page under Account settings — pick a name, check the permissions you want, save
• Wired the templates into the existing subuser invite/edit forms so they appear as one-click buttons next to “View only”, “Operator”, “Manager”, etc.

Tested it end-to-end in the browser: created a “Console Operator” template with console+start permissions, confirmed it landed in the database correctly, then applied it while inviting a user and watched it auto-select the right 2 permissions instantly.

Small feature, but it’s the kind of thing that saves real time once you’re managing more than one or two servers with a team.

Spent the last few days deep in the parts of Realm that people actually touch every day, and honestly it’s the stuff I’m most proud of so far.

The file manager got a real overhaul. The old flow felt clunky. too many round trips, slow loads on big directories, and editing a config meant fighting the UI more than the file. I rebuilt how the panel talks to the daemon for file operations so listing, uploading, and editing all feel instant now. Dragging files around, renaming, moving things between folders. it just works the way you’d expect it to, without the lag that used to make me wince.

The plugin manager is the other big one. Instead of telling people to SSH in and drop jars into a folder by hand, you can now browse, install, and manage plugins straight from the panel. It pulls the right versions, handles the install, and keeps track of what’s actually running on the server. Watching a plugin install from a button click the first time it worked end to end was a genuinely good moment.

There’s also been a lot of quieter work under the hood. subdomain provisioning is wired in now so spinning up a server gives you something reachable without manual DNS fiddling, and I cleaned up a pile of reliability issues in the server management layer that were causing weird edge-case failures.

More to come. Still a lot I want to ship.

Devlog — 2026-06-05 — VersionChangerController Fix

An issue was identified in VersionChangerController where the install process attempted to reuse the getDownloadUrl() route method by creating a standard Laravel Request object and passing it directly to the method.

The getDownloadUrl() method is designed as a route action and expects a GetDownloadUrlRequest instance. Because a regular Illuminate\Http\Request was passed instead, Laravel could not satisfy the method’s type requirements, resulting in a TypeError during execution.

To resolve this, the download URL resolution logic was separated from the request handling layer. A new protected helper method, resolveDownloadUrl(?string $type, ?string $version): array, was introduced to contain the shared business logic.

The getDownloadUrl() endpoint now reads the validated request parameters and delegates the actual resolution work to the helper method, preserving route validation behavior. The install() method was updated to call resolveDownloadUrl() directly, eliminating the need to construct or fake request objects internally.

As part of the cleanup, the unused Illuminate\Http\Request import was removed.

Modified file:

• panel/app/Http/Controllers/Api/Client/Servers/VersionChangerController.php

For future development, any controller methods that require the same resolution logic should call the helper directly rather than attempting to reuse route actions with manually constructed Request instances.

Realm is a modern, ground-up reimagining of the Pterodactyl game server management panel. Instead of forking and patching an existing codebase, I’m rebuilding the platform from scratch with a focus on performance, maintainability, and a better developer and user experience. The goal is to provide a cleaner architecture, improved usability, and a foundation that can support future hosting and automation features.