The AWS Pizza Bot is a notification inbox for agents
The AWS Pizza Bot is a small self-hosted service that collects alerts from background AI agents and puts them in one place you actually check. It is open source, it runs on infrastructure you already own, and it does one job: give every autonomous agent a single inbox instead of scattering notifications across Slack channels and email aliases.
I started running it on my own VPS instead of paying for a hosted agent inbox dashboard. The hosted tools work fine, but they add a per-seat cost and they keep your notification history on someone else’s servers. My hosting business already runs a few Docker hosts alongside the cPanel/WHM boxes. One more container costs me nothing. A hosted dashboard is another monthly invoice I have to justify.
The problem it solves is the one that kept biting me with background agents. A LangGraph job finishes a batch analysis at 2 AM and writes the result to a log file nobody opens until the next outage. A CrewAI agent watching certificate expiry sends a webhook to a Slack channel with seventeen other projects in it. The important failure drowns in the noise. The Pizza Bot reverses that flow: the agent writes to a queue, the bot collects it, and you get a single list of finished runs, failed jobs, and things that need a human decision.
Where agent notifications go to die
The old way is not really a system at all. Every agent gets its own Slack channel, its own email alias, its own webhook to a Discord server someone set up in 2023 and forgot. I have had agents page me forty times in one night for a transient error, then stay silent when a disk actually filled up. That is not an agent problem. It is a routing problem, and routing problems only get worse as you add more agents.
The open source agent inbox pattern treats notifications like email. Agents are senders, the bot is the mail server, and you are the reader. Nothing lands in a channel you have to remember to watch. It sits in a queue until you open the inbox. The New Stack covered the announcement (opens in new tab) when AWS open-sourced the project, and the pattern is exactly what it sounds like: an inbox for machines.
The name fits the workflow. You order the work, you do not stand over the oven watching it bake. The bot pings you when the pizza is ready, and you only look when there is something worth looking at. That is the whole value. It is not a fancy dashboard, it is a better way to be lazy about the right things.
What does the AWS Pizza Bot actually do?
It collects notifications from background AI agents into a single inbox with a web UI that shows status and history. Each notification has a status, so you can see what is new, what is in progress, and what you already marked done. It is basic in the way that email is basic, and that is the point.
It deduplicates repeated alerts. One failing agent does not page you forty times in a single night. The bot groups the noise into a single entry with a count, which is the feature I care about most after the disk-full incident I mentioned. Alert fatigue is what makes people ignore real failures, and deduplication is the cheapest fix for it.
Messages go through an SQS queue. That matters more than it looks like. Agents keep running even if the bot itself is down for a minute, because the message waits in the queue instead of being dropped at an HTTP endpoint that is not listening. I have lost real alerts that way with other tools, so I route everything through SQS on my own boxes now.
The version I ran handled webhooks from LangGraph and CrewAI without any custom adapter code. Both agents just sent a JSON payload to the bot’s endpoint and the bot figured out the rest. The repo has the details, and the TNS article walks through the architecture if you want the full picture before you clone anything.
Self-hosting the AWS Pizza Bot in practice
What you need is embarrassingly small. A t3.micro on AWS, or any small VPS with Docker, plus a domain if you want HTTPS without a browser warning. I ran it on a 2 GB VPS that was already running two other containers and it did not even notice. The whole thing is a web server, a queue consumer, and a small database.
The setup I followed was shorter than most of my cPanel migrations. Clone the repo, set the PIZZA_BOT_SQS_URL environment variable, and run docker compose up -d. That is the entire install. No Kubernetes, no service mesh, no infrastructure-as-a-code pipeline to maintain. If you already have a box with Docker on it, you can be up before your coffee finishes.
The cost is the part that surprised me. If you run the bot on a small VM instead of Lambda, the queue and the database are the only AWS services in play. SQS and a tiny database run a few dollars a month at this scale. You can skip the Lambda entirely and just run the consumer as a container on the same VPS, which is what I did. The project does not care where the consumer runs.
It falls short in two places right now. There is no mobile push notification, so you still need to open the web UI or set up your own forwarding. And the web UI is basic. It works, it is usable, but it is not a polished product. You should go in expecting a tool, not a SaaS demo.
Where the AWS Pizza Bot is heading
The roadmap items I have seen in the repo are the ones you would guess: threaded replies, a proper mobile view, and better alert filtering. Threading matters for agents that send follow-up updates on the same task, because right now each update lands as a separate entry. Filtering matters once you have more than a handful of agents, because the inbox gets busy fast.
Whether self-hosting keeps making sense depends on how the project matures. If the bot stays as good as it is now, I will keep running it on my own VPS. If a hosted agent inbox appears that offers push notifications and a genuinely better mobile experience, the cost math changes. I expect those hosted options to get better over the next year, and I expect the Pizza Bot to stay useful anyway, because the deduplication and queueing logic are the hard parts and they are already done.
My expectation, and it is an expectation not a promise, is that this project either gets adopted into something bigger or stalls. AWS open-sourcing a tool is not a guarantee of long-term maintenance. The hedge is to keep your webhook layer generic. If your agents send plain JSON to a single endpoint, swapping the Pizza Bot for whatever comes next is an afternoon of work, not a rewrite.
Your next step: run the AWS Pizza Bot on your own box this weekend
Clone the repo, point it at one test agent, and send a single real notification through it before you add anything else. Do not wire up all five of your agents at once. One agent, one notification, and then check that the message actually shows up in the inbox with the right status.
The one config decision that matters is routing alerts through SQS rather than a plain HTTP endpoint. The HTTP path is simpler and it will work for a demo, but it drops messages during deploys and restarts. SQS costs almost nothing and it gives you the guarantee that a notification sent is a notification stored. That guarantee is the whole reason to run this thing.
A concrete command to start: docker compose up -d, then curl the /health endpoint to confirm the container is alive. If you see the health check return OK, your queue URL is valid and the consumer is connected. Then send one test webhook from your noisiest agent and watch it land.
After it works, wire up the agent that produces the most alerts first. That is the one where deduplication will prove itself fastest, and the one that will convince you to move the rest over. Start with the noise, and the quiet agents will follow on their own.