Derp

2021.04.15

The What

I want to make a chatbot for fun and profit. But also to do reminders, tell me the weather, remind me of calendar items... personal-assistent-type stuff.

Discord demands that its chatbots maintain a WebSocket gateway with an always-on connection back to their servers to receive realtime events (reactions, mentions, and the like). No serverless platform I have available to me provides for such usage. Every serverless provider I can find expects a shorter-lived request/response model well suited for HTTP traffic or API calls. That means I need to run a server for the WebSocket gateway.

Because it's the future I want the main "body" of the chatbot to run in a Docker container. Any other piece of functionality for the chatbot can run on a serverless platform. Thus, I really only need to host a single Docker container in a production environment.

Finding a way to easily and reliably run a single Docker container in a production environment is a funny kind of problem to my programmer brain used to dozens of microservices that all run basically independently.

Kubernetes is probably overkill. It's a single service with no available HTTP endpoint that should restart if it crashes. Most k8s solutions require at least two nodes, which is immediately too expensive given the resources I actually need.
Run it in my home network. I could probably put the gateway on a cheapo computer somewhere in my house and script updates that way. So far I've been able to not have my network accept incoming requests; if I use something like GitHub Actions as CI that would have to change. I could also poll GitHub to see if the bot's repo changed, but that's yucko city (ask me about being #1 at GitHub sometime).
Run a tiny, single production server. This seems the likeliest route. Keeps running if my home network goes down, reachable from wherever, easy to manage ops-wise.

Sounds like I'm running a $5/month server somewhere and pushing new Docker images to it when the main gateway repo builds successfully.