Cloudron Forum

@luckow Good idea, I'll get it done!

@andreasdueren said:

Biggest Feature would probably be Teams with automatic routing etc.

I have started working on it, but expect it will take a few more weeks until it can be reliably shipped.

@fbartels said:

Exchange Webservices as as additional calendar type would be nice, but there does not seem to be something in elixir for this.

That's not an issue! That can also be done in the foreseeable future.

Tymeslot author here.

If you have any feature requests, anything you wish for, use this thread!

For issues, please create separate threads.

I have just run into the same issue.

Isn't the issue that the build process forks into different processes per worker and the sum of it takes too much memory? I had to set my memory limit to 5 GB to get the app to start again. It looks to me like the workers are given 75 % of the memory assigned to umami each, which leads to the issue. Also, does the app have to recompile every single time it restarts?
Maybe the default memory could also be raised above 2 GB considering that several people (also in another thread) faced memory issues before.

@fbartels said:

@joseph That is it (source: I just tried it myself and directly deleted the app again)

Thank you, who would have thought ... I think some better error messages would be good to help the user understand what the issue is.

@jdaviescoates said:

@ekevu123 hasn't this just been added to the official app store?

Not sure it needs to be in both?

It apparently was added, I was never notified of that ... that's better then!

Does that mean we don't need the cloudron versions file anymore, assuming any Cloudron user would prefer the app store install over the manual community package?

I was trying to add my app Tymeslot to the Community App Store using this link to the CloudronVersions.json: https://github.com/Tymeslot/tymeslot/blob/main/CloudronVersions.json

However, it says that the JSON is invalid. Am I missing something? It looks fine to me.

Okay, I will check that!

EDIT: I checked it, but as I see it, this requires to make changes to the OS Cloudron is running on, assuming it would even work. I think that's a bit too much manipulation.

How? I have tried to make it run, but I don't think it works. Gitea Runners need the opportunity to dynamically run docker containers.

It still doesn't run on Cloudron though.

An empty changelog breaks updating a community app, I believe. The update is never shown, and clicking on the button to update it manually makes it load indefinitely without any log entry.

Is there a way to get some sort of feedback for this, so that it doesn't come down to guessing?

What would be even better: some sort of API that I can use during deployment to automatically validate the file and warn me of any issues. But making the above more transparent would be already helpful!

Memory usage tends to be relatively stable, unlike CPU, which spikes heavier.

Can you perhaps use the contact form on tymeslot.app/contact to get in touch? Then I will guide you on which logs are needed to debug this.

I would love to see something like a coloured dot in the notifications to understand what's important.

For example, let's say app updates are orange, so every update notification has a small orange dot on the left. Others, such as "Email is not configured properly" might be red as a configuration issue that deserves attention.

Today, for example, I had 14 notifications in the morning, so this would help focus immediately on what's important.

I use app passwords a lot, but for some, I genuinely don't remember which one I use in my apps, and which one was a test duplicate. It would be great to have a "last used" date, then I could simply see what isn't used regularly, and delete those.

I think you would need to let the database button open a separate terminal window instead of pasting the variables. Not sure if that's worth the effort, I just wanted to point out something that repeatedly gets me.

To clarify: bin/app_name remote doesn't open a Linux shell at all. It attaches to the running Erlang VM and drops you into IEx, Elixir's interactive REPL (read-eval-print loop). At that prompt, you're not typing bash commands - you're typing Elixir expressions that get evaluated live against the running application (this is roughly equivalent to Rails' rails console, Django's manage.py shell, or Node's REPL).
So when the Postgres button injects a bash command like PGPASSWORD=... psql -h ..., IEx tries to parse it as Elixir syntax and understandably chokes.
Opening a second terminal tab works as a workaround, but from a UX perspective I'd expect one of two things instead:

1. The Postgres button detects that the current session is a language REPL (not a plain shell) and opens the psql command in a fresh terminal/tab automatically, or
2. At minimum, a clearer error such as "This command requires a shell prompt, not an interactive REPL" instead of a raw syntax error.

I don't mind particularly if you choose not to act on this, I just keep running into the same issue, because my expectation as a user is different, so I felt like pointing this out.

Sometimes, I have to enter the database shell for a cloudron app in the GUI, which requires several clicks:

1. Open the terminal
2. Enter the new tab
3. Click the Postgres button
4. Hit enter to connect

Not that bad, but since entering the database shell is a separate user story, how about the three dot menu in the GUI and the top-level icons in the app-specific menu got a shortcut entry "open database shell" (if there is a database at all)?

I think this would be handy.

I am working in Elixir, and it uses bin/app_name remote in the terminal on cloudron to enter an interactive debugging shell (that concept exists similarly in other languages).

If I then click the postgres button, it adds this to the shell:

PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE}

However, this command can't be run in the interactive shell, it errors out with a syntax error.

It's clear why this happens, but I think my user expectation would be to open a separate, overlay postgres shell at this point, do what I have to do in the database, and when quitting it, return to my previously opened shell.

Alternatively, there could be a cleaner error, e.g. "This command can't be run inside an interactive shell."

@james Okay, pushed! I couldn't use SSH for some reason, but a personal access token worked.

Is someone here using Infisical? I am looking into it now as a potential secrets manager and was wondering if things are going well with it.

I was also wondering whether it provides any additional benefits over using Cloudron environment variables.