More and more hostings appears with RPi with a very attractive pricing (8Gb RAM, 4CPU Cores * 2Ghz, 30Gb network HDD) for ~$15/month.

It would be also very handy for a private in-office use, for a more private use cases.

I currently do own a domain and run cloudron on a rented server, but I'm from Brazil and stuff is pretty bad here right now

We also have a thread on that.. search for "cheap vps" ..
my profile has a link to the affordable VPS servers I use.

I'll take a look.

I currently do own a domain and run cloudron on a rented server, but I'm from Brazil and stuff is pretty bad here right now, and it's starting to be a bit too expensive for my purposes.

I thought about hosting at home, but stumbled upon this problem. I'll take a look ad that thread and see what I can use. Thanks again!

Even if you don't have a domain, any subdomain provider will work, and I'm sure many of the forum members could offer a container that does just that on one of their subdomains if you don't already have one and a VPS.

1. As @girish said, there's not much interest in ARM servers, so it would be very low priority to integrate having different architectures into cloudron main code; and

2. I wanted to do this so I could host my cloudron at home, but since mos ISPs where I live won't let you expose port 80, 443, 25, etc., I lost interest in pursuing this.

If cloudron would support having nginx on custom ports, that would be cool for people wanting to host at home and with the same problem, but I think this is also not a priority now, as not too many people seem to be interested in this.

It's not too hard to make cloudron's install script work on a raspberry pi, though, but you'd have to maintain a fork, which was also not my interest at the time. If you want to, though, DM me and I can give you a few pointers.

Note: I personally have not used buildx yet, but from what I can see it's a simpler, automatic version of what I'm trying to do with qemu that handles the manifest for you. So I think you should just be able to build without the muckiness of all the build-args I pass, but if not you can play with mixing those in until it works.

I think buildx is supported on my laptop, so I can give it a try, but it's not supported on my CI box yet, so I haven't switched.

To give one simple example, any app using the go language, where we take the release builds, has to get some logic or separate Dockerfile to deal with arm.

I have some experience with this and have set up my own multi-arch go build pipelines using a single Dockerfile for some of my other apps: minitor-go, dockron, tag-checker, and for Python ones too: original minitor.

Here's a sample repo demonstrating my process: multiarch-pipeline-test. It's easier these days if your server has docker buildx though.

Also, since with Cloudron we're most often building things that exist upstream, here's an example multi-arch build repo I have for the Golang project cadvisor. It will auto build a particular cadvisor version on a git tag so I just need to create a release on my Gitea server and the build is started and deployed. With cadvisor, I have to clone the whole repo and cross-compile the cadvisor binary for arm becaue there is no pre-compiled binary. If there is, it should be even easier to just pull that binary.

Anyway, I'm happy to help if there are any applications that may be critical to be ported.

However the main reason we have not pursued this further is, that in order to support arm (arm64 to be precise), we have to rebuild all addon docker images for a start and patch up the code which creates addon container accordingly with different image tags and even once that is done, we then have to rebuild all app packages for arm as well, which means a lot of testing and potentially fixing apps upstream. This is a lot of work and this has to be done and tested for every app package update of course.

To give one simple example, any app using the go language, where we take the release builds, has to get some logic or separate Dockerfile to deal with arm.

I do think it is worth it in the long run to support arm, also because VPS provider start adding arm options and at least the raspberrypi 400 showed okish performance while I was doing the proof-of-concept, however we will need a different way to build packages and run the selenium tests for both architectures reliably. This is currently done manually by us due to the lack of such CI/CD pipelines in place.

So all this is certainly doable but unless we see higher demand, it is hard to justify the extra work and for the time being essentially at least double the work per app update.