Cloudron Forum

• Main Page: https://www.fizzy.do/
• Git: https://github.com/basecamp/fizzy
• Licence: O'Saasy License
• Dockerfile: ?
• Demo: https://www.fizzy.do/

• Summary: Kanban as it should be, not as it has been. Fizzy is a fresh take on cards and columns, with a few twists, human-nature inspired defaults, and a vibrant interface that’s the opposite of the bland and boring software the industry has been flinging at you for years.

• Notes: Really like the idea and the concept and love to selfhost on my cloudron.

• Alternative to / Libhunt link: Trello, Asana, Jira,
• Screenshots:

I’ve just finished packaging Fizzy for Cloudron myself and the app is already running great on my instance

If anyone is interested, here are the Git repo and Docker image:
Git: https://github.com/patattzel/fizzy-cloudron
Docker Hub: https://hub.docker.com/r/pathab/fizzy-cloudron

It’s still a bit quick and dirty, but fully functional. Features like “first user becomes admin” and disabled signup are already implemented. More refinements will follow.

Regarding the license discussion:
From my perspective, this should not be an issue for Cloudron. Cloudron isn’t offering Fizzy as a hosted SaaS product. It simply enables users to self-host the software on their own servers.

@james The community apps feature completely went past me...that's a great addition!

I've just updated the repo to support the new publishing setup. After a few initial hiccups I managed to get everything sorted out. You should now be able to install it via:

https://raw.githubusercontent.com/patattzel/fizzy-cloudron/refs/heads/main/CloudronVersions.json

I've tested it myself and it seems to work. Please let me know if anything doesn't work as expected. Happy to hear if it succeeds on your side as well.

Please also keep the O'Saasy licensing in mind!

I’ve actually been running Fizzy on my own Cloudron instance continuously since the start of this forum thread.

The project has seen a lot of updates since then and is being actively pushed forward. So far I haven’t had any issues keeping my fork in sync with the latest releases, and the recent versions have been stable for me in day-to-day use.

If anyone wants to try it out themselves, you can install it on your own Cloudron instance via the Cloudron CLI with:

cloudron install --image pathab/fizzy-cloudron:latest

So from a packager’s perspective, it’s been very workable and maintainable.

Good point.

It would actually be helpful if apps with such licenses were explicitly marked in Cloudron, or if there were a setting/flag for reseller environments to warn about license restrictions before installation.

@luckym So far I've mostly just pulled the latest changes from upstream sporadically and merged them into the repo without overwriting my Cloudron-specific adjustments.

With Cloudron updates you can always roll back if something breaks, so that makes it a bit less risky. But to be honest, it has always worked fine so far. Proper testing for the Cloudron package would definitely make sense though.

Recently I set up my OpenClaw to check and sync upstream weekly, which helps keeping things more up to date automatically

The Docker image is already packaged specifically for Cloudron and includes the CloudronManifest.json, so no additional manifest is required for installation when using the image.

Feel free to add it to your custom installer if that’s useful for users, but everything needed is already bundled in the image itself.

Repo is here: said in Fizzy on Cloudron - the Kanban tracking tool for issues and ideas by 37signals:

Git: https://github.com/patattzel/fizzy-cloudron

On Cloudron 10.0.4 with the current n8n package 4.42.3 (n8n 2.38.7), I found that:
/app/data/user/.cache/n8n/public/assets had grown to 4.5 GB and 82,398 files, while the PostgreSQL database was only 15 MB.

After stopping n8n, deleting the generated public cache and restarting:

• app data: 4.5 GB → 76 MB
• cache files: 82,398 → 1,565
• n8n started normally and /healthz returned HTTP 200

It appears that n8n’s generateStaticAssets() copies newly hashed frontend assets into its persistent cache on every update without removing assets from previous versions. Since the Cloudron package persists the user home under /app/data/user, these stale files are also included in every backup.

Could the package clean /app/data/user/.cache/n8n/public before starting n8n, or is there another intended solution?

Yes, I have set everything up according to the docs. I tried a little more today. I was able to find out that I can check the mails using the command

sudo -u git -H bundle exec rake gitlab:incoming_email:check RAILS_ENV=production

The result is now as follows:

Checking Incoming Email ...

Incoming Email: ... Checking Reply by email ...

IMAP server credentials are correct? ... Checking gitlab@mydomain.xyz
Checking servicedesk@mydomain.xyz
yes
Mailroom enabled? ... no
  Try fixing it:
  Enable mail_room
  For more information see:
  doc/administration/reply_by_email.md
  Please fix the error above and rerun the checks.
MailRoom running? ... can't check because of previous errors

Checking Reply by email ... Finished


Checking Incoming Email ... Finished

I've already tried a few things to activate mail_room, but I just can't do it. Does anyone have any ideas?

@luckym Yep, it's been working great. I use it privately every day and still run it on my Cloudron. I also keep the repo updated regularly, and so far every update has gone smoothly without any issues.

Is there something specific you're wondering about?

Hello, the login via Cloudron OpenID no longer works for all apps since I updated to V7.7.0. I have already tried several things, reinstalled apps and now also reinstalled the entire server and restored it from the backup. What else can I do?

The following apps are affected:

• Matomo (Unexpected response from the OAuth service.)
• Typebot
• Gitea (/user/oauth2/cloudron for xxx.xxx.xxx.xxx:0, 500 Internal Server Error)
• Rallly

All apps are up to date.

I looked through the logs again today and found something conspicuous:

Apr 23 10:57:32 from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:178:in `new_message_ids' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:163:in `new_messages' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:135:in `process_mailbox' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:45:in `wait' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/mailbox_watcher.rb:37:in `block in run' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-client-0.21.1/lib/redis_client/connection_mixin.rb:71:in `call_pipelined': WRONGPASS invalid username-password pair or user is disabled. (redis://redis-19727d9f-cec9-4b73-8b77-3cf41a03008c:6379) (RedisClient::AuthenticationError) <30>1
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-client-0.21.1/lib/redis_client.rb:771:in `block in connect' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-client-0.21.1/lib/redis_client/middlewares.rb:16:in `call' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-client-0.21.1/lib/redis_client.rb:770:in `connect' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-client-0.21.1/lib/redis_client.rb:732:in `raw_connection' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-client-0.21.1/lib/redis_client.rb:697:in `ensure_connected' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-client-0.21.1/lib/redis_client.rb:292:in `call_v' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-5.0.8/lib/redis/client.rb:90:in `call_v' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-5.0.8/lib/redis.rb:152:in `block in send_command' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-5.0.8/lib/redis.rb:151:in `synchronize' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-5.0.8/lib/redis.rb:151:in `send_command' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-5.0.8/lib/redis/commands/strings.rb:95:in `set' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-namespace-1.10.0/lib/redis/namespace.rb:558:in `wrapped_send' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-namespace-1.10.0/lib/redis/namespace.rb:515:in `call_with_namespace' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-namespace-1.10.0/lib/redis/namespace.rb:389:in `block (2 levels) in <class:Namespace>' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/arbitration/redis.rb:41:in `deliver?' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/mailbox.rb:108:in `deliver?' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:178:in `block in new_message_ids' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:178:in `select' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:178:in `new_message_ids' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:163:in `new_messages' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:135:in `process_mailbox' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/imap/connection.rb:45:in `wait' <30>1 
    2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - from /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/gitlab-mail_room-0.0.24/lib/mail_room/mailbox_watcher.rb:37:in `block in run'
Apr 23 10:57:32 2024-04-23 08:57:32,492 INFO exited: mail_room (exit status 1; not expected)
Apr 23 10:57:33 2024-04-23 08:57:33,494 INFO spawned: 'mail_room' with pid 60817

I find that in particular a bit strange:

2024-04-23T08:57:32Z cbe-svpv-http01 19727d9f-cec9-4b73-8b77-3cf41a03008c 1126 19727d9f-cec9-4b73-8b77-3cf41a03008c - /home/git/gitlab/vendor/bundle/ruby/3.0.0/gems/redis-client-0.21.1/lib/redis_client/connection_mixin.rb:71:in `call_pipelined': WRONGPASS invalid username-password pair or user is disabled. (redis://redis-19727d9f-cec9-4b73-8b77-3cf41a03008c:6379) (RedisClient::AuthenticationError) <30>1

btw. I just love how easy it is to transfer cloudron to a new server!

@girish Works like a charm. Many thanks for the fix!

It seems like you're right and the new modem is the problem, sorry I forgot to mention that - didn't expect that to be the cause. (Because cloudron has been running very smoothly for over a year now).
Well, I have now moved the server to a VPS. Everything seems to be working there now. I will try to get my cloudron home server up and running again at a later date. Thank you very much for your time and support!

I just tested this with a fresh installation (com.gitlab.cloudronapp@1.114.1), and I'm unable to add a profile picture to a group. Whenever I try, I get a 403 Forbidden error.

In the logs, I see the following message:

[ActionDispatch::HostAuthorization::DefaultResponseApp] Blocked hosts: localhost:8080

I've already tried changing various settings, but nothing seems to fix the issue. I’m currently stuck. Does anyone know what might be causing this or how to resolve it?

Perfect, thanks a lot!