Hi nebulon! Thanks for your thoughtful response. Some notes below.

@nebulon said in Show app disk usage in Storage tab:

So this is either not trivial or certainly misleading. Either this will show a size much larger if you would add up all the apps (if layers are shared) or if we would somehow count shared layers only towards one installed app, would that one be uninstalled, suddenly another app would take up more space.

My particular need would be resolved by the phrase "up to X GB" for the base image, e.g. "up to 1.2 GB" just to give me a rough estimate of things.

@nebulon said in Show app disk usage in Storage tab:

The system info page shows the data used by the app as such already. This is also much improved in the next Cloudron version.

The system info page does NOT show what I am looking for. In particular, for apps that are mounted on a drive other than the default ubuntu image, I do not see the size of the data I'm using. For example, I have Open WebUI at "ask.halecraft.org" but this is nowhere visible on the stats page:

I can't imagine I'm the first to ask for this, but I also can't seem to find any previous discussion on this. The docs talk about setting mounts and moving data, but do not discuss "how much data" I'm using nor how to find it.

I want to know how much space an app is using--both:

• the "base" disk usage (i.e. docker image, and whatever necessary system files it provides), and
• the "user" disk usage (i.e. the additional data on volume mounts or whatever I've configured the app to use to store as it functions)

I realize this might be a costly operation to discover--but a button in the Storage tab with "Measure Current Disk Usage" or something like this would be an acceptable trade-off.

Am I missing an obvious area of the app UI where this is already shown?

Oh wow, what an interesting (and slightly frightening) failure mode! "Your log files are so big that we've given up on managing them."

@msbt said in Windmill: Open-source alternative to Airplane, Superblocks, Retool:

@canadaduane cool, but it seems it's not yet available to the public

Oops! My MIT-licensed code is now public

We have a working Windmill instance on Cloudron, (container) released with MIT license here:

https://github.com/halecraft/windmill-cloudron

The compromise we had to make here was to embed a Postgresql server inside the container, rather than connect to the one provided by Cloudron's postgres addon. Short of modifying Windmill itself, this was the only way we could give Windmill the full control over the Postgres instance that it needs / assumes it has.

@girish Sorry, looks like I got it confused with Windmill. I can't find the Kestra demo.

I've been dabbling with trying to create a Windmill on Cloudron container. It's more difficult than other apps. Some notes:

• There is a hard-coded set of ROLEs required of the postgres database: windmill_admin, and windmill_user. Windmill uses these in DB migration scripts as well as during runtime to control access and access levels (see this section). As far as I can tell, Cloudron's postgres does not offer flexibility to add new roles in the database.
• Windmill's LSP (Language Server Protocol) is itself a docker container with various programming languages (node, deno, python, etc.) pinned to certain versions. Because of these pinned versions, it is difficult to integrate into a single container along with the rest of Windmill. This suggests the docker Cloudron addon may be necessary.
• Windmill also runs workers within docker containers. This may also require the docker Cloudron addon.

In my effort to get most of Windmill running inside the same container, I have supervisord running with the following processes:

• caddy
• windmill-server
• windmill-worker

Caddy (or similar) is needed in order to act as reverse proxy for both windmill-server and the windmill-lsp container's websocket service.

The biggest issue at this point is the hard-coded windmill_admin and windmill_user postgres roles. I'm not sure how to get around this other than to create a separate postgres DB, unfortunately.

Update: never mind. I ran out of disk space. Fixed by deleting the docker registry app that had been holding on to all of the docker data during experimentation.

I've been experimentally trying to create a Windmill for Cloudron container. However, I'm now stuck without the ability to uninstall it, and it has now taken down my whole server

Here is how (I think) I got here:

1. Windmill requires docker service, because it has an lsp container and worker containers that need to spin up during execution.
2. I was trying to diagnose a failure to start, so I entered a cloudron console for windmill and ran the start.sh script that is normally reserved for booting up the Docker container.
3. At this point, the console itself got stuck in a crash loop--it tried connecting, would fail, then would restart, restart, restart...
4. I tried to uninstall the container itself, but that resulted in the error 500 above (with tantalizing "message:" and no message).
5. I then rebooted the server itself, but it won't come up again.

How do I get back to running state? What logs should I look for to find out why I can't boot?

@marcusquinn So far I've been unimpressed I really wanted to like it because the UI is remarkable. However, they've put a lot of effort into making most of the useful things a "Talk to sales" option--from secrets storage to grouping workflows.

I might also be unfairly evaluating the overall software because my primary use case for ActivePieces was to use OpenRouter, and the OpenRouter node has a bug which prevented me from using it in a workflow.

We packaged it up for Cloudron here: https://github.com/halecraft/kestra-cloudron

@james Updated

Main Page: https://kestra.io
Git: https://github.com/kestra-io/kestra
Licence: Apache 2.0
Docker: Yes

Summary:

Kestra is a powerful, fully open-source declarative workflow orchestration engine. It allows developers and low-code users to define, run, and monitor complex workflows using either a UI or YAML-based code. Kestra integrates smoothly with modern developer tooling, including GitHub, and supports two-way synchronization between the UI and code—making it ideal for teams that blend visual and code-based development styles.

Notes:

I've previously used N8N and ActivePieces on Cloudron. While both have strengths, N8N is difficult to integrate with version-controlled development, and ActivePieces limits its useful features behind paywalls. Kestra offers a more open and developer-friendly alternative. With over 18k GitHub stars and 600+ plugins (including LLM support), it has a vibrant and growing ecosystem. I especially appreciate its ability to sync workflows between UI and code, making collaboration seamless between engineers and non-coders.

Alternative to / Libhunt link:

Alternative to: N8N, Airflow, ActivePieces
Product hunt: https://www.producthunt.com/products/kestra

We have an ActivePieces cloudron package working here:

github.com/canadaduane/activepieces-cloudron
https://github.com/halecraft/activepieces-cloudron

As far as I can tell, there is no OIDC setup for the community version of ActivePieces, so no direct integration possibility with Cloudron users.

@Valexico is the MIT license ok with you also?

Thanks @girish! I've added an MIT license. Also, I tested with a basic OPENROUTER_KEY and it seems to work well. I'm not aware of any issues at this time.

I think the CloudronPackagePrompt.md file changed locations or was removed. Here is a URL that includes a commit SHA at a time in the repo when it existed:

https://git.knownelement.com/KNEL/KNELProductionContainers/src/commit/9f74e0fc3977d368f1ca4846843607c75cd05b1c/Techops/CloudronPackagePrompt.md

Here is the prompt, licensed AGPL according to the repo:

Cloudron Application Packaging Wizard

You are a Cloudron packaging expert who will help me package any application for deployment on the Cloudron platform. Using your knowledge of Cloudron requirements, Docker, and application deployment best practices, you’ll guide me through creating all the necessary files for my custom Cloudron package.

Your Process

1. First, ask me only for the name of the application I want to package for Cloudron.
2. Research the application requirements, dependencies, and architecture on your own without asking me for these details unless absolutely necessary.
3. Create all required files for packaging:
   • CloudronManifest.json
   • Dockerfile
   • start.sh
   • Any additional configuration files needed (NGINX configs, supervisor configs, etc.)
4. Create a “[App-Name]-Build-Notes” artifact with concise instructions for building, testing, and deploying to my Cloudron instance.

Key Principles to Apply

CloudronManifest.json

• Create an appropriate app ID following reverse-domain notation
• Set memory limits based on the application requirements
• Configure the proper httpPort which must match your NGINX setup
• Include necessary addons (postgresql, mysql, mongodb, redis, localstorage, etc.)
• Add appropriate metadata (icon, description, author)
• Include a postInstallMessage with initial login credentials if applicable
• Configure authentication options (OIDC or LDAP)

Authentication Configuration

• Configure the app to use Cloudron’s OIDC provider (preferred method):
  • Set up routing to /api/v1/session/callback in CloudronManifest.json
  • Use environment variables like CLOUDRON_OIDC_IDENTIFIER, CLOUDRON_OIDC_CLIENT_ID, and CLOUDRON_OIDC_CLIENT_SECRET
  • Properly handle user provisioning and group mapping
• Alternative LDAP configuration:
  • Use Cloudron’s LDAP server with environment variables like CLOUDRON_LDAP_SERVER, CLOUDRON_LDAP_PORT, etc.
  • Configure proper LDAP bind credentials and user search base
  • Map LDAP groups to application roles/permissions
• For apps without native OIDC/LDAP support:
  • Implement custom authentication adapters
  • Use session management compatible with Cloudron’s proxy setup
  • Consider implementing an authentication proxy if needed

Dockerfile

• Use the latest Cloudron base image (cloudron/base:4.2.0)
• Follow the Cloudron filesystem structure:
  • /app/code for application code (read-only)
  • /app/data for persistent data (backed up)
  • /tmp for temporary files
  • /run for runtime files
• Install all dependencies in the Dockerfile
• Place initialization files for /app/data in /tmp/data
• Configure services to output logs to stdout/stderr
• Set the entry point to the start.sh script

start . sh

• Handle initialization of /app/data directories from /tmp/data if they don’t exist
• Configure the application based on Cloudron environment variables (especially for addons)
• Generate secrets/keys on first run
• Set proper permissions (chown cloudron:cloudron)
• Process database migrations or other initialization steps
• Launch the application with supervisor or directly
• Configure authentication providers during startup

Web Server Configuration

• Configure NGINX to listen on the port specified in CloudronManifest.json
• Properly handle proxy headers (X-Forwarded-For, X-Forwarded-Proto, etc.)
• Configure the application to work behind Cloudron’s reverse proxy
• Set up correct paths for static and media files
• Ensure logs are sent to stdout/stderr
• Configure proper authentication routing for OIDC callbacks

Process Management

• Use supervisord for applications with multiple components
• Configure proper signal handling
• Ensure processes run with the cloudron user where possible
• Set appropriate resource limits

Best Practices

• Properly separate read-only and writable directories
• Secure sensitive information using environment variables or files in /app/data
• Generate passwords and secrets on first run
• Handle database migrations and schema updates safely
• Ensure the app can update cleanly
• Make configurations adaptable through environment variables
• Include health checks in the CloudronManifest.json
• Implement single sign-on where possible using Cloudron’s authentication

We now have a working LibreChat cloudron container set up. See: https://forum.cloudron.io/topic/12850/first-try-app-packaging-librechat-issue-with-postgresql-extention-pgvector/14?_=1749416165430

I have a working setup, based on @Valexico 's work here:

github.com/canadaduane/librechat-cloudron
https://github.com/halecraft/librechat-cloudron

The package has been updated to the latest version of LibreChat 0.7.8, and I fixed a few minor wrinkles such as OIDC login, write access to the public dir, and postgres support. I haven't yet tested it with all of the providers (this requires access keys in the .env file).

@firmansi Thanks! This worked. It would be better if the URL need not be configured inside the app, but just wanted to note that the solution/workaround is ok.