DEV Community: PixelForge

I open-sourced the architecture of my Discord ticket bot. One dependency, zero database, files as modules

PixelForge — Fri, 23 Oct 2026 12:09:03 +0000

Most "support ticket" setups on Discord are a subscription: a hosted bot, a monthly plan, a dashboard you don't control. I wrote a ticket + moderation bot called ARBITER that goes the other way. You run it, you own it, forever. One npm install, one config file, no database.

This post is the architecture story: the five decisions that make a self-hosted bot pleasant to own instead of a liability.

Decision 1: One dependency, on purpose

The bot's entire dependency list is discord.js. That's not a flex about minimalism. It's a support-load decision. Every dependency is a thing a buyer on a $4 VPS can break: native modules fail to compile, lockfiles fight, Node versions drift. A single, pure-JS, actively maintained dependency is the difference between "runs anywhere" and "runs on my machine".

If you're building a tool people will self-host, count your dependencies as a cost, not a capability.

Decision 2: JSON over SQLite

Ticket counters and warning history live in data/*.json, written atomically: write a temp file, rename() over the real one. On any crash, you either have the old file or the new one, never a half-written one.

I'm not going to pretend JSON beats a real database at scale. It doesn't need to. A community server accumulates maybe a few hundred warnings a year. For that volume, the wins are concrete:

data is human-readable, so owners can audit their own files with a text editor
no schema migrations, ever
no native modules to break on weird architectures
backups are literally copying a folder

Choosing the storage engine that matches the actual data volume, not the volume you wish you had, keeps the whole program small enough to reason about.

Decision 3: File-per-command

Every slash command is one small file with the same shape: metadata, permission checks, an execute function. Adding a command is adding a file. The README says exactly that, and means it.

The consistency is the feature. When every file has the same shape, onboarding a new maintainer (or your future self, six months later) is pattern-matching, not archaeology. It also keeps diffs honest in code review: a change to /warn is a change to one file.

Decision 4: Custom interaction IDs

Buttons carry IDs like arbiter:ticket:open instead of raw strings like open. The namespace looks cosmetic. It isn't. Panels get cross-posted, reactions get chain-wired, and on busy servers other bots' components end up on the same messages. The prefix guarantees the bot only ever answers its own buttons, and that a collision surfaces as "ignored", never as "misfire".

Small systems touch. Big systems regret skipping them.

Decision 5: Errors that teach

Every failure message names the likely cause: role hierarchy, missing permission, Discord's 14-day purge window. A bot that says "error" teaches nothing; a bot that says "I can't time out a moderator above me" turns every failure into the owner learning the system. Support volume drops when the error messages do the supporting.

The part that sells it to owners

On ticket close, the bot posts a transcript to the log channel: a self-contained dark-theme HTML file with avatars, timestamps, attachments. Inline CSS, no CDN, renders in any browser. The archive outlives the channel it came from, readable in five years without running anything.

Want the whole bot?

Full source, one dependency, zero database at pixelforgehq.sell.app/product/arbiter-discord-bot. It's $12.99 one-time, and the code LAUNCH20 takes 20% off until Nov 5 (the price rises after the first reviews). config.example.json included: paste your token, run it.

The patterns above are free, though. One dependency you can defend, storage that matches your real data volume, same-shaped files, namespaced IDs, errors that teach. Steal them for your next bot; they'll hold up.

Indie dev, building in public. More admin tools at pixelforgehq.sell.app.

Your server is online. Your website says nothing. The quiet engineering of a live status widget

PixelForge — Fri, 23 Oct 2026 12:01:58 +0000

Here's a pattern I keep meeting: a Minecraft community spends weeks on their server, gets the gameplay tight, the Discord busy, and their website is still a static poster. No signal about whether anyone is playing right now. Visitors can't tell a dead server from a healthy one, so they assume the worst and bounce.

The fix looks trivial ("add a status badge!") and almost everyone implements it wrong. I recently shipped a server-site template called OBSIDIAN, and the status widget ended up being the part I thought about the hardest. This post is the write-up.

Why most status badges lie

The naive implementation polls the server, and when the poll fails it shows 0 players. That's a lie in both directions:

API unreachable? The server might be perfectly up. You're showing "0 players online" on a page whose real message is dead.
Server restarting? "0 players" reads as "dead server" for the 90 seconds it takes to boot back.

Users don't read "0" as a number. They read it as a verdict.

The honest version needs four states, not two: checking, online, offline, and a separate can't reach the status service state that explicitly refuses to guess. That fourth state is the unpopular one: it admits "I don't know" on your own production page. But it's the only configuration that never lies.

Where the query actually lives

Raw Minecraft status isn't HTTP. Java Edition answers a handshake over TCP; Bedrock speaks RakNet, a UDP protocol with its own packet framing. A static page can't speak either from the browser: no raw TCP/UDP in a JS context, by design.

So the honest architecture is a two-hop: the page calls a public status API that performs the protocol handshake server-side and returns JSON. api.mcsrvstat.us is free, needs no key, and speaks both editions. You give it your address, it resolves Java vs Bedrock and returns player counts, version, MOTD.

const res = await fetch(
  "https://api.mcsrvstat.us/2/" + encodeURIComponent(address)
);
const data = await res.json();
// data.online is the only field you trust for state

Everything downstream flows from data.online. Never from a player count, never from a catch block.

The state machine I ended up with

check() -> [checking] -> ok?  -> [online]  show players, version, MOTD
                     -> no?  -> [offline] "Server is offline" (plain, no shame)
           network error    -> [error]    "Can't reach the status service.
                                         The server may still be up."

Two rules make it behave under real traffic:

Never cache "online" optimistically. If the API says offline, show offline now; visitors respect a page that updates honestly.
The error state names the failure honestly. "Could not reach the status service" tells the owner to check the API, not their server. Ambiguity here generates support questions about the wrong problem.

One config file, because owners aren't developers

The widget ships inside a site template, so the whole thing is driven by one file (js/config.js): server name, address, Discord invite, staff list. The owner never edits logic. This matters more than any technical choice in the stack. A config typo is a question I can answer in one line; a broken app.js edit is a debugging session neither of us wants.

The design half of the story: the live numbers get the only warm accent color on the page. One lamp in a dark cave. And when the server is offline, the number doesn't turn red. Red says emergency, and an offline hobby server isn't one. It dims to a quiet neutral. The page stays honest without yelling.

If you want the whole thing

OBSIDIAN is the full template: status widget, one-click copy-IP bar, responsive layout, and a design doc explaining every decision at pixelforgehq.sell.app/product/obsidian-mc-template. It's $9.99, and the code LAUNCH20 takes 20% off until Nov 5 (the price rises after the first reviews). The demo runs the widget live against a real server: obsidianmc.vercel.app

But honestly, the four-state pattern costs nothing to copy into your own page. Poll data.online, never trust player counts, refuse to guess when the chain breaks. Your website stops lying, and your players notice.

Indie dev, building in public. More admin tools at pixelforgehq.sell.app.

I built a live MOTD designer for Minecraft servers and learned the color code system properly

PixelForge — Fri, 23 Oct 2026 11:58:41 +0000

Your server's MOTD has about two seconds to earn a click in the server list. Most of us edit it blind: change motd= in server.properties, restart, open the multiplayer screen, squint, repeat. I did this loop for two years before I finally sat down and learned how the formatting system actually works. Then I built a designer tool around it so nobody has to do the blind loop again.

The 30-second version of Minecraft color codes

Formatting in MOTDs (and chat, and item names) runs on a single control character: § (U+00A7). Whatever follows it is an instruction, not text:

| Codes | Effect || Codes | Effect |
|---|---||---|---|
| §0-§9 | dark colors || §a-§f | bright colors |
| §l | bold || §o | italic |
| §n | underline || §m | strikethrough |
| §k | obfuscated || §r | reset |

Sixteen colors, six formatters, one reset. The palette is fixed by the game: you can't invent new ones in server.properties. What you can do, on 1.16+, is go hex:

§#ff6601Happy Hour §r- join now

§#rrggbb gives you any of 16.7M colors, and it survives the server list. (Bedrock accepts the codes but renders a slightly different palette, so test on your version.)

The three gotchas that cost me an evening

1. The two-line limit is real. server.properties MOTD supports \n for a second line. A third line doesn't exist in the list, and no client-side mod changes that, because the list is rendered client-side.

2. Color carries over. After §6, everything stays orange until you §r or pick a new color. Most "broken" MOTDs I see are missing resets: the second line inherits the first line's formatting, and bold spreads across the dash you thought was plain.

3. Your editor is probably lying to you. The multiplayer list renders in a specific font with its own row layout. A MOTD that looks fine in a generic preview can wrap or clip in the real list. The only preview you can trust is one that reproduces the actual list row.

So I built the tool I wanted to exist

One HTML file. Type on the left, a faithful server-list preview updates live on the right: same row layout, same 16-color palette, obfuscated text actually animating. All codes are one click away in a palette, hex included. When it looks right, copy the codes into server.properties and you're done.

It's called MOTD Studio. It's $7.99, and the code LAUNCH20 takes 20% off until Nov 5 (the price rises after the first reviews). The demo is fully functional: pixelforgehq.sell.app/product/motd-studio

If you'd rather stay vanilla

You honestly don't need my tool. The table above is 90% of the system. Keep three rules and you're fine:

end every colored segment with §r unless you want carry-over
one \n, never two
check it in the real list, not in a plain-text editor

The tool is the difference between editing blind and editing with your eyes open. For something players see before they even join, I think that's worth two minutes.

Indie dev, building in public. More server-admin tools at pixelforgehq.sell.app. Questions about the code system or the preview renderer: comments are open.