There is no point in having AGPL if no one uses it! I am the only contributor right now, so I have time to think. I need to change my message. I will talk less about encryption and production. I will talk more about localhost testing benefits.
1. Isolated inbox per test (parallel-safe by default)
2. Deterministic email assertions, no sleeps
3. One container: SMTP, Web UI, CLI
4. Automatic cleanup with expiring inboxes
5. Secure by default, no config required
I got some upvotes, but almost no feedback, negative or positive.
I get the concern. WeKan is a great example of why licensing boundaries matter.
That is exactly why I licensed the SDKs and the Frontend as MIT. Since the gateway is a standalone service and your application only links to the MIT-licensed SDK, there is no risk of infection. Your code stays MIT, it just talks to an AGPL service over the network.
I wanted the gateway to be protected (AGPL) while making integration (MIT) zero-risk for any project. The gateway should be self-contained and equal for my open-source version and the commercial solution that uses the gateway instead of building on it.
Thanks for that perspective. My goal right now is not money, I just want to build something super helpful. If I can make some cash later, in a way that helps everyone, like with white-label or pro-services, that is great. If not, I am cool with that too.
Building the community is the priority. If I do not solve a real problem for people, then the rest does not matter anyway.
Really appreciate you taking the time to share that 'pro-services' angle. It has given me a lot to think about.
Thanks, someone who has sent billions of emails is exactly who I need to ask.
Regarding 'set and forget': I agree once infra is stable, it stays. But I see the value when the application layer changes—tweaking templates, switching providers, or DNS updates. Do you still feel mocks are enough there?
Regarding PII: You're 100% right on hygiene. The encryption (ML-KEM-768) is just a 'safety net' for the human errors.
Regarding FSL-1.1-MIT: Very interesting suggestion. I will investigate it.
Honest question: At your scale, is this a niche tool or is 'mock and pray' just the industry standard for a reason? Don’t worry about hurting my feelings, I just need to know if I'm solving a real problem.
I would love to dig into the actual developer experience side. One of the main reasons I built this was to kill the sleep(5) or polling loops in CI by using Server-Sent Events (SSE) in the SDKs, so tests react instantly.
For those of you managing large test suites:
- Does your current team rely on mocks/Mailtrap style catch-alls, or do you just trust that the protocol (TLS/DKIM) works?
- How are you currently handling PII in dev/test email logs? (This is why I went with encryption for zero-plaintext storage on the server).
Any feedback would be really useful, since until now I have gotten none and as a solo dev it gets to a point that you do not know if it is a good idea or not.
I do not see the issue here, either. My plan for developing the commercial add-on (a separate backend server) is for this gateway to connect to it using a REST API. So, if they need to use this, they can integrate it with their system the same way. There is nothing stopping anyone from using the open-source gateway and developing a compatible backend, since I will document that part.
For now I am focusing on phase 1, which is to make it rock solid. Only after that will I start doing that part. In this phase, I wanted to listen to the community to add missing features, but apparently it will not be easy :D
Thanks for your reply.
Edit: One crucial detail I should have mentioned: while the gateway engine is AGPLv3, all the native SDKs (Node, Python, Go, Java, .NET), Frontend and CLI are MIT licensed. This ensures a clean legal boundary; your application code only ever interacts with the MIT-licensed client, which talks to the gateway over the network. This should eliminate any 'GPL infection' concerns for standard CI/CD use cases.