It depends. If it's not exposed to a network and doesn't have any awful bugs, than it should be fine.
Usually those mailtrap servers have some exposure to the company intranet or sometimes the internet, which could be problematic. Even test systems might receive sensitive data in the emails, that shouldn't be leaked to an attacker. An unmaintained software might have well known security issues.
Easy REST API access can be a quite useful feature too.
For automated integration testing it's a must. The test can verify in the end if the expected emails were sent out.
I think Mailpit can even be set up as a real SMTP server, handling a (sub) domain. Either as a MX or just via forwarding rules. Sometimes it can be useful to periodically run integration tests on a production system. So your tests could create accounts based on your test domain (random-user-name@testsystem.company.tld), which is deliverable from every email server, and the tests can verify the delivery. An automated script can then periodically delete the *@testsystem.company.tld accounts.
Maybe Zitadel. But be aware their hosted paid plans are very expensive (they have a very original way to count daily active users). It can be self hosted on k8s, but I'm not sure how secure and mature it really is.
Would you mind sharing your thoughts on our pricing? We certainly love to improve this. Its not our intent to have a smoke and mirrors pricing ;-)
On the subject of maturity and security.
Many known enterprises trust Zitadel for their identity needs, especially the self-hosted version, which can be used for free. I think what makes Zitadel a great package in regard of security is that our community actively provides vulnerability disclosures to the project which we track in public.
Let us know what we can improve to show that we take security and stability serious!
- the step up from free to paid is huge, and already needed if you have 4-5 users that log in every day
- your definition of "daily active user" is a bit tricky, as one user who logs in every day is counted as 31 users. The most common metric I know is monthly active users (users that log in at least once a month)
So, if we would increase the free amount and the included in the pro tier it would a little alleviate this pain?
On the definition, we wanted to use DAU because with this we can have on metric to price consumers, business customers and service accounts. To us it was weird to pay for a MAU when a consumer only logs in once a month. Coming back to my reply above... would a "bigger" number of included DAU solve this?
I think it's your business decision how much quota you want to give away for free and how much you charge for each DAU.
But the current free plan has a few issues (I would even call them traps):
It has a monthly DAU and API request limit. If this limit is exhausted Zitadel will essentially shut down the service until the end of the month, unless you switch to the Pro plan, or just accept getting locked out until the end of the month.
The DAU restriction can be safeguarded by only onboarding 3 users, then the DAU quota will never be exhausted.
The API limit is even more tricky, if your users heavily use the console or log in very often it is out of your control.
This makes the Zitadel free plan practically just a demo version (1 admin user, 1 test account, 1 service account). In my case I nearly hit the quota already after 5 days of developing a product, just me, developing alone. I ended up switching to auth0, because I was not very invested in Zitadel yet.
I know it’s our decision, but I wanted to get a sense of how our pricing looks to people from a less biased perspective. Thanks for taking the time to share your thoughts!
I’ll take your points for a spin internally. We’ve already had some ideas that address some of your concerns, especially around the quotas.
I set up Zitadel Cloud for the services at home, just for a few basic services (professionally I'm mostly using AAD and Keycloak).
Already with one user per family member we are coming dangerously close to the quotas, it's my fault, I didn't take the time to check the terms and conditions. But I honestly did not expect the free plan to be that restrictive. I just stopped at "100 users" and thought: "well, that should be enough". That's why I'm warning everyone about this fact.
Not the parent, but DAUs make a lot of sense when you have lots of external collaborators than seldomly login. That way you don't pay a full month license for somebody that logged in twice or once in that period, I rather log them in manually :-)
About the pricing, I haven't made the calculations in your product, but in other products I sometimes miss a middle ground between free and pro like a "hobby" or "mini" tier. maybe I have a small product, an SMB, or a personal thing thing that needs a service, and I don't want to be a "freeloader" on the free plan, but the pro is too much.
There are services I've used that I know I'll stop using once I grow out of the free plan, because it's so expensive.
I guess this would be a good start, it would allow instances for smaller companies.
Another thing would be to mix daily active users and monthly active users. For example in the ratio 1:10 (100 DAUs or 10 MAUs). Just cap the DAU counter for a user at 10 logins per month.
It's really hard to predict how often users are going to log in. So if you have a company with 50 people, you know 50 MAUs are enough. But will 500 DAUs be enough? You just don't know that in advance. The DAUs can also grow a lot even if MAUs stay the same, if your product becomes better and is used more often in the company. Really hard to tell the customer at a later stage that Zitadel is now more expensive, because people log in more often. The DAU/API limit is also an incentive to cache authentication/2FA longer and compromise on security.
Maybe remove a few enterprise features for the cheaper plans like SAML or restrict branding. But please keep passwordless/2FA, for me those features were the main reason to try Zitadel, that's one of the features where Zitadel shines over auth0.
Did you consider the aspect, that in many countries the date would change during the day?
So in UTC-5 the day would end at 19:00 solar time. „Lets meet up for dinner on Thursday“ would become completely ambiguous, depending on the time. If you move dinner on Tuesday at 18:30 (23:30 UTC) to an hour later, it would be on Friday at 0:30 UTC.
Common types calendars would become quite useless, they would need to be different for each timezone. It doesn’t make sense to split the events of one solar day into multiple day-columns in a calendar.
The vast majority of people plan their life around solar days, they usually don’t have appointments planned that span over two calendar days.
It is much harder to do. We all speak the same 24 hour clock and it is not a culturally significant thing. It would be nice if everyone could understand everyone but there is something to be lost by losing languages. There is absolutely nothing to be lost by doing away with timezones.
Of course there's something lost. If I see my colleague's local time will be 9:00PM, I know not to schedule a meeting then. It's a method for translating familiar associations of hours across space.
Also, and more importantly, "it's 5:00 somewhere!" would cease to be true.
And yes, it's really bad. No idea how someone could think this could replace a human.
reply