Hard to know exactly what's going on.

I would try creating another tenant and seeing if the same SMTP settings fail. Then I'd try standing up a version with the very latest FusionAuth version and seeing if you see the same behavior.

Also, do you have the same tenant smtp settings? That is under the "advanced" tab, then "smtp settings".

@dan

Thanks for the reply. It works

How much memory are you giving to the java process?

You can also switch to the database search engine and see if removing ES resolves the issue. At that point it might be a resource issue.

https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines/ has instructions on how to change these.

For anyone interested I got this running by one installing docker-compose from the actual docker tutorial on how to do it, and then giving docker permission to run commands as root. There is a tutorial on how to do it on. On top of those I moved it to a server with 2gb of ram, as I noticed a few out of memory errors when it was trying to start up.
https://docs.docker.com/engine/install/linux-postinstall/

Hi @daniel-barrett ,

Great question! The short answer is that the TOTP/Google authenticator/authy 2FA will continue to be included in the community edition.

As we're revamping the SMS functionality entirely and making it a whole lot better, when this MFA project is released, using SMS 2FA will require a paid edition license.

Here's a lot more detail.

Please let me know if you have any questions or comments.

Hi @daniel-barrett ,

Sorry for the hassle!

All the hosted login pages that FusionAuth makes available are documented in the themes section.

That Integration Points doc is pretty new, but if you haven't seen it is worth a read. Would love any feedback on that.

You could maintain two user accounts, dan with MFA turned on and dan-api-access with MFA turned off and application tokens. You could then use webhooks to keep their permissions in sync.

Sorry, no kub expert here. I'm not sure how to teardown just the database, but I assume you could write a script to connect to the backing database and drop the tables/schema, etc. That might be quicker than dropping the entire cluster.

If you figure out a better way, please share!