HammerTime MCP server

HammerTimeBot

Discord bot written in Node.js (using discord.js) for [HammerTime]

[HammerTime]: https://github.com/WentTheFox/HammerTime

$ sudo npm install -g pm2
$ npm install
$ cp .env.example .env
$ nano .env # Fill in the neccessary environment variables
$ npm build
$ pm2 start pm2.json

Webhook deployment

src/webhook.ts is the bot's only entry point (npm start/pm2.json's HammerTimeBot:Webhook) - it receives interactions over Discord's HTTP Interactions Endpoint rather than a gateway connection, so there's no ShardingManager/gateway mode to speak of. Setting an Interactions Endpoint URL on the application in the Discord Developer Portal is what actually switches interaction delivery over - once set, Discord stops sending INTERACTION_CREATE over the gateway entirely for that application, which is why this needs to be a real HTTP server rather than something that only starts reacting once you're sure: there's no dual-running fallback. Don't set that URL against production until you're confident in the webhook path (test it against a dev subdomain / secondary application first).

One-time production server setup:

/etc/nginx/sites-enabled/, matching how this project's other nginx configs are laid out on that host.

1. deploy/nginx/ → symlink the config into /etc/nginx/sites-available/ and

WEBHOOKPATHSECRET (a long random URL-safe token - see its doc comment in src/env.ts for how to generate one), and optionally WEBHOOKPORT (defaults to 3939) and WEBHOOKHOST (defaults to 127.0.0.1, so only the reverse proxy in front of it can reach the endpoint) in the server's .env.

1. Expand (or issue) a cert covering the webhook subdomain, e.g. via certbot --expand.
2. sudo nginx -t && sudo systemctl reload nginx
3. Set DISCORDPUBLICKEY (the app's Ed25519 public key, from the Developer Portal),

if it is already running, see Clustering).

1. pm2 startOrReload pm2.json --only HammerTimeBot:Webhook to bring up HammerTimeBot:Webhook (or replace its workers

https:/// in the Developer Portal - this is the actual cutover step (see above). The endpoint only serves interactions at that secret path (anything else, including /, 404s) so scanner/health-check noise never reaches signature verification.

1. Once confident locally/in staging, set the Interactions Endpoint URL to

Clustering

Both pm2 apps in pm2.json (the webhook and the API server) run as a cluster of two workers that share their port, so more requests can be handled at once and one worker can be replaced while the other answers. Nothing is kept in memory between interactions, which is why any worker can take any of them.

A deploy runs pm2 reload, which replaces the workers one at a time: a new worker sends ready once it is listening (waitready), and only then does the old one get its SIGINT, which makes it stop taking connections, finish the requests in flight and exit (killtimeout is how long it gets). Nothing is dropped, which a rehearsal under load with the real pm2.json confirmed. The first deploy after switching from a single process deletes and starts the app once, which has a short gap, and says so.

Shortened. The full README is on GitHub.