My first slack bot!

Overview
The goal of this project was to build a full-stack Slack bot from scratch using Node.js and the Slack Bolt framework, move it away from fragile local hosting, and deploy it 24/7 to a remote cloud Linux server (Nest).

Phase 1: Core Architecture & Commands
Instead of dealing with incoming HTTP webhooks (which require opening firewall ports or running reverse proxies like Ngrok), I opted for Slack Socket Mode. This creates a secure, bidirectional WebSocket connection directly from my application to Slack.

I built out a solid suite of commands into index.js:

/dsb-test: A quick ping/pong handshake test.

/dsb-help: A clean command menu.

/whoami: A utility that extracts the user’s Slack ID, username, and channel info from the incoming payload.

/dsb-catfact & /dsb-joke: Live integrations that fetch data from external public APIs.

Phase 2: The Deployment Battle (Hurdles Overcome)
Moving the bot from my local machine to the remote Nest server container is where the real engineering happened. I ran into—and solved—several classic DevOps roadblocks:

1. The Terminal Environment Trap
   Early on, I hit errors trying to run Linux commands (pkill, rm) because I had accidentally dropped out of my SSH session and was running them inside my local Windows Command Prompt.

The Fix: Re-established a secure SSH handshake to target the remote Nest environment properly.

1. The Nesting .env Path Bug
   Upon launching the bot on the server, it crashed with a fatal AppInitializationError claiming tokens were missing, even though I had created the .env file. I diagnosed that the repository structure had a duplicate inner folder, isolating the environment variables.

The Fix: Consolidated the directory structure, moving the .env file to the outer root directory where node index.js was executing.

1. Upgrading to Native Network Requests
   My initial API fetches threw module loading errors on the server due to dependency mismatches.

The Fix: Stripped out heavy third-party HTTP clients and upgraded the /joke and /catfact architecture to use Node 24’s native fetch API. This made the code cleaner, lighter, and completely independent of external package bugs.

Phase 3: Going 24/7 with Systemd
To ensure the bot didn’t shut down when I closed my laptop or disconnected from SSH, I configured it as a system-wide background daemon using Linux’s systemd.

Final Status
The bot is officially 100% stable and live. Running systemctl status slackbot.service confirms a beautiful green active (running) status. Every single slash command resolves instantly with zero latency.