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.
Having sent billions of emails between multiple startups:
RE setup and testing: Trust (as is most devops one-time setups). Once the initial email setup is complete, you typically aren’t paying with it much. The black swan outages aren’t really an active concern.
RE PII: email is non-secure and shouldn’t have sensitive data in production either. Also, dev/test shouldn’t have PII in regulated industries as a good hygiene practice (I’ve worked in healthcare, finance, and national security contexts).
Re licensing: I appreciate your openness and clarity on the licensing of the gateway engine as AGPL vs MIT for the rest. There’s a more modern licensing approach with FSL-1.1-MIT. It may be a better fit for customers (ie clear licensing terms when using a paid license and less concerns if the business goes defunct or pivots) and for your business plans.
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.
For a bit more context, most email infrastructures I’ve worked with are for transactional and marketing DTC and B2B companies. I would read my response in this context.
Re one-time setups and one-time changes: I think this will answer both questions and the implied PMF question as well. For internal FTE staff, this will be handle as a one off exception consistently (it’s really no one’s full-time job or responsibility). You may wish to speak with teams that offer professional services / SaaS including self-hosted where this infrastructure would be helpful. Their jobs are made easier with additional predicable / dependable infrastructure software (ie chat with (a) Twilio’s messaging team which remains the SendGrid acquisition, (b) related Red Hat / IBM) vs more work for an individual who is just doing this one-off. You may wish to consider a revenue share and/or white-labeling as they co-install the infrastructure for your business.
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.
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.
> especially on whether AGPLv3 would be a blocker for something you'd self-host in dev
AGPL3 shouldn't be a blocker for use with this sort of tool unless:
▪ someone is very paranoid about GPL infection (that is to say that they, or their bosses, have been taken in by some of the fear-mongering over the years)
▪ or they are intending to make the feature available as part of the their product/service (if it is a mail related/adjacent tool and they want to use this as a built-in self-test module) rather than just using it internally, in which case they might be subject to the full terms of the licence due to effectively directly linking the code.
To alay the concerns of that first group, perhaps include in you documentation a paragraph explaining that simply using it in a dev environment, with no redistribution, does not constitute linking.
If someone tells you "no one will use it commercially if you use GPL"¹, you always have the option (assuming all the code is yoursor contributors have signed over their relevant rights) of dual licencing GPL and commercial.
--------
[1] this usually means "I want to sell this with my service but don't want to pay or otherwise give back, please use a more permissive license so I can do that"
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.
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,
Having sent billions of emails between multiple startups:
RE setup and testing: Trust (as is most devops one-time setups). Once the initial email setup is complete, you typically aren’t paying with it much. The black swan outages aren’t really an active concern.
RE PII: email is non-secure and shouldn’t have sensitive data in production either. Also, dev/test shouldn’t have PII in regulated industries as a good hygiene practice (I’ve worked in healthcare, finance, and national security contexts).
Re licensing: I appreciate your openness and clarity on the licensing of the gateway engine as AGPL vs MIT for the rest. There’s a more modern licensing approach with FSL-1.1-MIT. It may be a better fit for customers (ie clear licensing terms when using a paid license and less concerns if the business goes defunct or pivots) and for your business plans.
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.
For a bit more context, most email infrastructures I’ve worked with are for transactional and marketing DTC and B2B companies. I would read my response in this context.
Re one-time setups and one-time changes: I think this will answer both questions and the implied PMF question as well. For internal FTE staff, this will be handle as a one off exception consistently (it’s really no one’s full-time job or responsibility). You may wish to speak with teams that offer professional services / SaaS including self-hosted where this infrastructure would be helpful. Their jobs are made easier with additional predicable / dependable infrastructure software (ie chat with (a) Twilio’s messaging team which remains the SendGrid acquisition, (b) related Red Hat / IBM) vs more work for an individual who is just doing this one-off. You may wish to consider a revenue share and/or white-labeling as they co-install the infrastructure for your business.
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.
I can not include anything GPL or AGPLv3 with my MIT license WeKan Open Source kanban, where I have added and removed over 4 million lines of code.
I have discontinued version of WeKan where was GPLv2 licensed Gantt Chart component, because it infected WeKan license to be GPLv2.
There has been some other kanban, that first changed from MIT to GPL, and then from GPL to some source-available license or propietary.
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!
> especially on whether AGPLv3 would be a blocker for something you'd self-host in dev
AGPL3 shouldn't be a blocker for use with this sort of tool unless:
▪ someone is very paranoid about GPL infection (that is to say that they, or their bosses, have been taken in by some of the fear-mongering over the years)
▪ or they are intending to make the feature available as part of the their product/service (if it is a mail related/adjacent tool and they want to use this as a built-in self-test module) rather than just using it internally, in which case they might be subject to the full terms of the licence due to effectively directly linking the code.
To alay the concerns of that first group, perhaps include in you documentation a paragraph explaining that simply using it in a dev environment, with no redistribution, does not constitute linking.
If someone tells you "no one will use it commercially if you use GPL"¹, you always have the option (assuming all the code is yoursor contributors have signed over their relevant rights) of dual licencing GPL and commercial.
--------
[1] this usually means "I want to sell this with my service but don't want to pay or otherwise give back, please use a more permissive license so I can do that"
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.