Inbix
Cloudflare-native Email Infrastructure for Developers
58 followers
Cloudflare-native Email Infrastructure for Developers
58 followers
Inbix is an open-source, Cloudflare-native email infrastructure platform built for developers. Create disposable inboxes, receive emails in real time, automate workflows with webhooks, and integrate seamlessly using REST APIs, SDKs, and MCP. Designed for testing, CI/CD, AI agents, and modern developer workflows without relying on proprietary infrastructure.
Inbix
@sandiandrian Thanks for building this. I've always wished something like this exist
Inbix
@0xhecker Sure, hope it will help you and the community :)
The disposable-inbox-over-API-plus-webhooks combo is exactly what is missing when you are testing signup/verification flows in CI and do not want a real mailbox in the loop. Since it is Cloudflare-native and open source, can I self-host the whole thing on my own Cloudflare account (my Workers, my domain) so inbound email never touches Inbix-run infra, or does delivery still route through your tenancy first?
Inbix
@hazy0
Great question and yes! 😊
One of the reasons I decided to make Inbix open source was to give developers full control over their email infrastructure.
If you self-host Inbix, everything runs in your own Cloudflare account: Workers, Email Routing, D1, R2, KV, and your own domain. Incoming emails are processed entirely within your Cloudflare tenancy and never pass through Inbix-managed infrastructure.
Inbix Cloud is simply the managed option for people who don't want to operate the infrastructure themselves. The underlying platform is the same.
I think having both options is important: self-host when you need full control, or use the hosted service when you just want to get started quickly.
That's the answer I was hoping for — own tenancy end to end is what makes it usable for CI. Follow-up on the self-hosted path: does it manage its own retention, i.e. is there an inbox/message TTL that purges D1 rows and R2 objects on a schedule, or do I need to run my own cleanup job before a few thousand throwaway CI inboxes a week quietly turn into a storage bill?
Inbix
@hazy0 I've set the expiration on the .env like 15 mins for inbox. and you can configure it later as you want
Thanks, 15-min configurable inbox expiry covers the logical TTL. The bit I want to pin down: when that timer fires, does it actually delete the D1 rows and R2 objects behind the inbox (reclaim storage), or just mark the inbox expired while the message payloads linger until I run my own cleanup? Matters when a CI suite spins up a few thousand throwaway inboxes a week.