Cloudron Forum

Btw, this shouldn't be inside N8N. This is more a request for an app, not N8N alone.

Hi guys, I think we need to revive this post again:

The Rocket.Chat Apps Engine is broken on both Cloudron package versions 3.1.0 (upstream 8.2.1) and 3.2.0 (upstream 8.3.1). No marketplace apps can be installed or run.

Error logs:

error: failed reading lockfile '/app/code/bundle/programs/server/npm/node_modules/@rocket.chat/apps-engine/deno-runtime/deno.lock'

Caused by:

Error getting response at https://registry.npmjs.org/@msgpack/msgpack for package "@msgpack/msgpack": An npm specifier not found in cache: "@msgpack/msgpack", --cached-only is specified.

Root cause:
The deno.lock file is located in /app/code/, which is on the read-only Docker image layer. When Deno tries to resolve the @msgpack/msgpack npm dependency, it can't find it in cache and can't update the lockfile because the filesystem is read-only (Read-only file system, os error 30).

This means the Deno runtime can't start app subprocesses, so all marketplace apps (e.g. Giphy) fail with compiler errors and crash-loop.

Steps to reproduce:
Install or update to Rocket.Chat 3.1.0 or 3.2.0 on Cloudron
Go to Admin > Apps > Marketplace
Try to install any app (e.g. Giphy)
Installation fails with "The App had compiler errors, can not enable it"

Suggested fix:
Either pre-cache the @msgpack/msgpack npm package in the Docker image at build time, or move the Deno cache/lockfile to a writable location (e.g. /app/data/ or /tmp/).

Thanks!

Same issue here. Workflow downloads audio from some of our tools and uploads to Azure OpenAI Whisper via multipart form. Azure logs confirm requestLength: 0 on every request. Container logs show the same "Unable to calculate form data length / data should be a string, Buffer, or Uint8Array" errors. Can Cloudron roll back to 4.8.2 or push a patched version? OR what's the plan here?
This broke 5 different workflows and things inside my whole enviroment, not critical, but data has been lost in this.

Hi folks

I’m running the Cloudron Postiz app and I’m blocked uploading videos because Postiz returns:

413 Content Too Large on:
POST /api/media/upload-server

In the browser Network panel I see the response header server: nginx and the upload fails around ~5MB.

I confirmed with an internal test that this is not Cloudron’s outer proxy, but the nginx inside the Postiz container:

# created a 6MB file...
dd if=/dev/zero of=/tmp/6mb.bin bs=1M count=6

# called the Postiz nginx directly (inside the container)
curl -sS -o /dev/null -w "%{http_code}\n" \
  -F "file=@/tmp/6mb.bin" \
  http://127.0.0.1:5000/api/media/upload-server
# => 413

The nginx vhost used by the container is:

/etc/nginx/sites-enabled/postiz.conf

and currently it contains no client_max_body_size directive (also confirmed via nginx -T | grep client_max_body_size → no output). Adding client_max_body_size would be the standard nginx fix (Postiz docs also suggest it for 413s).

However, because this is a Cloudron app, I can’t apply persistent patches to the packaged nginx config within the container, right? (Am I missing something here?).

Request/proposal:
Could the Cloudron Postiz package include a higher client_max_body_size (or make it configurable), ideally scoped to the API location block?

Example:

location /api/ {
    client_max_body_size 200M;  # or 1G
    proxy_pass http://localhost:3000/;
    ...
}

Happy to test a package build or PR if you point me to the exact config template file used to generate /etc/nginx/sites-enabled/postiz.conf.

Thanks!

Agree! Would love to see WAHA in the App store.