Cloudron Forum

Ah so essentially this: https://forum.cloudron.io/topic/1977/platform-data-and-other-disk-usage/26

@james said: Maybe you could do a test if possible. If you add a new storage site, that is also rsync and a hetzner storage box and create a fresh backup maybe this issue does not exist on the new backup site then. That's what I'm doing at present... will report back once it finishes and I've done the integrity check...

VPS (shared resource) is always a risk, but I only ever had one problem where claimed specs were not really available runtime (SSDNODES). Netcup is decent so you should get what you pay for. But if your Cloudron is "production" (meaning you rely on it for services), I would go for something more dedicated resource. My first destination is Hetzner Auctions. Interestingly their auctions are cheaper than their shared-resource VPS currently. They're pinched on RAM etc costs, but auction is still cheaper than VPS. My current Hetzner production cloudron is cheaper (60 euro) with much better specs than their cheapest dedicated auction (75 euro). But I think it's an industry thing, rather than a Hetzner thing.

Hello @loudlemur @LoudLemur said: Request 2 stands. A slow cold-model call completes via localhost inside the container, but through the reverse proxy it is cut at 60 seconds every time. Just raising the timeout higher is not a resilient approach. One system might have a response time of 30s and on another maybe 60s+ So no matter to what value the timeout is set, it can always reach the timeout. This sounds more like an design issue of the application. If something is still working it should inform the pending request about that and not simply do nothing until a timeout is reached. Something similar we just hit with https://forum.cloudron.io/topic/15914/large-app-backup-70gb-fails-at-rotate-copy-step-with-nosuchkey-ionos-s3-read-after-write-consistency-but-cloudron-has-no-retry Where the IONOS proxy in front of the S3 server simply did not respond, reached the timeout of 600s while it was in reality still working. This was because IONOS did not implement CompleteMultipartUpload of S3 correctly. While the CompleteMultipartUpload request could take several minutes to finalize and that is why S3 should periodically sends white space characters to keep the connection from timing out. They did not do that and thus proxy timeout was reached and caused all sort of issues. They could have increased the timeout to 1000s, 2000s or what ever value, but it would not have fixed the actual issue. The same can be applied here. If a slow cold-model takes time to complete, it should report it is still working instead of doing nothing causing the proxy to throw the timeout.

[2.2.0] Update grav to 2.2.0 Full Changelog Rebuilding the pages cache no longer writes a compiled file for every page, so the first request after a cache clear is much faster on large sites. A new pages.frontmatter.native_yaml setting reads page frontmatter with the much faster YAML extension when the server has it installed. It is off by default because the extension reads unquoted dates and yes/no differently. pages.lazy_index now defaults to auto, which uses the page index on sites with 1,000 pages or more and the classic pages cache on smaller ones, so large sites load pages faster and use far less memory without any setup. CSS minification now uses wikimedia/minify, which understands modern CSS and is about 15 to 25 times faster on real stylesheets. Sites on Apache older than 2.4.8, common on Plesk and CentOS 7 hosts, no longer answer 500 for everything under user/ after upgrading, and upgrading fixes the .htaccess files earlier releases wrote there (grav-plugin-admin2#179) Plugins' onShutdown work runs again after Admin Next saves on sites with session.read_and_close on, when another plugin had already finished the response. Deleting or renaming a page folder is now picked up without clearing the cache. The file change check no longer counts files that only contain .md somewhere in their name, such as page.md.bak, or whose name merely ends in yaml. Searching Flex pages now matches a page's route as well as its title, slug and menu. calc() inside @media, @supports and @container conditions keeps its spacing when CSS is minified, so browsers no longer drop those blocks.

@james said: Maybe you could look into these findings and we can move everything into your community app. Thank you, James. We will get onto this right away and will try and improve it as you suggested. It is ironic that search packages found each other like this. I also packaged an application for cloudron and found that somebody else had already created one! We must be soul mates. It is kind of like a dating site where Packagers go to find people with similar interests!

Thank you for the request, @Teiluj. We like Paperclip and we are going to package it as a community app. Before we do so, here are some concerns which people who might want to use a Paperclip package may like to read, because this app is not like most on the store. What concerns us Agents run inside the app. Paperclip starts Claude Code, Codex and similar tools as processes in its own container, and upstream hands them the server's full environment. On Cloudron that includes the database credentials, and the key that encrypts every stored secret is a readable file. An agent that reads a hostile ticket or repository could take over the whole Paperclip instance. Upstream's sandbox cannot run here. It relies on Linux namespaces, which Cloudron app containers do not allow. The internal network is reachable. Any app container can reach the shared database servers and other apps directly, which also bypasses proxyAuth. An unconfined agent would be a foothold inside the server, not just inside Paperclip. Sign-in is email and password only. There is no OIDC yet (it is an open pull request upstream, not a plugin), and the server sends no email at all, so there is no password reset. It moves fast. Releases are roughly weekly, and one recent release carried 49 database migrations. One correction to the post above: Paperclip does not use Redis or Qdrant. It needs only PostgreSQL, which the Cloudron addon provides. How we intend to handle it Agents run as a separate, unprivileged user, started through a narrow sudo rule with a clean environment. They cannot read the database credentials, the encryption key or the server's memory. A firewall inside the container, matched on that user for both IPv4 and IPv6, blocks the internal network and outbound mail. The internet, DNS and Paperclip's own API stay open. Process and file-size limits apply to the agent user. Telemetry is off by default, and so are Paperclip's own database dumps, because Cloudron already backs up PostgreSQL. We have tested this design on a test Cloudron. The agent user was refused on every database and every other app, saw no secrets, and still reached the internet. Advantages You can run local agents without handing them the server. It works on stock Cloudron. It needs only the net_admin capability, which Cloudron offers to apps: no Docker socket and no privileged container. The listing will say plainly what an agent can and cannot reach. Drawbacks All agents share one user, so one agent can read another's workspace. Agents can still reach the internet, so anything an agent can read, it can send out. For untrusted input, a remote sandbox or an agent in its own app (OpenClaw and Hermes Agent are already in the store) remains the better choice. An agent can still fill the disk. Board users can run any command in the app, so treat them as administrators. There is no SSO and no password reset until upstream adds them. Updates to the application (but perhaps not the package) will be frequent.

@girish : SOLVED ! I traced it to (1) the backup in cloudron update failing, triggering update to fail, which was totally caused by (2) my ultra-minimal minibase not having sqlite3 in it and I forgot to add it manually as the packager responsibility when going ultra-minimal. Interestingly I did not discover this in testing, because I was always ticking 'skip backup'. So your approach in the other discussion is proven out ! Ultra-minimal can work but it seems not wise, because darned packagers cannot be trusted . A slightly fatter base is worth it to avoid such mistakes. You win ! Will fatten my minibase while waiting for yours. Sorry for taking up your time again.

@robi neat idea !