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

@nebulon thank you ! I'm going to update and test rn Edit : I can confirm you solved the CPU 100% issue : [image: 1743791032859-02b19f87-91d2-449a-82c7-326f7f806ba4-image.png] We can clearly see the result after the update

the calcom package is not using apache or nginx. Cloudron has an nginx reverse proxy for all apps, but that is outside of the app package itself. Calcom uses a nodejs based process to serve up api and assets. You may be able to increase verbosity of that by setting some variables at /app/data/env. Check https://github.com/calcom/cal.com?tab=readme-ov-file#development-tip for the loglevels and env variables.

As far as I understand Cal.com's support, an external service is unfortunately necessary for the functionality of workflows I want. I will therefore try to solve it myself via the API and webhooks. This thread is therefore no longer relevant. Thanks for the feedback.

This is a calcom upstream issue. The double quotes look strange but are required. The corresponding github issue is https://github.com/calcom/cal.com/issues/12201

@bmann Not sure if this answers your question, but our process is this: Initially, I enabled "teams" and disabled "signups" at /settings/admin/flags, then configured some teams and Google Login. When we have new team members join, I invite them to the appropriate team (e.g. /settings/teams/2/members > Add.) When they accept the invite, I believe this creates the user account automatically. The issue that we ran into is that there was (and still is) no way to subsequently delete that user account from the admin GUI.

@Jean-Henri it was a bug in the Cloudron integration. This is fixed now. We reverted the broken packages.

Apparently we were a bit overreaching, the latest app package broke some public page feature, we are fixing it up but had to revoke that last package version