Cloudron Forum

• Title: Supertokens on Cloudron - Open Source User Authentication

• Main Page: https://supertokens.com
• Git: https://github.com/supertokens/supertokens-core
• Licence: Apache 2.0, but excludes ee/ sub-directory (enterprise edition)
• Docker: Yes
• Demo:

• Summary: Supertokens provides a backend for user authentication, to permit your users to use any authentication mechanism for an account (passkeys, SSO, magic links, etc.).

• Notes: It seems like a very nice alternative to clerk, permitting freedom on the front-end by providing an API, but taking away the hassle of the different authentication methods for user management.

• Alternative to / Libhunt link: https://clerk.com

• Title: keygen on Cloudron - software & licensing API

• Main Page: https://keygen.sh
• Git: https://github.com/keygen-sh/keygen-api
• Licence: FCL-1.0-ALv2
• Docker: Yes
• Demo: https://app.keygen.sh

• Summary: Keygen enables commercial/proprietary software products with the implementation of licensing, by providing license key generation, license key validation (offline), and more.

• Notes: This may be admittedly a bit of a nice app, but seemingly attractive for anyone software product business that's not SaSS but providing software distributions of any kind.

• Alternative to / Libhunt link: Haven't found any open source alternative.

Same here, with the latest update it works now. Thank you folks for updating the cloudron app!! (You don’t realize how dependent you’ve become on a feature until it is gone

I've noticed that the docker image for cal.com is rather big:

docker image ls
REPOSITORY                                TAG                         IMAGE ID       CREATED         SIZE
cloudron/com.cal.cloudronapp              202410300519450000          5e16a79c3c9a   2 weeks ago     15GB

The very latest seems even bigger with 22.4GB.

Compared to other apps this seems big, and it's almost double of what the upstream docker image is:

calcom/cal.com                                     latest      307203a992f4   9 hours ago   7.68GB

I understand that they're not derived from each other. A quick glance at the upstream docker file suggests that they're using multiple stages.

To those who are also running this app: What's the size of your image?

@robi I measured again and it look 30-50 seconds. With the default pool_timeout of 50 that should suffice, yet when I tried multiple times with the defaults it never succeeded. It's possible that it was always close.

I have tried to reach out to their IT support, because at first I thought it's a bug on their end. Their response was that they don't see anything wrong on their end. It's also a prospective business customer/partner, so my interest in the ability to exchange emails with them outweighs theirs for sure at this stage. Consequently I'd rather apply generous timeouts than ask their IT to make changes

@Benoit we ran into exactly the same issue with our installation. I couldn’t find anything yet, but suspect that it’s upgrade related (happens not in new installations). Hoping the next upstream MM version fixes it.