vaultsandbox's comments

Just to let you all know, I am changing the license for all my public repositories to "Apache 2.0".

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.

You are right, maybe I will change it to MIT. What is the worst that can happen?! I will think about it. Thanks

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 the insight!

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.

Thanks for the upvotes so far!

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.

Thanks again,

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.