Project Insanity

After what feels like many years now, Project Insanity has finally been released. This has been a massive labor of love from myself and the rest of the Kiai Developers from April 2025 to now, and so I want to describe the journey it's been to get to this point.

Fair warning, this post will be pretty technical, but I'll do my best to keep it interesting.

What is Insanity?

That's a great question! Before we can even answer that, we need to go back. Let's take a look at:

The History of Kiai's Codebase

Contrary to when the Kiai's account was created - which was in 2018 - Kiai's earliest concepts date back to July of 2022, but it really began as a project on January 18, 2023, around the time that Buape Studios also started.

In this version, which we'll refer to as v1, Kiai was a pnpm monorepo with this folder structure:

This worked pretty well, and was a solid base for us. Most of our logic went into the packages, and the apps were what surfaced that logic on Discord and on the web.

Our lib was a custom framework built around discord.js (which you can see a historical version of here), and most of our logic was in database and functions.

Our first big issue we ran into this was build times. We were using turborepo to manage this, and it was EXTREMELY slow to run that iteration of Kiai, sometimes taking up to 60 seconds just to restart after a quick change, making development work a tedious process, to say the least. On top of that, many things in our repo just completely broke on Windows with no clues as to why (mainly things related to pnpm and turborepo). As I'm writing this, one of our Kiai Developers, Codeize, tells me his first gray hairs appeared as a result of trying to get that version of Kiai to run on Windows. Yikes.

One of our other devs had been keeping an eye on a shiny new runtime called Bun, and it had finally released in a stable v1.0 build, so we decided to take the leap and switch to Bun.

The Bun Era

The PR to convert our codebase to Bun was merged on December 23, 2024 and was an extremely logical leap for us. This was a massive overhaul that touched almost every file in the codebase (so massive that I can't even preview the changes on GitHub today without the site OOMing and crashing).

We were able to drop a ton of things that our codebase had relied on to be functional before, including:

• Turborepo
• tsc-alias
• All of the tsconfigs
• rimraf
• vitest
• env-cmd
• dotenv-mono
• tsc-watch
• and most of all, any .js files 🎉

Because Bun can natively run Typescript, we no longer had to deal with any compile or build steps, both in development and even in production.

Additionally, we took this time to combine all the extra packages that we had been making into one package called "internal", because having many packages had made it very confusing for what logic goes where, especially when you have a function that also touches the database but has is used for config, or a file that adjusted the database but was part of the lib, etc., making repo maintenance a much bigger chore than it needed to be.

(We also got mentioned on Bun's X account!)

Our codebase now looked like this:

Migrating to bun made Kiai way easier for our entire development team to use, and paved the way for more substantial updates like v2 of our API, now running on Elysia. There was still one big feature that Kiai was missing looming over our heads, though...

The Dashboard (dun dun dun)

We know, we know, a web dashboard to manage Kiai has been a feature on our list of TODOs literally since day 1, but we've always wanted to hold off on releasing one until we knew it would be a good experience for both us as developers and also any of its users.

Thankfully, now that our codebase is a lot more performant and stable, it should be easy to do now, right?

Wrong.

It turns out, having all these different packages with a ton of extra code that didn't need to run on the dashboard brought both Next.js and React to their knees in pain and agony. Our codebase wasn't designed to be tree-shakable, but trying to use the packages that were designed to be able to be shared between the bot, API, and web was nearly impossible, with compile times in development mode nearing 3 minutes per reload, and build times for our website reaching almost 20 minutes in GitHub Actions.

We knew this wasn't sustainable, and something needed to change.

Introducing Carbon

While all of this had been happening, myself and two other devs on our team had been working on Carbon, which was a Discord framework written from scratch and designed for HTTP bots, and the first beta was released September 2024.

If you don't know what HTTP bots on Discord are, I've written a full post about it here: https://carbon.buape.com/concepts/http-bots, but the TL;DR is that HTTP bots don't maintain an active websocket connection with Discord, but instead Discord sends POST requests to a URL you specify for interaction events (slash commands, buttons, modals, etc).

I'd been wanting a framework like this for a long time, following projects such as Interaction Kit, /create and more, but they would either die out, or felt overly complex or clumsy to use. At Buape Studios, we have an internal bot that handles all our emails, staff management, internal API, and several other tasks. It runs fully on Cloudflare Workers, and was my first time building out a full HTTP-based Discord bot from scratch. I didn't use any frameworks to build it, only the raw Discord API and typings from discord-api-types, and it was a really good experience. The codebase may have been messy, but it worked well and had several QOL features for me to use.

I spent about 5 months (off and on) designing and building the initial version of Carbon, bouncing feedback and ideas off of Codeize and Apteryx, the two other maintainers for Carbon. The process was a lot different than building out our internal bot's methods, but it used the same concepts and ideas. Whenever I added a new feature, extendability and modularity were always a priority, and I wanted to make sure that Carbon was as easy to use as possible, but still very powerful to run extremely large and scalable bots.

So...

Why not Kiai?

If Carbon was built to handle big bots, why not put it to the test with the biggest bot that Buape runs, and one that's already been struggling anyway?

And so, an idea formed, and I continued working on Carbon until I was confident that we could start work on:

Project Insanity

Insanity, at its core, was a port from our existing discord.js + @buape/lib setup to one that was based on Carbon instead, but it quickly grew into more than that. Way more than that.

Since our monorepo was giving us issues, why not combine it into a single app? Carbon was already HTTP-based for the main bot and the staff bot, and a website and API are HTTP-based by their very nature so it made sense to convert our monorepo into a single web app.

*But what about the other events??? Doesn't an XP bot need message events and guild events?? Those aren't provided by Discord over HTTP???????*

Great question, I'm glad you asked! :D

In Discord's HTTP bot setup, you only get the following items over HTTP:

• Interactions
• Linked Role Verifications (Kiai doesn't use these)
• Webhook Events (Limited to Application Authorized/Deauthorized, events for Discord's native subscriptions, and events for Quests and Game integration)

That third one is interesting... if Discord has a way to have HTTP events with the same structure as the Gateway events, why can't we mimic that? So, I added a feature to Carbon called Gateway Forwarders which allows you to run a separate, light-weight process that connects to Discord's Gateway and receive all the events there, and then forward them over HTTP using the exact same signing method that Discord does, allowing you to receive them on Carbon's end via HTTP, no matter what event you need.

This really was the killer feature that Carbon needed to become all we needed for Kiai, and so, the (insanity-fueled) migration began.

Now What?

So we’ve talked about the history of Kiai and what led to Insanity, but how does it actually work now?

Insanity is built around three parts: **the Processor, the Forwarder Manager, and the Cron Manager**.

There is also one important shift, we don't have one hardcoded “main production bot” in the code anymore, a fact that left most of the team scratching their heads when I raised the idea initially.

Each Kiai instance has its own tokens/keys in the database, and the processor handles all of them. The public Kiai is just one of those instances, with higher limits and minor other tweaks.

The Processor

The Processor is the core of everything. It’s an Elysia web server that handles:

• API routes
• Discord HTTP interactions (commands/select menus/buttons/modals)
• forwarded gateway events from the Forwarder Manager
• the Vite website

So instead of splitting logic across multiple services/apps, everything lands here.

The Forwarder Manager

The Forwarder Manager runs alongside the Processor.

It connects to Discord Gateway once per instance, receives gateway events, and forwards them to the Processor over HTTP using the same signing model as Discord interactions.

There’s only one Forwarder Manager process, but it can run many forwarders (one per instance).

The Cron Manager

The Cron Manager handles scheduled jobs and automation.

Only one is needed per database... and since all instances share one database, Kiai's 'production version' only needs one Cron Manager!

So... that’s Project Insanity.

What started as “let’s port off discord.js” turned into a full reset of all my bad decisions when I first made Kiai and everything that followed in the succeeding years.

We went from really long builds, tangled package boundaries, and painful dashboard attempts to a single HTTP-first system that’s faster to develop, easier to run, and way easier to scale.

It took a long time.

It took an intense amount of planning.

It broke a lot of things.

But... it also changed how we (alongside many others) build applications on Discord, and for that, I truly could not be happier.

I would be doing the team a disservice if I did not give a huge shoutout to the Kiai Developers who basically took my work-in-progress rewrite and helped pull it over the finish line. A special thanks also goes to Aleksander for taking over the Kiai Team Lead position right before I started this rewrite, if he were to speak honestly, I don't think he'd say he knew what he had agreed to. Shoutout too to the rest of the Buape Team who work behind the scenes to ensure every aspect of our projects run with as little issue as possible.

Finally, thanks to you. Our users. Thank you so much for sticking with us.

This release really is the strongest foundation we’ve ever had, and we’re just getting started. We truly can't wait for you to see what we're cooking up next!