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)!

update I've poked the package with a stick, added more to the README, and have run into a few interesting things about this package. s3 functionality I was able to create a bucket and put stuff in it. This seems to be a core function of an S3-compatible object server. administrative server Garage has a notion of having an administrative API at one port. I can use httpPorts to bind this port, and I can use it. For example, if I have s3.example.com as the root domain, then admin.s3.example.com can be the home for the Admin API. And, I was able to create an administrative API token, and using it, access the admin API. static websites This one is tricky. In theory, if I configure part of the garage.toml correctly: [s3_web] bind_addr = "[::]:3902" # This wants to be set dynamically in the startup. # That way, it can grab a Cloudron variable. root_domain = ".web.s3.example.com" index = "index.html" I can serve static sites out of buckets. However, this implies domain name manipulation. And, possibly, a wildcard. As in, I'd like *.web.example.com to resolve to s3.example.com, and for Garage to pick it up (internally) on port 3902. I have explored this manually (by manipulating DNS settings in Cloudflare), but even though I have configured a bucket to serve static content, I can't (yet) convince it to serve something up. While it might be that this functionality has to be sacrificed, I think it would be a nice way (if it was baked in) to manage 100% static sites. However, that would be new machinery: a way to map domains to buckets. backups I'm not convinced the backups are good. Specifically <path>/meta/db.sqlite is the metadata database for the Garage instance. This is, as far as I can tell, all of the information about where all of the files is stored. Losing this database is tantamount to losing all of the data. I think. So, making sure it backs up correctly matters. And, it is clear that updates will need to do things like garage repair and garage migrate, in the event of migrations/changes to this metadata database. Ah: Since Garage v0.9.4, you can use the garage meta snapshot --all command to take a simultaneous snapshot of the metadata database files of all your nodes. This avoids the tedious process of having to take them down one by one before upgrading. Be careful that if automatic snapshotting is enabled, Garage only keeps the last two snapshots and deletes older ones, so you might want to disable automatic snapshotting in your upgraded configuration file until you have confirmed that the upgrade ran successfully. In addition to snapshotting the metadata databases of your nodes, you should back-up at least the cluster_layout file of one of your Garage instances (this file should be the same on all nodes and you can copy it safely while Garage is running). (Emphasis mine.) So, the backup process is something I'll need to investigate further. It might be that some manual/scripted management of this database file---and dumping it---is going to be a bit of a thing in terms of having it be a robust process. (Given that Cloudron does backups before upgrades, as long as the SQLite DB is snapshotted correctly on backup, I think it will be fine.) I suspect that a cron will need to be installed for this package that---daily?---runs the snapshot command, rotates DBs, and those are part of the backup. (I have a suspicion that Cloudron packages handle this kind of thing in the start.sh scripts?) healthcheck URL The manifest assumes that the health check URL is on the main app. In this case, if I have s3.example.com and the Admin API is at admin.s3.example.com (defined in httpPorts), I want the health check URL to be https://admin.s3.example.com/health because that is where Garage put it. I don't think I can do that with the manifest as-designed. summary I think the package is off to a good start. I have questions, but most of them are described above, and I'll probably figure things out. The health check and static site subdomains, though, might not be easily solved.

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

Hashicorp (now IBM) Vault (and all other Hashicorp products such as Terraform) e.g. has a similar license, the BUSL. Other examples with similar licenses are MongoDB, Kibana, Elasticsearch, Redis… Here’s a good overview: https://www.goodwinlaw.com/en/insights/publications/2024/09/insights-practices-moving-away-from-open-source-trends-in-licensing

@timconsidine As part of maintenance, there are database migrations that are part of the update process. The more complex the update process, the more likely there will be issues.

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.