Cloudron Forum

Description

I just migrated my entire Cloudron instance, and there were no problems.

You can, and should, close this ticket after basking in your kudos.

Steps to reproduce

1. I read the documentation for backing up and restoring Cloudron.
2. I followed the directions.
3. I migrated my instance from one machine to another.

Specifically, I'm locally hosting, and was very impressed with how seamless the process was. My backups were via SSHFS mount, so when I brought up my new machine, and uploaded the backup config, it happily mounted the backup and began the restore process.

I used the /etc/hosts trick to point to the new machine on the internal network, and when everything came up, I told my router to point to the new host as opposed to the old.

Absolutely wonderful. Thank you.

Logs

YOUR_LOGS_GO_HERE

Not this time!

The Absence Of Troubleshooting Already Performed

Just wanted to say how grateful I am for the work that goes into this. Thank you.

System Details

I moved from a Dell 7040MFF (bare metal) to a UGREEN NAS 2800.

1. I put Proxmox on the NAS bare metal
2. Built a VM on the NAS NVMe boot drive (this became my new Cloudron host)
3. I put a pair of 8TB drives in ZFS RAID1 (7TB usable), and mounted a 6TB virtual disk living on that ZFS filesystem to the VM as /home

This should put all of my Cloudron app data on the ZFS array. I backup over SSH to another machine with a similarly sized ZFS mirror.

Cloudron Version

9.0.15

Ubuntu Version

24.04.03

Cloudron installation method

Manual on a 24.04 Ubuntu Server VM.

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 just thought I'd mention a fun use of Tailscale, which I'm unreasonably pleased with, even though it was minimal effort to do.

To start, I have Cloudron backing up to a local SSD. It's an old 2.5" that has enough space for the host backups (which are... rsync format, I think).

This weekend, I took a an old, small machine (a NUC I accumulated from years ago), installed Ubuntu 22.04 on it, plugged in an old 1TB USB HDD, and took it to an undisclosed remote location. (Read: a family member's house.) I set up my fstab to mount the USB drive by ID, so it should always come up on boot. (I also remembered to set the machine's bios so it would come on after power failures.)

I then installed Tailscale on both my Cloudron host and this aging NUC. Finally, I set up my crontab on the Cloudron host to run rclone every now and then. It clones my backup (from the SSD) to the remote, undisclosed location over the Tailscale network.

This saved me a ton of time in terms of setting up a hole in the remote router (for a secure SSH connection), as well as worrying about whether or not I have secured SSH adequately. Granted, I'm trusting Tailscale to do the right thing here, but I figure it has a better chance of being secure than me quickly hacking things together.

Although it isn't a full "Cloudron using Tailscale" story, it is nice that the default Tailscale configuration is to leave all your public networks alone. As a result, the Cloudron host can be set up to replicate backups elsewhere very quickly and easily.

@andreasdueren I've packaged one or two things for myself on Cloudron, and I took a look at Frappe/ERPnext.

First, for the thread: Cloudron does not run Docker images "as-is." Or, if you prefer, simply because a project runs in Docker does not mean that it will immediately be runnable under Cloudron. A Cloudron app needs to be packaged up so that it will "play nicely" with the control architecture that Cloudron provides. Put simply, to get that friendly Cloudron experience, some work is needed when packaging an app.

In the case of ERPnext, it has a compose file that specifies many software services. Traefik is used for routing and load balancing (I assume); Nginx fronts the service; it seems like Frappe (the API backend) is written in Python (another service). There's worker processes of several flavors, a scheduling service, a Redis cache, MariaDB (which, for porting to Cloudron, we'd want to integrate with it's built-in DB add-on), the site creator service... and a large number of storage volumes.

Cloudron does not, to the best of my understanding, support running docker-compose files. As a result, to package this, we'd have to pull all of these services into a single container image. That would take some thinking, especially since Docker "likes" to have one process per container. Or, if there is another way/it is possible, I don't personally know how to package up a multi-container Cloudron application.

The Cloudron team may have something else to say, but I thought I'd drop a note in the thread that helps explain why this app is a more complex proposition than others (perhaps) when it comes to packaging. Yes, it is open, and yes, it installs easily on a VM when you do a docker-compose up. Unfortunately, that is not the same as packaging things up to run under the Cloudron framework.

I've started work on this, and will update this thread when I have it in a repo. That might be later today, it might be in another day or two. I managed to get:

1. A modified Dockerfile
2. A modified startup script
3. The image pushing to a (local) private repo
4. An install into my local Cloudron

And, at that point, I have more environment variables to set.

So, it seems possible/I'll make the work public shortly.

Hi @timconsidine , I know I won't have time to do a PR anytime soon, so I'll drop a note here. Huge kudos on bringing the package forward.

The Garage state is stored entirely in SQLite databases. I can't remember the names of them... there's 2 or 3? So while you've spec'd the directories where they will live, that's only part of what needs to be done with them for a restoreable Garage installation on Cloudron.

https://docs.cloudron.io/packaging/addons/#sqlite

You'll want to make sure they're explicitly called out in the manifest. Doing so makes sure they get baked up safely.

If you don't, it is possible that a backup will fail to correctly capture all of the metadata about the Garage instance, and the result could be lost data upon restore. (That is, if a WAL file is not flushed, then the standard backup might capture the metadata DB in an inconsistent state, and if someone had to restore, they would have a corrupt and unrecoverable Garage installation.)

I've eyed both

https://github.com/kanbn/kan

and

https://planka.app/community#strategy

as being potentially friendly to Cloudron packaging. kan.bn in particular just wants a Postgres database, which Cloudron happily provides.

feature statement

As a user, I want copy-paste to "just work" when pasting SSH private keys into Cloudron.

context

When setting up SSHFS, either for backups or volume mounts, a private key is needed. These typically have the form

-----BEGIN OPENSSH PRIVATE KEY-----
MULTIPLE/ASDFLAKSJDFLKAJASDFLKJASDF
LINES/ASDFASDFKLJASDLFJKSADFLKJASDF
OF/ASDFLKJASDFLKJASDFLKJASDFLJKASDL
BASE64/ASDFJKLASDFLKJASDLFJKASDFLKJ
DATA/ANDPADDING=
-----END OPENSSH PRIVATE KEY-----

As a user, I might be copy-pasting this from a number of places.

1. I might cat a private key on my terminal, and have to use a three-key sequence (CTRL-SHIFT-C) to copy
2. I might cat a private key in a web terminal, and have to CTRL-INS to copy (because that is how the web terminal is configured)
3. I might use Bitwarden/Vaultwarden, and have it generate a keypair for me. That key will then have a "copy icon" that I can click for both the public and private keys
4. I might use a web gui in another product (e.g. TrueNAS Scale) to generate the keys, and copy-paste out of a web text area

In each case, the way whitespace is handled may vary.

Further, it appears (based on skimming things on the web) that SSH defines the protocol, but there are not good definitions for how SSH keys should be stored. That is, the bytestream representation for communicating them between client and server is specified, but it is a bit up-in-the-air as to how they should be stored at rest.

On inspection, it looks like it is common for a MIME encoding to be used on the Base64 content. Base64 does not consider __ (that's a space) to be a valid character. Some encodings, like MIME, specify maximum line lengths, but the use of spaces/newlines/etc. as separators should be ignored.

https://en.wikipedia.org/wiki/Base64

(Apologies for not linking to authoritative sources/RFCs.)

the problem

Long story short: when I paste a private key into Cloudron, I am pasting a lot of text into a small text area. How whitespaces or linebreaks are or are not used once I hit "Save" or "Submit" is invisible to me as a user. However, it is clear that it has impact.

1. When I copy-paste and carefully preserve line breaks, it appears to work.
2. When I use Bitwarden, and copy-paste from an auto-generated keypair, it appears to fail.

replicating the error

1. Go to your Bitwarden install
2. Generate and save an SSH keypair
3. Copy the private key
4. Create an SSHFS volume mount
5. Paste in the private key
6. On another system, add the public key to the authorized_keys file
7. It should fail.

It is also possible that there is some kind of subtle user error taking place; however, I'm uncertain where to look in my Cloudron instance to debug this under the covers.

what i want as a user

I want things to "just work."

In this case, I would like Cloudron to either:

1. Warn me my key is not well-formatted, or
2. Make a best effort to format the key appropriately behind-the-scenes

If I paste something like this (the Bitwarden example):

-----BEGIN OPENSSH PRIVATE KEY----- MULTIPLE/ASDFLAKSJDFLKAJASDFLKJASDF LINES/ASDFASDFKLJASDLFJKSADFLKJASDF ... -----END OPENSSH PRIVATE KEY-----

with whitespaces instead of newlines, I expect Cloudron to write it to disk replacing my spaces with newlines, so it becomes:

-----BEGIN OPENSSH PRIVATE KEY-----
MULTIPLE/ASDFLAKSJDFLKAJASDFLKJASDF
LINES/ASDFASDFKLJASDLFJKSADFLKJASDF ... 
-----END OPENSSH PRIVATE KEY-----

if that is necessary to "make it just work." Or, I expect it to complain, and tell me the format is invalid. Either way, I don't want to be able to paste a key and then have SSH failures that are inscrutable. (SSHFS mount failed for unknown reason, or whatever the vague error case is.)

other solutions I'd think work for me as a user

I'd also be happy to:

1. Have Cloudron generate the keypair for me, and let me copy the key(s) (pub/priv) to my local machine. Or, you could put them on a page and say "copy these and don't lose them." Either way, if you control key generation, you guarantee that I can't mess them up. (Or, if I mess them up elsewhere, that's my problem, not yours).
2. Upload a file for the key. It would be OK if I uploaded the keyfile. This way, I can inspect it on disk, and the upload process won't (shouldn't?) mangle the file en route.

The spirit here is that I'm excited about anything that doesn't have invisible errors.

fun find

https://superuser.com/questions/1444319/how-to-check-ssh-key-version-locally

You can do

ssh-keygen -l -f <file>

and if it is a valid pub or priv keyfile, it will spit out

<bits> <SHA> <comment> (<type>)

which may be a good check to add to the backend after writing the key. Then, you could either get a valid SHA, or you could say "Could not generate SHA of SSH key; see <docs> for more info."

side note: types of key

Some (probably poorly written) systems only accept RSA keys (vs ED25519, etc.). This probably has to do with OpenSSL version(s) that are installed.

If there are any known limitations to Cloudron's use of pub/priv keypairs (e.g. "Cloudron can only use RSA keys up to 2048 bits"), then that should be communicated to the user up front. I think Cloudron is fine with any valid kind of SSH key, but that would be invisible to me at the moment.

2FA with authenticator apps are, by-and-large, all using TOTPs (https://en.wikipedia.org/wiki/Time-based_one-time_password), and therefore are effectively standardized. Whether you use Google's Authenticator, Authy, FreeOTP, Keepass, Vaultwarden, or something else, it doesn't matter. Or, if you find a provider where it does matter, you might want to be concerned.

https://alternativeto.net/software/google-authenticator/?license=opensource

You can also, in many 2FA contexts, use a hardware key.

https://www.yubico.com/

which have some added benefits (and drawbacks, mostly "it's a thing you can lose). Or

https://www.crowdsupply.com/sutajio-kosagi/precursor

if you really want a serious bit of kit from an open-and-secure perspective.

In short, and with kindness: I think you're searching for a boogeyman where there isn't one. I want 2FA on every account that matters to me, and I especially want stronger authentication frameworks in my software supply chain. I want 2FA on my bank accounts, I want 2FA on my email... really, I want something that goes beyond a single, salted/hashed password everywhere.

I'm not saying you shouldn't want to self-host your code on your own stack, and only use the most libre of free software. However, I think worrying about TOTP/2FA is like worrying about the "forced" transition to HTTPS everywhere. It's actually a good thing, and it isn't a "give us all your information" play. 2FA is a smart thing to do.

That said, I'm not keen on biometrics as a second factor.

@Neiluj

I would welcome input from a member of the team on this.

Docker is intended to run a single process in a single container. When you want to run multiple services, you run multiple containers.

This is where you (typically) would use some kind of tool to orchestrate or compose those containers. For example, a docker-compose.yml will define a set of services, and how they connect and interact with each-other.

Cloudron is designed to host singleton containers. Unlike industrial-scale platforms as a service, it provides limited tooling for how to define connections to other services. The manifest allows you to connect to the services that exist; for example, I can say "connect to the Cloudron-provided Postgres server." However, I have no way to say "I have chosen to run an S3 server/Minio at location X, and please use it." As a result, it puts a significant burden on the user. Further, there is no way within the package to say "this should not boot if that service is not present." You have to write custom code in order to provide that logic.

Further, the Docs app itself wants to run multiple services. The frontend is separate from multiple backends in their design. The app itself has orchestration concerns and considerations.

So while I appreciate people saying "but it is all there!," we're not discussing what is required to make this a production-grade package.

1. You have to pull the codebase.
2. Study how it wants to be run, and decide how it can be run in Cloudron.
3. Write a custom build/containerization script for the app, compressing multiple services (that want to be in multiple containers) into a single container.
4. Write custom code to make sure external services that are not part of the Cloudron PaaS are present, and fail gracefully/in a way that a non-expert user can debug, so that they can add those services and connect them to the app.
5. Make this all automated and testable.
6. Maintain all of this while upstream rapidly evolves.

I'm forgetting things, I'm sure. I estimate 80-120h of work in this, and it is essentially devops work. It should bill at $85+/hour. Further, I'm notorious for underestimating how long it takes to develop features by a factor of 2x-4x. So, I think this is work worth at least $8K-$12K---to say nothing of having to maintain the package, against a large, fast-moving target. (And, while it is open source, governments tend to be very careful about accepting changes from third parties, because there are significant security and compliance burdens they must bear.)

Maybe I'm just accustomed to deployments in Ansible and Terraform, and am overstating the difficulty of this deploy. However, my experience is that when a system is designed to run one way, and you want it to run some other way, there's significant work involved.

So, in return, please forgive my ignorance. I may be misunderstanding things about packaging for Cloudron, and you may be right: this may be easier than I think.

I've started poking at a package for Planka to refresh myself on packaging, because it is a singleton Node app that only has Postgres as an external dependency. It is an example, in my mind, of an app that fits the Cloudron model perfectly. However, anything that wants orchestration beyond the core services Cloudron provides---especially when some of those services are custom components internal to the application itself---is, in my mind, significantly more effort.

Hi @scooke ,

To your question, I followed the instructions on the Garage website, and I added a near-copy of that documentation to the README in the package I've developed. This is all documented in the git repository for the package that I linked to. I have Garage running on my Cloudron instance, and was able to create buckets, add content, and even serve static web content from within those buckets. I'm sorry your prior experience with this did not work for you.

I am now trying to do that in a way that it would be considered for inclusion as a standard package, if the Cloudron team thinks it is worthwhile. If they don't, perhaps I'll do it for myself.

I started work on a package; this was under a different thread, but it is probably more appropriate to mention here:

https://forum.cloudron.io/post/116583

For anyone poking the package...

I was unsure how to change the password for the default user. Some digging around yielded the following...

1. I had to generate a password hash. Log into the terminal for the app and run:

htpasswd -bnBC 10 "" PASSWORD | tr -d ":\n" | sed 's/$2y/$2a/' && echo

replacing the word PASSWORD with your password. I used a long combination of words and numbers with no spaces. This will output a bcrypt password hash:

$2a$10$GpIUtD/NDyfpVkQuaVfDde7M5SjcHdcmN9e49kFlgoeVsmMnrQ0wm

or similar. (Don't use that one.)

2. Log into the terminal, and open up the Postgres prompt.

update user_account set password = '$2a$10$GpIUtD/NDyfpVk...' where email = 'admin@cloudron.local';

Again, put your password hash between the single quotes.

Now, you can log in as the administrative user with the password you hashed.

3. Log in using your SSO/Cloudron user.

I think a package update might be needed. The OIDC users do not have any privileges out-of-the-box.

https://github.com/plankanban/planka/issues/661

It might be setting OIDC_IGNORE_ROLES would allow OIDC users to create boards. There might be more env vars necessary, but that one seems critical. It seems like the administrative user cannot (out-of-the-box) modify the roles for OIDC users (https://github.com/plankanban/planka/issues/1112). Again, that env var may be part of the puzzle.

In the meantime, I again opened up the Postgres prompt, and did:

SELECT * FROM user_account

I found my username (which was my expected Cloudron username, so it was easy to find/there were no surprises), and then modified that row to give myself more permissions:

UPDATE user_account SET role = 'projectOwner' WHERE username = 'MYUSERNAME';

This gave me enough permissions to do things.

My hope is that if the right env vars were set, that I would not need to grant my OIDC users permissions via the admin user.

@girish Hi Girish. You got it.

I have a small IoT service hosted in the home network that adding auth/protection to would be painful. (It doesn't have a notion of auth, I don't think. So, Cloudron-as-LDAP-authority doesn't even save me.) The App Proxy feature made it easy to bounce through to it from outside, but I don't want it unauthenticated.

So, yes. You nailed exactly what I was wondering.

summary

Garage is "an S3 object store so reliable you can run it outside data centers."

Given that the open source version of Min.io recently went into maintenance mode, it feels appropriate to have another S3 option on Cloudron.

I think I have a more-than-proof-of-concept, but not-ready-for-production package for Garage. I'm starting this thread here so there is a place to discuss what would be necessary to bring it into readiness for a "real" Cloudron package.

related posts

• https://forum.cloudron.io/post/116583
• https://forum.cloudron.io/post/116585

building the package

1. Check out the repository (https://git.jadud.com/jadudm/cloudron-garage)
2. export DOMAIN=s3.example.com
3. make install

(If the package has value, I'm of course happy to see the git repository move.)

The build relies on the value of the environment variable DOMAIN; it will be easiest if you set that variable in the shell before running make. Within the Makefile, the cloudron tool is run; it is assumed you have this tool installed, as well as the ability to push/pull from a registry.

I cannot provide support for people who have not set up their development environment for Cloudron packaging.

alias domains

The installation will set three alias domains for this site. If you installed at s3.example.com, then it will set:

• admin.s3.example.com
• api.s3.example.com
• *.web.s3.example.com

NOTE: These sub-sub domains are likely not covered by a certificate. It may be that the installation would rather create aliases like api-s3, admin-s3, and so forth, all off a root domain.

inside the package

The package launches two services:

• caddy
• garage

Garage is a single Rust binary, but serves on ports 3900, 3902, and 3903. (Verdict is still out on 3901.) These appear to be "secure by default" ports, in that nothing comes back on any of them without valid credentials (API keys). That said:

https://admin.s3.example.com/health

should be a valid health check. Because this is the only valid health check, the caddyfile sets up a respond directive for api.DOMAIN, admin.DOMAIN, and DOMAIN so that /health works on all three domains.

It might be that caddy would be unnecessary if the manifest's healthCheckPath worked differently. The solution here was to proxy inside the container.

what is that wildcard domain?

Garage can expose buckets as static websites. In this way, it might be possible for users to:

1. Upload static content to a bucket
2. Add an alias to this package
3. Add a redirect to the caddyfile
4. Profit!

(That's an old internet meme.)

Using a wildcard alias works, given that Cloudron passes the alias value straight through as a DNS A record. Therefore, it is possible to proxy everything that comes in to *.web.s3.example.com, add a rule to the caddyfile, and... it should work? In testing, I was able to confirm that buckets would serve content; I did not try layering a new domain on top, but believe it would work.

The caddyfile is in /app/data/, and therefore will be backed up. This should mean that changes there would persist on a backup/restore.

what works, what doesn't?

The package seems to come up, and I can follow the instructions in the README to

1. Create layouts, buckets, and keys (using the garage command, in the terminal for the app)
2. Access the buckets using mc (Minio Client) to ls, cp and so on
3. Declare a bucket to be a website, and serve content from it

I have experimented briefly with the Administrative API; it works. It is likely in this version of the package it does not, as I just noticed that I fail to actually set the admin_token. So, that needs to be fixed. (Or, perhaps it is being set... but, it's random.)

what needs to be done?

1. Backup and restore. I have not yet tackled this. At /app/data/meta/db.sqlite is the metadata for all of the block storage in the S3 instance. This needs to be handled with care. Failure to care for this DB likely loses all of the data in the instance.
2. Migrations. See "Backup and restore."
3. Enable the key/value store. This is probably easy, as it is another service at port 3904. It will be a proxy value in the caddyfile and a possible alias.
4. I don't know how/if aliases can be defined in the manifest. It would be nice.
5. ... ?

W.R.T. #4: I can't use httpPorts for the wildcard subsubdomain... but, I'd rather not have to tell users it's a step they have to follow. Should the manifest support adding alias values? If so, could the manifest support things like *.web.CLOUDRON_APP_DOMAIN? I don't want everything appearing on the root domain of the Cloudron instance by default; I want things to appear under the domain provided by the user.

Someone more familiar with packaging Cloudron apps would be able to answer better than me. However, I find that whenever a docker-compose.yml is involved, it is probably hard to move the app to Cloudron.

https://github.com/AppFlowy-IO/AppFlowy-Cloud/blob/main/docker-compose.yml

In this case:

• It wants nginx. That might be avoidable, or it might be serving static assets/code for the app.
• It wants minio. This could probably be accommodated by requiring users to run minio on their Cloudron before installing this.
• It wants postgres, which might be able to be leveraged from the internal stack.
• It wants redis. Again, possibly from the default stack... I can't remember.
• gotrue is an auth component from supabase. This will need its own container, and may (or may not) play nice with the SMTP/OAuth running on Cloudron.
• appflowy_cloud is the hosted app. It wants its own container, and configuration information for all of the services included.
• admin_frontend has its own Dockerfile. I haven't looked. Looks like more things.
• ai. I have no idea. It looks like it wants some kind of OpenAI. This is getting heavy in terms of resources.
• appflowy_history is... another Dockerfile. Looks like a rust application that has been Dockerized.

The problem, I think, is that Cloudron assumes/is structured such that applications run as single containers. The compose is suggesting that this application has a number of independent components. Perhaps those could be bundled up/run separately... but, it might be a real trick to make work.

This isn't to say it isn't possible, but that's what I see that needs to run, and it isn't clear to me that this is an easy app architecture to move over to Cloudron. YMMV, etc.

Not much I can do with that statement. I have it packaged and working. I'm now in the weeds of how best to handle data backup and restore on Cloudron. Given that the Minio package must go away, this is at least a possibility that can be evaluated.

Looking at the Docker Compose, this one is actually a very clean/light app.

1. The license is the GNU Affero, so there should be no licensing issues.
2. The Dockerfile is small, and basically a node app.
3. The docker-compose.yml is actually simple! It spins up the image for Planka, it has a whole bunch of environment variables (commented out as documentation, mostly), and it expects Postgres as a database.
4. It has a backup script!
5. It has an active repo and community!

I'm... in a rather tough spot in terms of time, but this feels like a good packaging target. @girish , @nebulon , is this app one that you would want to see in the app store? (To me, that's an important first question.) If so, do you have additional requirements (e.g. tests, automation) that you would want to see in place?

I would ask, for simplicity, that you require the developer to put the JSON in a fixed/predictable path, and allow the user to paste the URL for the main GH repo. Asking users to find the "raw" link is likely hard/confusing. Put the onus on the person packaging, not the person installing?

Agreed. I'm not offering thoughts from a spirit of "GIVE UP!," by any means. It is more from the perspective of "I think this one is trickier than it seems at first glance."

But, I am still learning. So, the staff may say "this is actually easy!" Or, they might say "Yep, it's kinda tricky." And, as a result, we all learn more.