@girish Glad to serve. If the goal is an addon, then... I think the backup piece should be straight-forward? (I have some more info in the packaging thread about this.) Essentially, you want to make sure the SQLite DB is backed up, and then you backup the filesystem. I have questions about what happens if (say) a restore happens (e.g. what if the filesystem path changes?), but those things can be explored. There is an administrative API that (once you generate a secret/trusted admin API token) lets you do everything administratively via that API (bucket creation, etc.). As to a web interface, I would not recommend you create one for end-users. (I suspect this is not what you mean.) You have NextCloud, XBackBone, and other apps that can talk to an S3-compatible backend for file browsing. What people might need/want is a way to: Create/remove buckets (which, on the backend, you'd use your secret admin key) Create/remove keys and attach them to buckets Create/remove administrative keys (for superusers who want to script things against the backend) Bonus: the ability to designate a bucket as a static site, and then you do the DNS work on the backend to point either a subsubdomain at it (e.g. site.s3.example.com) or a whole new domain (e.g. someothersite.com -> site.s3.example.com) I suspect you could iterate towards this, if you wanted to. Release it with terminal-only management to start, and work towards an admin interface for common bucket creation/removal-type tasks. There are things that Garage does not do (e.g. lifecycle rules), so this is not a "full" S3 clone (the way Minio aspired to be). ~~In this regard, SeaweedFS might offer more features (and a built-in admin UI)... so, it might be worth doing a spike to explore it as well. At a glance, it is similar, but it also is intended to scale (e.g. it does Raft consensus and Reed-Solomon EC if you want it) in a way that Garage does not. This might also be a reason to not use Seaweed. I can poke it with a stick if it would be valuable~~. Update, a few hours later: I would recommend sticking with Garage.

@composer nice. you compared to Element recently? any deal-breaker differences?

Good point. It would actually be helpful if apps with such licenses were explicitly marked in Cloudron, or if there were a setting/flag for reseller environments to warn about license restrictions before installation.

The library is also usable in nextcloud: https://github.com/nextcloud/whiteboard/blob/main/README.md I use it (not in cloudron) with a simple docker-compose: services: whiteboard: image: ghcr.io/nextcloud-releases/whiteboard restart: always # ports: # - 3002:3002 environment: - NEXTCLOUD_URL=https://your.nextcloud.url - JWT_SECRET_KEY=KEYsome-strong-one

https://forum.cloudron.io/topic/9857/webtrees-web-based-family-history-software?_=1765106819684

Webtrees was a great suggestion for genealogy way back then and today it stands as the most active and fully featured project amongst its contenders. Here is a quick ai summary: Strongest Fully Featured Alternative with Most Active Development Based on the latest metrics as of December 7, 2025, Webtrees stands out as the strongest fully featured open-source genealogy program among the alternatives (Ancestris, Webtrees, GeneWeb, and Genea.app), particularly when prioritizing both comprehensive features and the highest level of ongoing development effort. Here's a quick rationale, followed by a comparison update incorporating fresh data. Why Webtrees? Fully Featured: It rivals Gramps in depth, supporting full GEDCOM import/export for seamless data migration, advanced editing (individuals, families, sources, media like photos/documents), privacy controls, interactive charts/maps, and real-time collaboration—making it ideal for both solo researchers and shared family projects. Unlike lighter tools, it handles large trees with database-backed storage and media merging during updates. Most Work Happening: It shows the highest momentum with 676 stars, 332 forks, and over 20,777 total commits on GitHub. The last commit was just yesterday (December 6, 2025), with frequent updates in late 2025 (e.g., PHP 8.5 compatibility fixes and translation enhancements in November/December). This indicates a vibrant, multi-contributor ecosystem (historically 100+), far outpacing the others in visible activity and community engagement. Edge Over Others: While Ancestris is a close second for desktop users (recent v13 release on Nov 30, 2025, with 1,200+ commits in 18 months), its SVN-based development lacks the transparent, high-velocity GitHub metrics of Webtrees. GeneWeb is steady but dated in interface and metrics (363 stars, no recent commit details). Genea.app lags with minimal activity (245 stars, sparse updates). If you prefer a pure desktop experience like Gramps, Ancestris is nearly as robust and actively maintained—but for overall strength and dev hustle, Webtrees wins. Updated Comparison Table (Dev Effort Focus) Alternative Fully Featured Highlights Dev Metrics (Dec 2025) Activity Level Webtrees GEDCOM/media/editing/privacy/collaboration/charts 676 stars, 332 forks, 20,777 commits; last commit Dec 6, 2025; daily updates Highest: Frequent commits, broad contributor base Ancestris 30+ tools (editors/trees/maps/analysis); modular/GEDCOM v13 release Nov 30, 2025; 1,200+ commits (18 mo.); daily v14 builds via SVN High: Steady releases, community forums GeneWeb Database mgmt/conversion/plugins; web/offline 363 stars, 111 forks, 9,894 commits; active mailing list Moderate: Consistent but slower pace Genea.app Visual GEDCOM editing/Git sync; serverless 245 stars, 56 forks; limited recent commits Low: Small team, infrequent updates For setup, Webtrees is self-hosted (easy with Docker) and free forever. Dive in via GitHub or site. If this doesn't fit, clarify your priorities (e.g., desktop vs. web)!

Yep. There's multiple alternatives. When/if they're appropriate as a drop-in for Minio and (for packagers) as an extension, there's more than one path. Looking only at things that seem to be "live"/viable: Service URL License Notes Garage https://garagehq.deuxfleurs.fr/ GNU AGPL EU-based, compatible with many common clients, might serve as a static site/fileserver as well SeaweedFS https://github.com/seaweedfs/seaweedfs Apache 2.0 Can run as a single binary; can grow its storage area by adding to a list of paths (which would play well with Cloudron's volume mount model) VersityGW https://github.com/versity/versitygw Apache 2.0 Essentially proxies S3 straight to the filesystem, allowing access to files either through the S3 API or directly through the underlying filesystem. (Sounds easy to backup.) RustFS https://github.com/rustfs/rustfs Apache 2.0 Explicitly supports a single disk/single node deployment, but it looks like it wants direct access to disk mounts. Ozone https://github.com/apache/ozone Apache 2.0 Apache Foundation object store project. Handles HDFS and intended to scale. Not really appropriate for Cloudron's use-case. Garage and/or Seaweed are likely the most mature of this bunch. Versity might be the simplest. the start of a package After looking at the Garage repo, it was apparent that it should be very packageable. All the right things are broken out as environment variables. https://git.jadud.com/jadudm/cloudron-garage I was able to: Push this to a private registry I'm hosting on my Cloudron Use the cloudron build and cloudron update sequence to make changes and improve it on my Cloudron instance Use the terminal to create a zone/location, assign it some space, and create a bucket Create a key for that bucket Use mc (minio client) to put a file in the bucket and list the contents of the bucket There's a bunch more that would need to be done. A few thoughts, mostly random: The SQLite metadata needs to be backed up correctly. It might be that I've already done everything necessary by using localstorage and pointing it at that metadata DB. I used httpPorts to map almost all of the endpoints that are supposed to be public, but... I'm not sure I wired everything up correctly in the config. Something was right (since I could use the API), but I did not test (say) the admin API, and I did not expose the K/V database API. (Which... could be handy to expose.) The docs say httpPort is optional/not required, but the command line tools disagree. The docs should be updated. I didn't try and play with SSO, but I don't know if I have to? Or, there's a bunch to think about there. I think garage is kinda secure out-of-the-box (with no keys configured by default, etc.), but that doesn't mean I'm confident. As a result, perhaps SSO isn't necessary? I did not experiment with exposing anything as a web page. The notion that I could push to a bucket and use that as a static site server (as opposed to creating surfer instances, say) is compelling. But, I'd have to figure out how to map the domains... If this is a direction things go, I'd be glad to be a sounding board/help out. Because this is really about Garage, not Notion/etc., I'll continue commenting here: https://forum.cloudron.io/post/116584

I'd be interested in this

Is it time to bring this to CCAI? @andreasdueren @timconsidine

With 49 upvotes, this seems to be a killer feature in Cloudron. What is the current status of efforts in this regard?

Can we get this in CCAI?

Should this be added to CCAI? @timconsidine ? Any updates @kubernetes ?

@timconsidine you are welcome. You can always test on the demo server. And at least the second issue is easily solved via an expected version bump or just take out the check. Not sure why it's needed. Is it?

Wow what a major rebrand, we need this indeed, as RC doesn't cut it.

@micmc said in Super Productivity: Offline I guess it has the option to sync via webdav. So it's like the ntfy frontend, it's all public but very limited in functionality.

I wrote a small script so I can monitor the HPB (turn) backend. Because if it fails, it breaks Nextcloud talk. Posted here in case anyone else wants to easily monitor his turns server. The cron job runs it once a minute. Each run generates REST credentials from the static auth secret, calls turnutils_uclient to allocate on the TURN server, and then sends a push event to Uptime Kuma containing either TURN allocate succeeded or the last error line from turnutils_uclient. So Kuma sees “up” whenever the allocate completes successfully and “down” when it fails.