@fengchang How are you using this? As an AI brain? Personal 2nd brain or something else?

@luckow yes, this is the difference with our remote-self-hosted setup. 9router expects it to be on a local system, but that doesn't mean we can't change that. That's also in the upstream code so I'm not sure I can change that as a runtime env, or if it's even capable of evaluating a $HOST variable. Open to suggestions and if it's obvious how to fix it, drop a PR.

@creative567145 Thanks, that log was enough to identify it. This is a different issue from the earlier gateway status detection bug. The fresh install was hanging before supervisor started because start.sh ran: npx agent-browser install without forcing non-interactive mode. On a new /app/data volume, npx prompts with “Ok to proceed? (y)”, but Cloudron has no TTY there, so startup never reaches supervisor and port 8000 never binds. I pushed package version 0.4.32 with the fix: npm_config_yes=true npx --yes agent-browser install So fresh installs should no longer block at that prompt. Existing installs where the browser runtime is already seeded were likely unaffected, which is why this showed up on a clean installation.

Upgraded to upstream v2.2

Update: hardening pass complete, production-proven, and one correction on backups A few days on from the original post, the package has been through a full integration and hardening pass on a live Cloudron box. Most of this is good news. There is also one correction to a claim in the original that is important enough to lead with. ️ Correction: bundled-ClickHouse backup needs care (a fix is in progress) The original post said that /app/data backup "just works, no custom backup hook needed." That holds right up until ClickHouse happens to be running a background merge during the backup snapshot. Here is the race. ClickHouse continuously creates and deletes temporary merge directories under its store (tmp_merge_*, tmp_insert_*, tmp_fetch_*). Cloudron's rsync syncer walks that tree, and if one of those directories disappears between enumeration and read, readTree receives null and crashes on .sort(). The part that matters: that crash aborts the entire server backup run, not only Langfuse. Every app scheduled after it is left on the previous night's snapshot. The failure is timing-dependent, so it appears intermittently with no configuration change on your side. This affects any ClickHouse-backed package (Plausible, PostHog, SigNoz, and others), so we have filed it upstream as a platform robustness issue: https://forum.cloudron.io/topic/15663/backup-task-crashes-when-a-clickhouse-app-deletes-a-temp-merge-dir-mid-snapshot. A single null-guard before the sort would fix it for every affected app. Until that lands, the workaround (full detail in KNOWN-ISSUES.md: Exclude Langfuse from the automatic backup schedule so a racy run cannot abort the others, and back it up out of band. One correction to the obvious workaround: Cloudron will not back up a stopped app, so "stop the app, then back it up" is not a valid path. A quiesced backup has to be a filesystem-level snapshot taken outside the platform, or you simply re-run the schedule, since it is a timing collision and usually clears on the next attempt. The real fix is the next release. Version 0.2.0 moves the ClickHouse store to a persistentDir and backs it up as a consistent logical dump through backupCommand and restoreCommand, which removes the race structurally, because the syncer never walks the live store at all. It is scoped and tracked, and it gets its own backup-and-restore round-trip gate before it ships. What is new since the original A full hardening pass on the live instance, covering the code, configuration and dependency surface, container capabilities, the network surface, the authentication surface, and secrets at rest and in transit. Verdict: pass. The write-up is here: SECURITY.md. In short: the internal services (ClickHouse and the worker) are unreachable from outside; the only surface open without a login is /api/public/*, which is API-key gated by design; secrets are 0600; and the encryption key is byte-identical across both update and restore. Production-proven from the public package: installed from the versions-url exactly as any operator would, OIDC single sign-on confirmed end to end, presigned trace-media working through the proxy, update and backup-restore both preserving the encryption key, and memory measured under sustained ingestion (peak around 2.6 GiB, with the 5 GiB default holding comfortably). Integration note: agentgateway If you are considering wiring agentgateway's own traces into Langfuse, it will not work on agentgateway 1.3.1, and the cause is not on the Langfuse side. Its config.tracing OTLP exporter sends cleartext even when the endpoint is https://, and Cloudron's TLS-terminating proxy rejects that with a 400. Langfuse accepts the identical payload over TLS without complaint. agentgateway simply will not negotiate TLS for trace export, and there is no configuration option to change that. Filed upstream: [agentgateway issue — link]. Open WebUI and the Langfuse SDKs both handle TLS correctly, so the integrations described in the original post work as written. What is next Version 0.2.0 is the ClickHouse backup rework described above. Source, issues and pull requests are here: https://github.com/OrcVole/langfuse-cloudron. Real-world memory-footprint reports and "works on my install" confirmations remain very welcome.

@LoudLemur well done Be aware that windmill push out releases like their pants on fire. Almost daily at times. My windmill community package has fallen behind, and I’m not much motivated to be constantly re-packaging it for Cloudron. I’m likely to do one update then freeze it or hand the baton over. So very pleased to see your package as alternative. It would likely save you some hassle to decide an upgrade policy for Windmill. Once per week or whatever. Otherwise you might be forever publishing.

I haven't tested it with a gpu(would need to pass device through i think), but yeah, it likely won't work well without one(though ik_llama backend might be good for modern cpus).

@jdaviescoates Thank you again. I didn't see the wood for the trees!

@timconsidine The one who asks

Can be deleted

@girish Well, if developers like @luckow essentially maintain their own appstore, I fully agree. With all other community apps, you always risk going down the Yunohost way - a plethora of apps, many if not most unmaintained. Your USP is - inter alia! - that people can rely on well maintained apps. IMHO opinion, the goal should always be to maintain a broad-ranging, well maintained appstore. This is also relevant in a commercial scenario, where individuals/companies have to ascertain risks before implementing Cloudron („are those apps maintained and up-to-date?“).

Can you check the logs for any error? Regarding the e-mail, the issue could be a wrong email setup. Have you installed it as a Cloudron community app?

I'm the one who deployed to the demo instance to test if the image/manifest could be pulled from an instance without credentials. And yes, the HTTP endpoint returns a 404 because it's a REST API. You can fetch the server status even without a token : curl https://terraria.demo.cloudron.io/v2/server/status { "status": "200", "name": "", "serverversion": "v1.4.5.6", "tshockversion": "6.1.0.0", "port": 7777, "playercount": 0, "maxplayers": 16, "world": "World", "uptime": "0.02:02:19", "serverpassword": false }

It would be great to get a Zammad Package out there! https://forum.cloudron.io/post/1224

@andreasdueren Three reasons I chose nginx: nginx is already in the base image and central to the Cloudron model. nginx is incredibly light. Caddy’s biggest selling point (auto-HTTPS) is completely irrelevant to Cloudron apps, which are behind a reverse proxy anyway.