Today we are launching berrybyte v2: a new brand, a new site, and a new platform behind it.
This is Project Marion. It is the system we spent the last year building to replace the stack berrybyte grew up on. The short version is simple: one account, one platform, built in-house. We replaced a stitched-together setup with a single system we control end to end.
We’re giving you a tour in today’s post, but expect deeper posts coming soon! Saves, modpacks, provisioning, node control, crash analysis, billing, and the pieces we changed after they met real users.
Why rebuild
The first version of berrybyte ran on a familiar hosting stack: WHMCS for billing and Pterodactyl for game-server control. Those tools earned their place. WHMCS knows client accounts, invoices, subscriptions, coupons, and payment flows. Pterodactyl gave hosts a panel, a daemon, and a community around game definitions.
That stack also split the product in two. A customer had a billing account in one place and a server account in another. Our team had billing state, product state, server state, and support state spread across systems that had to agree. Every feature became a sync problem before it became a product problem.
The split showed up in ordinary support work. A customer could have an invoice in WHMCS and a server in Pterodactyl, so checking one issue meant opening both systems and matching the account to the server by hand. Product changes, refunds, server status, and support history all lived in different places. Modpacks meant manual installs or community definitions, and worlds stayed tied to the server that created them.
So we rebuilt it.
What Marion is
Marion is berrybyte’s unified platform. Billing, account management, server control, modpacks, saves, activity, SFTP access, game switching, and the back office all sit behind one login.
The control plane
Marion has one central control plane and an Oxide agent on every box. A server action starts in the dashboard, goes through Marion, and reaches the Oxide agent on the physical machine that runs that server. We took the broad architecture of Pterodactyl’s Wings and rebuilt it from the ground up in Rust as Project Oxide.
Oxide owns the work on the box: Docker containers, ZFS-backed server filesystems, real-time logs and stats, recipes and installs, transfers, backups, file imports, and built-in SFTP. Marion owns the account, billing, server records, and the work that has to cross those boundaries. PlanetScale hosts our managed Postgres database, Cloudflare R2 holds saved worlds, and Inngest coordinates longer jobs such as purchases, installs, saves, and game changes.
Marion runs its dashboard, API, and workers on Kubernetes, with Argo CD handling deployments. Oxide runs on the purpose-built boxes that host game servers. That split lets us ship the control plane like an application while keeping the game workloads close to the machines built to run them.
New boxes come in through OneTouch, our internal bare-metal installer. It turns fresh dedicated hardware into a standardized Debian host with ZFS and Docker. Once the host is ready, Ansible registers the box in Marion, places Oxide’s configuration, and brings the agent online. We will cover that flow properly in a later post.
We also moved project tracking from GitHub Issues to Linear as the work grew beyond a small backlog.
The dashboard started in Next.js. Around six months into the project, Marion had grown enough that next dev was getting slow and heavy, and small changes came with a wait. We made the call to rewrite the dashboard in TanStack Start.
TanStack Start gave us a Vite-powered development loop that felt much quicker, plus TanStack Router for a dashboard with a lot of nested screens and state. The rewrite was a real cost, and it paid off every day after it landed: changing a server page, an admin screen, or a purchase flow felt quick again.
What ships with v2
One-click installs
The create flow is the first place Marion feels different. Pick a game, region, plan, and settings, then Marion carries the purchase and provisioning path through one system. Credits, subscriptions, server records, and node setup move together instead of bouncing between a client area and a separate panel.
AI crash analysis and natural-language automations
AI is one area where we are betting heavily over the next few months. We are putting it inside the work people already do in Marion: crash logs and automation setup.
Crash analysis lives in the crash log viewer. When a server owner asks for it, Marion sends the useful end of the console log plus the exit code, server type, memory, and startup command through OpenRouter. It returns a plain-English summary, a crash category, the probable cause, suggested panel-side fixes, and a confidence level. Crash analysis can also search the web for known mod and plugin issues when the log points in that direction.
The same idea powers automations. The assistant sits inside the Create Automation flow: write what you want in plain English and Marion fills the cron schedule and server actions below it, such as a restart, backup, or console command. You review the draft before it becomes an automation.
We plan to expand on this and build a game-server RAG system around the problems our users actually hit: crash signatures, mod conflicts, configuration errors, recipes, and the ways individual games behave. We want the assistant to have better context than a generic chat window and give answers that fit the server in front of it.
This is early, and we are keeping it user-reviewed while we improve it. We will keep writing about what works, what needs work, and how far we can push it.
Modpacks as a first-class feature
Modpacks used to feel like a chore. Search a provider, download files, upload them, adjust versions, hope the server agrees with the client, then repeat the next time you want to try something else.
In Marion, modpacks are part of the server flow. We search Modrinth, CurseForge, and FTB, then install the selected pack onto a server. Marion can also scan and detect installed mods, which gives us a cleaner path for future repair, migration, and compatibility work.
Server Saves
Saves are Marion’s answer to a question that kept bothering us: why should a world belong to one server forever?
A Save is a world stored in your account. You can snapshot the current world, swap another save onto the server, switch games while keeping the old world, keep a world after cancellation for the grace window attached to that save, or even download to your PC for easy re-uploads later on!
Saves
Snapshot this server's world, swap it onto another save, or switch games. Saves live in your account, restore them here or move them between servers.
Active save
Default
Pick an action to see what it does to your data.
More games, with real settings
Recipes are Marion’s in-house game configurations (our version of Pterodactyl’s Eggs). They tell Marion how to install and run a game, and which settings it can surface in the dashboard.
The bigger job is giving each game the care it needs. We started with Palworld, Hytale, and Minecraft, building proper settings and integrations for each one. The Palworld screen below has controls for server software, world settings, difficulty, players, updates, and access. We will keep bringing that same level of control to each game as the catalog grows.
Free tools on the site
The new site is part of the platform too. The tools section gives players and admins useful utilities outside the dashboard, while the public modpack browser and game catalog make Marion’s data visible before someone creates a server.
What still feels rough
The biggest cost of Marion was scope. Rebuilding the panel, billing, node control, admin operations, and the public site in one long push gave us a much better platform, and it also stretched the migration. We carried validation rules from the older PHP world into the new TypeScript stack, which helped us keep behavior steady while we moved the product.
We spent more time on the customer dashboard first. The admin side came later, which meant routine work such as checking a server, issuing a refund, moving a user through a problem, or finding an orphaned server took longer than it should have. If we did the build again, we would ship a smaller admin surface much earlier.
The other rough part is the last 10 percent of every flow. Creating a server, installing a modpack, changing a game, and recovering from a crash all need clear status updates and useful errors. That is the work in front of us now: better install states, better crash explanations, more complete recipes, and progress screens that say what Marion is doing.
What comes next
This blog exists because Marion changes how we ship. When the whole platform is ours, every product decision has an engineering story inside it.
We want to write about Saves, modpack search, recipes, provisioning, oxide, billing credits, AI crash analysis, and the admin system that replaced our old modules.
berrybyte v2 is the launch. Marion is the platform underneath it. Stay tuned! We have a lot more fun exciting engineering updates coming real soon. :)
Happy gaming,
Imad