Cloudron Forum

Happy to help. No /app/data/twenty-front/ holds no user-uploaded content.
On my instance it only contains front build artifacts: assets/ (hashed JS bundles), images/, manifest.json, index.html, mockServiceWorker.js, all dated from install day and matching what ships in dist/front.orig. Nothing user-generated. The only dynamic piece is the .env symlink, which already points to /run/twenty-front/.env, not into /app/data.

@james I have some news
The update refreshed the server to 2.9.0 in /app/code, but the prebuilt frontend in the persistent volume /app/data/twenty-front was never re-synced — it still held the original 0.14.0 front from install (files dated from install day; index.html still pointing to the old bundle index-CGzHeZZA.js).
That stale bundle queries GaugeChartConfiguration, a type removed server-side in 2.3. So a 2.8.0-era front was served against a 2.9.0 schema → Unknown type "GaugeChartConfiguration" → blank page on load.

Confirmed: the string is present in /app/data/twenty-front/assets/ but absent from the fresh package front in /app/code/packages/twenty-server/dist/front.orig/assets/ (different hashes).

Fix: copied assets/, images/, manifest.json, index.html from dist/front.orig/ → /app/data/twenty-front/ (keeping the .env symlink), then restarted. App works.

Hope this helps

Alright thanks

Thanks for testing, that's actually my exact path. My instance was installed fresh as package v0.14.0 (Twenty 2.8.0) on May 29, then auto-updated v0.14.0 → v1.0.0 (2.9.0) on June 7 at 01:00. So same package versions and same Twenty versions as your repro.
The only difference left is data: yours is a clean install, mine had ~9 days of real data created under 2.8.0 (contacts, deals, and possibly a default dashboard/widget). I never manually created a chart, but a default dashboard widget referencing GaugeChartConfiguration could have been seeded under 2.8.0.
Could you share a SQL query to check whether any stored dashboard widget / chart configuration references GaugeChartConfiguration? If that's the culprit, I'd much rather delete that specific record than roll back the whole instance and lose 3 days of data.

Hi @james,
Here is the output :

Vendor: QEMU Product: Standard PC (i440FX + PIIX, 1996)
Linux: 6.8.0-124-generic
Ubuntu: noble 24.04
Cloudron: 9.2.0
Execution environment: kvm
Processor: Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz
BIOS pc-i440fx-8.1  CPU @ 2.0GHz x 2
RAM: 4009860KB
Disk: /dev/sda1        18G
[OK]	Root disk usage is OK (47%)
[OK]	Memory usage is OK (52%)
[OK]	Clock is NTP-synchronized
[OK]	node version is correct
[OK]	IPv6 is enabled in kernel. No public IPv6 address
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	unbound is running
[OK]	IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[SKIP]	IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip — no public IPv6 address
[OK]	IPv4 HTTPS to auth.docker.io/token
[SKIP]	IPv6 HTTPS to auth.docker.io/token — no public IPv6 address
[OK]	IPv4 HTTPS to acme-v02.api.letsencrypt.org
[SKIP]	IPv6 HTTPS to acme-v02.api.letsencrypt.org — no public IPv6 address
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[WARN]	Service 'mysql' is not running (may be lazy-stopped)
[OK]	Service 'postgresql' is running and healthy
[WARN]	Service 'mongodb' is not running (may be lazy-stopped)
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.2.0 is running
[OK]	Dashboard is reachable via IPv4 (https://xxx)
[SKIP]	Dashboard IPv6 reachability — no public IPv6 address
[SKIP]	Domain expiry check — whois did not return an expiry date for 

======== Summary ========
PASS:  24
WARN:  2
FAIL:  0
SKIP:  5

Warnings:
  - Service 'mysql' is not running (may be lazy-stopped)
  - Service 'mongodb' is not running (may be lazy-stopped)

For troubleshooting tips, see https://docs.cloudron.io/troubleshooting
To share a full diagnostic dump on the forum, run: cloudron-support --send-diagnostics

After the package update to Twenty 2.9.0, the app no longer loads — blank page in the browser.
The server side is healthy and fully on 2.9.0:

yarn command:prod upgrade:status → Instance 2.9.0 and the single workspace 2.9.0, both Up to date, 0 workspaces failed.
Server logs: [NestApplication] Nest application successfully started, all routes mapped, healthcheck green after boot (0 ECONNREFUSED once started), BullMQ worker processing jobs, no 500s and no GraphQL errors server-side.

The failure is frontend-only. At app load, the browser console throws:

Uncaught (in promise) CombinedGraphQLErrors: Unknown type "GaugeChartConfiguration".
Did you mean "BarChartConfiguration", "LineChartConfiguration", "PieChartConfiguration",
"AggregateChartConfiguration", or "CalendarConfiguration"?
  at /assets/index-CGzHeZZA.js

So the shipped frontend bundle queries a GraphQL type (GaugeChartConfiguration) that the 2.9.0 server schema does not define the package's front and server look built against different schemas.

Already tried, no effect:

• Reproduced in a clean private/incognito window → rules out browser cache.
• yarn command:prod cache:flush + restart → same error.
• App Repair → same error.

The only thing that would restore a working UI is rolling back to the pre-2.9.0 backup, which loses ~3 days of data, so I'd rather not.

Questions:
Is this a known front/server mismatch in the 2.9.0 package?
Is a corrected 2.9.x already available, or coming?
Is there a supported way to realign the frontend bundle with the server without a full rollback?