Cloudron Forum

I just wanted to share what a great addition the Outline app has been to the Cloudron catalog. It’s been a fantastic tool, and the Cloudron packaging has been seamless. Thanks for making this available!

While these two relevant issues (https://github.com/calcom/cal.com/issues/3026 and https://github.com/calcom/cal.com/issues/6780) remain open, it looks like a PR was merged and released in 2.9.5 a few weeks ago that addressed both of these: "feat: Make database optional when building" (https://github.com/calcom/cal.com/pull/8561)

Wanted to share a working solution, lightly adapted for Cloudron from Github issue comment referenced above:

1. Enter Recovery Mode
2. On the app's terminal: sqlite3 /app/code/data/kuma.db "DELETE FROM setting WHERE key = 'migrateAggregateTableState';"
3. Exit Recovery Mode

I saw a mention of BotPress integrated with Chatwoot in their documentation on AgentBots at https://www.chatwoot.com/docs/product/others/agent-bots/#implementation-examples

I haven’t tried this out, so it’s not an endorsement, but I did want to highlight that in addition to its standalone capabilities, BotPress may integrate with and complement Chatwoot.

@nebulon We recently set up Chatwoot, and it's been great so far!

The work to support the IMAP Email Channel that was discussed in this thread has since been finished and released. I was able to configure an Email Channel with IMAP and SMTP details using a Google account, so presumably this could work with Cloudron email now, too. This allowed me to set up a dedicated email address for Chatwoot-based support.

The one piece that I wasn't able to get configured fully was the "conversation continuity" discussed above. I'm still seeing the "Forward to Email" address provided by Chatwoot as xxxxxxxx@false. It's not clear to me if some configuration with Cloudron Email (for the inbound email service) might address this, but it seems worth revisiting now that the IMAP integration is in place.

I wasn't ultimately able to get this to work, but uninstalling and reinstalling the Cal.com app from the Cloudron App Store gave me access to the admin onboarding flow, which did let me set up Google Calendar correctly.

Sorry. bash wasn't supposed to be there. Failed attempt to format the markdown code block.

@nebulon Thank you! Great to hear. Happy to say that our custom skin loads properly.

@girish said in Using the n8n CLI:

I put this in the docs as well - https://docs.cloudron.io/apps/n8n/#cli

In the docs, it could be helpful to linking "n8n CLI" to the documentation link: https://docs.n8n.io/reference/cli-commands/

Wanted to note that the optionalSso change here allowed me to fix my Google Login issue, too! https://forum.cloudron.io/post/77654

Looks like logrotate was configured to time out after 90 seconds, and so the large Etherpad log files failed to rotate, and disk filled. Looks like it's time to extend the timeouts and generally review the logrotation config.

I wanted to flag that the latest Cloudron build is the first beta release candidate for Chatwoot v4. (Chatwoot posted a migration guide to accompany the upgrade, but looks like pgvector may already be installed and available.)

I spotted this before our Cloudron app auto-updated so I was able to turn off auto-updates for this app, but I wanted to recommend marking this beta of a major version such that it doesn't get updated by Cloudron automatically.

Problem solved! With these two in my env file, I'm no longer seeing the error messages:
NEXT_PUBLIC_WEBAPP_URL=https://cal.example.com
ALLOWED_HOSTNAMES='"example.com","cal.example.com"'
(I suspect that the first hostname is sufficient on its own. Haven't yet tried removing the second one.)

We ran into this issue recently, too. As a temporary workaround, we updated the code snippet from <domain>/embed/embed.js to https://cal.com/embed/embed.js. The upstream issue is at https://github.com/calcom/cal.com/issues/14990. It looks to me like this regression is being fixed in the calcom/docker repo with https://github.com/calcom/docker/pull/364. Hopefully this gets incorporated in the next upstream release.

@nebulon Confirming that the latest version of cal.com has embed.js rendering and working again!

I wanted to express appreciation to the Cloudron team for great tooling to support reliable updates. The Etherpad app has changed quite a bit since the previous package, and a great set of platform-level features has made managing potentially breaking version updates very manageable:

• allowing user to specify exactly when auto-updates should run
• only auto-updating if the new version is marked as “stable”, with unstable updates available but not automatic
• allowing user to disable auto updates for specific app(s)
• cloning an app to test changes in a sandbox
• backups automatically created before each version update
• one-click to roll back to any past version

Together, these make it low-stress to manage big updates. Great work on the platform!

I wanted to post an update on this based on this response to my post on the Outline repo...

The authentication_providers database record for Cloudron OIDC and for Google Login need the same providerId value (i.e., email domain), but only one can have it set.

I confirmed that if a fresh Outline installation specifies that account management should be left up to the application does work properly with Google Login (assuming GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET are set in env.sh file.)

Ideally, Cloudron login and Google Login options would co-exist, but this isn't strictly necessary in our case.

Last Friday, we found that our Cloudron apps stopped working due to one app (Etherpad-Lite) filling 100% of /dev/root with >100GB of new app logs. We deleted the logs, rebooted, and chalked it up as a one-time issue. Earlier today, this same thing happened a second time: Disk filled with another 100GB of extra platformdata. Running cloudron-support --troubleshoot and rebooting Cloudron resolved the issue, but without a clear understanding of why this happened, I'm concerned that this could happen again.

This leaves me with a few follow-up questions:

• After having already deleted the excess log files, is there anything we can look at to track down the root cause, or is the "evidence" now all gone?
• Do we need to be actively managing log rotation for apps? Should I be setting up app-specific logrotate config files? Recommendations on how to do this?
• Any recommendations on how to monitor or configure alerts on file size or disk usage on Cloudron? (Server is running on AWS EC2, so perhaps I just do this with AWS Cloudwatch tools.)
• I'm seeing a number of recent disk-full threads on Cloudron and they didn't seem to be localized on Etherpad-Lite, so wondering if there are any platform issues that might be related.

Some specifics on our situation:

• saw that our externally-hosted uptime server reported that multiple Cloudron-hosted apps were unresponsive.
• visited Cloudron dashboard and found /dev/root at 100% capacity, with "platformdata" filling up disk usage chart. (160GB disk)
• connected via SSH (AWS EC2 "Session Manager" option failed, presumably due to filled disk)
• found that Etherpad-Lite app had created >100GB of log files in the past day
• tracked down the troubleshooting instructions (idea: link to Troubleshooting page from the "/dev/root at 100% capacity" error dialog)
• ran sudo cloudron-support --troubleshoot, still saw DNS failures, but after rebooting everything started normal again.

Currently using the hosted version. It is excellent! Would definirely prefer to self-host on cloudron if that was an option.

Thank you!