Hello @tom.westphal Great to read that it worked out. Just keep Cloudron, Ubuntu (next EOL) and the apps updated and it should run smoothly.

@sparkwise According to their blog post, back in April, the maintainers are "former Cal.com interns". Anyhow, it's been ~15 days since any commit was pushed, and all the commits since their announcement were almost exclusively changes to remove code from their "now" closed source version. Not to be pessimistic, but I wouldn't expect a new release any time soon, if ever.

Hello @mejoaocordeiro The URL states cloudron:1337 that does not look correct. Also the output of cloudron-support --troubleshoot is still missing see https://docs.cloudron.io/troubleshooting#troubleshooting-tool Please send that.

@Mathieu https://docs.cloudron.io/packaging/ is a good place to get started

The fix for this has now been released in Cal.com 6.2.0

@chopsol it seems their license URL has changed. Can you check this in your /app/data/env ? GET_LICENSE_KEY_URL="https://goblin.cal.com/v1/license" CALCOM_PRIVATE_API_ROUTE="https://goblin.cal.com"

Hi there, Sorry to dig this up but. Is it really disabled on the selfhosted app ? I managed to activate "workflows" in the settings page (/settings/admin/flags) [image: 1764161572348-e626f64d-c6a3-4ed4-95ad-3c7cd9452561-image-resized.png] I discover workflows don't run on themself and needed to be triggered by external cronjob, which I did via Cloudron : * * * * * curl -fsS -X POST -H "authorization: $CRON_API_KEY" http://localhost:3000/api/cron/workflows/scheduleEmailReminders > /dev/null 2>&1 I also discover it needed some env variables to work : ENABLE_TASK_SYSTEM=true CRON_ENABLE_APP_SYNC=true CRON_API_KEY=*** When calling this URL from the instance itself, I even got a status:200 code with a JSON response {"message":"No Emails to schedule"} And this is my problem now : it says no emails to schedule while there is actual emails scheduled (from workflow). It is visible in the postgres tables "WorkflowReminder" and "Task". I even see in the log that the task is set up for scheduling. But at the end, the workflow is never executed and I'm out of solutions. What a complicated journey just to get this feature working, even though it’s advertised as available in the free version (so I assumed it would work in self-hosted as well). Or am I missing something? Could you clarify this for me? Thanks.

Also from here - Thank you

thanks @nebulon

The problem has been resolved thanks to the information provided there. Best regards, Lasse

@girish Thanks for this - This is a great workaround and fit the bill perfectly for us.

You are right. You are forced to set up 2FA, then you log out and back in again, and only then the admin section appears under settings and you can enable/disable the apps. Wow, I am impressed by who made that design decision. @girish Maybe this could be added to the cloudron docs for this app as this is kind of important for using this, while it is far from obvious?

Since the Cloudron-Team can't force changes upstream, I've made this into a normal topic. I added the feature-request tag tho. Maybe when @mirotalk-57bab571 him - themselves pushed this issue, they might be more inclined to do so. As for now, the feature request would be: Can Cloudron change the /app/code/packages/app-store/mirotalk/config.json to allow all domains for mirotalk or make the file editable by some means?

I know and understand @nebulon's explanation on this, but I'd though I would mention that if there is ever a chance for this to happen, that would be much appreciated. I guess there is also hoping that Cal.com handles this differently in the future, making this also compatible with Cloudron's package.

See https://github.com/calcom/cal.com/issues/11582 and https://github.com/calcom/cal.com/issues/9699 . Not sure what the fix is though .

Nice one! Thanks for providing feedback. I'm glad I could help.

See also https://forum.cloudron.io/topic/13711/added-stripe-keys-to-.env-still-not-able-to-add-stripe-app