This is correct, only the Cloudron version is relevant in this case

@CBCUN It's in our TODO list. I don't have an ETA yet.

@girish Oke feel stupid. That worked, thank you.

I’m using Tailscale IP, so all traffic is going via the tunnel. My assumption is that it doesn’t matter if it’s not encrypted as long as I use the Tailscale tunnel? 😶‍🌫️

In case, anyone is using borgbase, they seem to be having a big outage. Possibly down for a week already.

https://status.borgbase.com/status/default

I found out from https://news.ycombinator.com/item?id=37115540
image.png

robi said in [Guide] Auto Deploy of Hugo via Gitea + Drone CI:

how this could all run from the same cloudron

It already could. Drone's runner (would be the same with Gitea or Woodpecker) is a simple go binary that just needs access to a local docker socket. It's just me running jobs on my installation, so there's no risk of exposing data to others by accessing the Docker socket.

And if you're serious about CI, you'll want optimised machines anyway (building in a ramdisk ftw), not running your CI jobs where their resources are competing with Wordpress & co. Being a simple binary that doesn't hold any local data also means you don't need to back up your runners, and since they access a central node, they don't even need internet access.

If you want to save costs, you can even let your developers run the runner on their local machines.

You could also use rclone together with mergerfs to create some kind of layer.
like
/mnt/remote
/mnt/local
/mnt/mergerfs

You then write stuff locally, and it'll upload stuff in the background to your remote storage.

You can look for inspiration @ https://github.com/l3uddz/cloudplow

Some tar - streaming would help with all the small files.

@imc67 geo-block feels like a more feature-rich solution, that might be of help, but not exactly my cup of tea.

I would guess, that Cloudflare doesn't prevent anyone from accessing your web service directly (should they figure out the IP address, for example, via e-mail you've sent)?

Guess CentOS / RedHat is out of consideration now... 🙂

That is fixed https://forum.cloudron.io/topic/9625/branding-bug

@LoudLemur said in icedrive as backup solution?:

How would marking the bucket on idrive e2 as private rather than public effect usage with applications on the Cloudron?

With object storage, public buckets mean it's accessible via HTTP to anyone.

Some people use it to host web assets or even entire static websites.

Moving forward, what would be a good backup policy be to prevent this issue from occurring in the future?
Should I just get seed boxes and sync directly from there to my local machine?

@LoudLemur I find rsync too slow with zilions of small files. You'd think it would be quicker as incremental, but large compressed files are beating many small files, same for storage space, compressed significantly less storage costs.

good point, I will remove them from the 1-click area in our install page

@robi Next to the likes of WordPress and cPanel - Cloudron has come such a long way! ❤

ok. will work something out.
thanks

@LoudLemur (Going by the topic subject), if the error is related to PTR record, then the solution is not correct.

The PTR record is set by your VPS provider and not by your DNS provider

PTR record goes by many names - Reverse DNS, rDNS, PTR. Unlike "forward" DNS which looks up something based on the domain name, a "reverse" DNS looks up based on the IP address. And who owns the IP address? The VPS provider. So, you have to change it there.

This means that to fix PTR record issue, you have to fix this in SSDnodes and not in Porkbun or whatever name server you have. If SSDnodes, does not let you set PTR record, you have to ask them by raising a support ticket.

More information at https://docs.cloudron.io/email/#ptr-record