Why we made Krispy open source
Krispy is open source so you can read the code before you trust it with customer conversations. Self-host in 3 commands for $0, or use Krispy Cloud.
Buttr, auditing the codebase before approving the deploy. thorough little guy.
🥐 Buttr: you're about to put a chat widget on your site. it reads customer messages. "trust us" is not a data model. luckily, you don't have to.
Krispy is open source because a live chat widget handles customer conversations — sometimes sensitive ones — and "trust us" doesn't cut it. When the code is public, you can read the implementation, self-host on Cloudflare's free tier for near-zero cost, and know exactly what happens to your visitors' data.
Why does open source matter for a live chat widget specifically?
Most live chat tools are black boxes with a monthly invoice. You paste a <script> tag, messages start flowing, and you have no idea what's happening on the server handling them. You're trusting a vendor's privacy policy, their infrastructure uptime, and their pricing decisions — indefinitely.
When a customer asks "does this tool store my visitors' messages?" you have two answers: "yes, on a server we control" (honest), or "I'm not sure" (also honest, for a closed tool). Open source gives you a third: run it yourself and nothing leaves your Cloudflare account.
We wrote about this in more depth in why self-hosted chat gives you ownership that rented SaaS can't. Short version: renting a channel isn't owning a relationship.
How does the Telegram handoff actually work?
Here's something concrete. Krispy's human handoff — the part where a conversation escalates from the AI to a real person on Telegram — is powered by Cloudflare Durable Objects. Each active conversation is a single DO instance. There's no polling, no queued background job that might drop a message. The WebSocket connection to your Telegram and the widget on your visitor's screen are both held by the same stateful process.
You don't have to believe us. You can read it — and we wrote up the full design in how we built live human handoff with Durable Objects.
Trust by inspection: the answer is a file path, not a promise.
What does self-hosting Krispy actually cost?
There's a practical reason we went open source, and we're not going to pretend there isn't.
Intercom's AI assistant features start at $29/seat/month on their cheapest plan; teams with shared inboxes typically pay $90–$400/month depending on seat count (Intercom pricing). Crisp charges $95+/month at the plan level that includes an AI assistant and team inboxes (Crisp pricing). Tawk.to is free but the model is "we show ads to your visitors, or you pay to remove them."
Krispy's self-hosted path:
npm create cloudflare@latest -- my-krispy --template github:krispyai/krispy
cd my-krispy
wrangler deploy
Cloudflare Workers AI is included in the free tier for reasonable volumes — 100,000 Worker requests per day at no cost (Cloudflare Workers pricing). Your Telegram bot is free. Durable Objects bill by request and storage at fractions of a cent per active conversation. For most small teams, the bill rounds to $0.
🥐 Buttr: intercom's great at being intercom. i'm just free. no shade — just math.
We also have Krispy Cloud — $19/month flat, no per-seat tax — for teams that want the product without managing infrastructure. But the self-hosted path is real, not a footnote.
How does building in public keep the codebase honest?
There's a less obvious reason we chose open source: it's harder to cut corners when the corners are visible.
When you ship a closed product, bad decisions are private. You can skip input sanitization, silently log things you shouldn't, quietly tighten rate limits and hope nobody notices. Open source doesn't guarantee you won't make those mistakes — but it means someone can catch them and file an issue. Or a PR.
We've had contributors catch a session leak we missed. A community member spotted that we weren't stripping query parameters from a logging call that could have leaked token values. These things get fixed faster when people can read the diff.
How Krispy compares to other open-source live chat tools applies the same standard: show the tradeoffs, name the constraints, don't pretend the category is simpler than it is.
What did we give up by going open source?
Open source isn't free (for us). Competitors can read the code. Anyone can deploy it without telling us. A large company could white-label it and we'd have no idea.
We're fine with that. The MIT license means what it says. If you're self-hosting and something breaks, file an issue. If you fix it yourself, open a PR. That's the whole social contract.
🥐 Buttr: read the code. then decide. that's genuinely the whole pitch.
Try it
Star the repo on GitHub and follow the five-minute deploy guide. If you'd rather skip the infra: Krispy Cloud is $19/month flat, 14-day free trial, same code — we handle the Workers. Either way, the code is there. Read it before you decide.
FAQ
Why does open source matter for a chat widget specifically?
A chat widget handles what your visitors type — support questions, order details, sometimes payment context. Closed-source tools ask you to trust their data handling on faith. Open source lets you read the implementation and, if you want, run the whole thing on your own Cloudflare account so no conversation data ever leaves it. For anything touching customer conversations, that's not a nice-to-have.
Can I really self-host Krispy for free?
For most small teams, yes. Cloudflare Workers and Workers AI include generous free tiers — 100,000 requests per day at no cost. Durable Objects, which power the live Telegram handoff, bill by request and storage at very low rates. A team handling a few hundred conversations a month should see a near-zero bill. High-volume deployments will incur real Cloudflare costs — check their pricing page for specifics.
What does "build in public" actually give users?
Commit history, open issues, and public diffs. You can see what gets fixed and what gets deferred — and you can contribute. That's a form of accountability a private roadmap doc can't replicate. It also means the project improves in the directions real users care about, not just the ones the team guesses at.
Is the open-source version missing features compared to Krispy Cloud?
No. Krispy Cloud runs the same code as the public repo, deployed on our Cloudflare account. The difference is operational: we manage infrastructure, updates, and uptime. You trade that control for convenience at $19/month flat. There's no feature gating between the two.
If anyone can fork Krispy, what's your business model?
Krispy Cloud — the hosted version — is how we keep the lights on. Some teams want the product without running Cloudflare infrastructure, and we charge a flat $19/month for that. It's the same model as Plausible, Gitea, and Mattermost. The code stays open either way.