Cloudron Forum

We hope to see this app available soon. We are already using it in a self-hosted setup on our systems, but for convenience we would like to migrate it to Cloudron.
How can we help you make this happen?

Thank you

Hi,

I'm running the Twenty CRM Cloudron app and trying to use Logic Functions with LOGIC_FUNCTION_TYPE=LOCAL. Execution fails systematically because the local driver tries to create a .yarn directory inside the read-only /app/code, which Cloudron doesn't allow. This looks like a packaging gap rather than a Twenty bug, and the fix appears small.

Environment

• Cloudron: 9.2.0
• Twenty app package version: 1.1.0
• Twenty version: 2.9.0
• Relevant config: LOGIC_FUNCTION_TYPE=LOCAL

What happens

When a workflow triggers a Logic Function, the server throws:

ERROR [LogicFunctionExecutorService] Logic function execution failed: ... driver=LocalDriver, mode=LIVE:
Internal Error: ENOENT: no such file or directory, mkdir '/app/code/packages/twenty-server/.yarn'
    at copyYarnEngineAndBuildDependencies (.../application-package/utils/copy-yarn-engine-and-build-dependencies.js)
    at LocalLayerManagerService.ensureDepsLayer (.../logic-function-drivers/drivers/local/services/local-layer-manager.service.js)
    at LocalDriver.execute (.../logic-function-drivers/drivers/local.driver.js)

Root cause

The LOCAL driver's LocalLayerManagerService builds a per-function dependency layer by creating a .yarn directory inside packages/twenty-server/ and copying the Yarn engine into it. Since /app/code is mounted read-only on Cloudron, the mkdir fails.

I confirmed it's the mount, not a permission issue, even in the Web Terminal:

# id
uid=0(root) gid=0(root) groups=0(root)
# touch /app/code/_test_write
touch: cannot touch '/app/code/_test_write': Read-only file system

Two observations that point straight at the fix:

1. The Yarn engine is present, but only at the monorepo root (/app/code/.yarn, .yarnrc.yml, .corepack). It's the per-package packages/twenty-server/.yarn that's missing and can't be created.
2. The package already redirects writable runtime paths under twenty-server to /run via symlinks:

packages/twenty-server/.cache -> /run/twenty-server/cache
packages/twenty-server/.env   -> /run/twenty-server/.env

So the same, proven pattern just needs to be extended to .yarn.

Suggested fix

Apply the existing symlink approach to the layer directory in the Dockerfile:

RUN ln -sf /run/twenty-server/yarn /app/code/packages/twenty-server/.yarn

and create the target early in entrypoint.sh:

mkdir -p /run/twenty-server/yarn

A couple of notes for whoever picks this up:

• The driver doesn't only create .yarn; it then runs a Yarn install to build the deps layer, so the redirect target must stay writable and the container needs outbound network during that step. There may be one or two further writable paths the install needs, worth checking once the first mkdir is unblocked.
• /run is ephemeral, so the layer would be rebuilt after a restart (same behaviour as .cache). If rebuild-on-restart is undesirable, /app/data/twenty-server/yarn would persist instead.

App: Twenty
Version: instance reports 2.37.0

Summary

start.sh appends a hardcoded IS_CONFIG_VARIABLES_IN_DB_ENABLED=false after copying /app/data/env, so any value a user sets for that variable in /app/data/env is silently overridden on every start.

Details

In /app/pkg/start.sh:

cat /app/data/env > /run/twenty-server/.env
cat >> /run/twenty-server/.env <<EOT
IS_CONFIG_VARIABLES_IN_DB_ENABLED=false
...
EOT

Since the generated .env is read top to bottom, the appended line wins. I had IS_CONFIG_VARIABLES_IN_DB_ENABLED=true in /app/data/env; the resulting /run/twenty-server/.env contains false.

Impact

With database configuration disabled, Twenty's Admin Panel still renders the Configuration Variables and AI model settings, but no write succeeds. From the UI this looks like a broken feature rather than a deliberate deployment mode — in my case a generic "failed to update model recommendations" toast with no indication that the panel is read-only by design.

It also means the only way to configure the instance is to edit /app/data/env and restart, which is not discoverable from the app itself.

Suggested fix

Only append the default when the user has not set it:

grep -q '^IS_CONFIG_VARIABLES_IN_DB_ENABLED=' /app/data/env \
  || echo 'IS_CONFIG_VARIABLES_IN_DB_ENABLED=false' >> /run/twenty-server/.env

Same pattern would apply to any other variable in that heredoc that isn't strictly infrastructure-bound (the Postgres/Redis/APP_SECRET lines obviously need to stay authoritative).

Happy to test a build if that helps.

We are currently running it self-hosted in Docker on our NAS, but we would migrate to Cloudron if it becomes available.

Can we help ?

Error logs

QueryFailedError: column core.workspace.useRecommendedModels does not exist
code: '42703'
routine: 'errorMissingColumn'

This happens during a query when checking user existence (CheckUserExists).

What I understand

It looks like the application expects new fields in the core.workspace table, but the database schema was not updated accordingly.

What I tried

I manually added one missing column:

ALTER TABLE core.workspace 
ADD COLUMN "enabledAiModelIds" jsonb;

But the app still fails due to another missing column:

useRecommendedModels

Additional issue

I tried to run migrations manually:

npm run typeorm migration:run

But the script does not exist.

@nebulon

The documentation say :
"Cross-version upgrades (v1.22+)
Starting from v1.22, Twenty supports cross-version upgrades. You can jump directly from any supported version to the latest release without stepping through each intermediate version. For example, upgrading from v1.22 straight to v2.0 is fully supported."

So I think it's ok for now.

Yes,

Pricing here : https://twenty.com/pricing

It looks interesting for us too. How can we help ?

@marcusquinn Do you have any update from the Cloudron team? I’d like to use Twenty CRM with my team, but I’m not sure whether I should try installing it myself with Docker or wait for your Cloudron integration.

@girish @nebulon

@marcusquinn Thanks for your work on the Twenty CRM integration with Cloudron.

Would it be possible for you to share your integration (even if it’s just a test or partial setup)?
I’d like to try deploying it internally with my team and, if needed, contribute to improving or adapting it, while we wait for validation of the integration from the Cloudron team.

+1
I think GlitchTip is still worth packaging alongside Bugsink rather than instead of it.

Bugsink is deliberately errors-only. Sentry self-hosted is unusable at small scale : Kafka, ClickHouse, Snuba. GlitchTip lands in between: clearly more complete than Bugsink (uptime monitoring, performance data, teams/orgs, alert integrations) for a fraction of Sentry's footprint, just Django + PostgreSQL + Redis + a Celery worker.

MIT licensed, official Docker images, drop-in compatible with the Sentry SDKs. For a small team it's the right trade-off, and it maps cleanly onto Cloudron's existing addons. Happy to help test a package.