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 everywhere. Modpacks meant manual installs or community definitions. Worlds stayed tied to the server that created them. The back office lived in WHMCS modules and glue code. The panel lived somewhere else. We could ship, and we did, although each new thing carried the shape of the old stack with it.
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.
Under the hood, Marion is a control plane, a node agent, and a set of workers. The dashboard talks to the Marion API. The API talks to oxide agents running on boxes. Workers handle the longer jobs. Postgres holds product and server state, Stripe handles payments, R2 stores saves, Valkey helps with fast shared state, and Inngest coordinates workflows that cross systems.
The word “built” matters here. We wrote the payments stack around Stripe, credits, purchase flows, subscriptions, plans, products, and promo codes. We wrote the node layer that talks to boxes through oxide. We wrote the recipe system that defines games. We wrote the admin console our team uses for boxes, regions, databases, products, users, subscriptions, audit logs, support, service tokens, orphaned servers, and promo codes.
That gave us a heavier build. It also gave us a product where the account, the invoice, the server, the install, and the support trail all point at the same source of truth.
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.
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, or keep a world after cancellation for the grace window attached to that save. We wrote the first deep dive on this feature already: How Saves work.
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
Marion uses recipes for game definitions. That is our replacement for the egg-shaped part of the old world. A recipe is maintained by us and can expose the settings a game actually needs, instead of treating every title like the same generic process with a different startup command.
That unlocks a broader catalog and a better per-game experience. Game switching, SFTP access, activity logs, and custom settings all belong to the same server model, so the dashboard can show the control a game needs in the place users already are.
Crash help and scheduled tasks
We also started putting AI in the places where it has a real job. Marion includes crash analysis and task assistance backed by a RAG system we trained around game-server operations. The goal is practical: help explain why a server crashed, and help turn routine jobs into scheduled tasks that make sense for the server.
This is early, and it is one of the areas we plan to write about after launch because the product line is thin: helpful explanations on one side, confident nonsense on the other. We care a lot about keeping that line visible.
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.
The architecture, briefly
Marion has one control plane and many nodes. That is the mental model we will use in the posts after this one.
The dashboard is a TanStack Start app. The API is tRPC. The database layer is Postgres through Drizzle. Boxes are the physical machines. Agent nodes are the oxide daemons running on those boxes. Workflows handle operations that cross boundaries, like purchases, installs, saves, and game changes.
That gives future posts a shared vocabulary. When we write about Saves, the important handoff is node to R2. When we write about modpacks, the interesting part is provider search, version selection, install, and scan. When we write about provisioning, the story is purchase state, product state, box capacity, and oxide doing the work on the machine.
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.
If we started again, we would make the internal admin surface earlier and smaller. The customer dashboard gets the attention because users touch it. The back office decides how fast the team can operate, debug, refund, migrate, and support people. We got there, and we could have made that part sharper sooner.
The other rough edge is expectation setting. Marion can do more than the old stack, so users ask it to do more. That is a good problem, and it means our job now is tightening the edges: clearer install states, better failure messages, smarter crash explanations, richer recipes, and more honest progress indicators.
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.
The first deep dive is already live: How Saves work. After that, we want to write about 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