Cloudron Forum

I will mark this as solved, but please open a new topic with the crash report.

@susankhanal said in cloudron not accessible using domain name outside the network:

doing curl my.domain.com gives HTML lines from inside the network but doing curl outside the network it says unable to connect

Before debugging further, I would double check the HTML output. Can you check if that looks like Cloudron dashboard code?

Also, is my.domain.com resolving to an internal IP or an external IP?

If it is resolving to an external IP, then most likely port forwarding is not working properly in the router.

I wanted to let you know how I got everything to work, it might help other users.

The initial issue was about DNS resolution. The quick fix is indeed to use the forward-everything option in unboud but with the previously used dns server. To find that value you just need to do a resolvectl and look at the value of the Current dns servers. In my case it was 10.0.2.3 (the one that was linked to my vpn on the host machine of the server). That is enough to fix the installation script losing internet.

For the Configuration error: Domain resolves to ["XXX.XXX.XXX.XXX"] instead of IPv4 XX.XX.XX.XX the quick fix in my case (home server not directly exposed to the internet) was to install an openvpn server on the vps server (https://www.cyberciti.biz/faq/ubuntu-22-04-lts-set-up-openvpn-server-in-5-minutes/) and an openvpn client on my home server so that my home server gets the vps's IP address. In this setup you I also need a reverse proxy to expose the 80 and 443 ports from the home server to the vps.

I don't think there is any backup option out there which can do what you are hoping can be done. The one exception is if you are manually extracting the data to be restored, and putting them in different locations. I just say this so you don't go feeling like this is some sort of weakness of Cloudron. Backups rely on timestamps and exact conditions. You couldn't restore the second backup because it would look for the time slot from which it was built, in the records, and those records aren't going to be in the currently restored backup. But if it is the media you want, then the fact you do have separate sets of backups does mean you can at least navigate through the backup and find that media, and then as @nebulon said, manually add them back to your Mastodon. But I gotta say, why do you need to have this media? I mean, Mastodon IS social media, and it's meant to be ephemeral. If there is some info you like, then screenshot it, or click the link and bookmark it, print it out to PDF, or follow the poster (to then check them out post-restore to see that specific post) etc. But saving it and keeping it to be viewable only within your Mastodon seems like a use even Mastodon wasn't really meant for.

Anyway, good to hear you are back up and running. Hope the new year remains happier. I'm @shane@social.futurnumerique.com if you want to expand your follow/followers!

Hi @JOduMonT,

I ran Cloudron with a combination of Tailscale & Cloudflared for two weeks without a public IP at my home setup. So far, everything was working well and I didn't encounter any significant issues. Below is the process that I followed:

1# I had two servers - one for Cloudron and the second with docker and docker-compose. Tailscale was installed and configured with Tailscale IP on both servers. The automatic domain configured was disabled in Cloudron and was set manually.

2# I ran the docker-compose.yml file on the second server using the following:

version: '3.8' services: tunnel: image: 'ghcr.io/shmick/docker-cloudflared' container_name: tunnel hostname: tunnel restart: unless-stopped user: 1000:1000 env_file: - $PWD/tunnel.env volumes: - /etc/timezone:/etc/timezone:ro command: tunnel run network_mode: host TUNNEL_TOKEN={TUNNEL-TOKEN}

3# I set up and configured the domain in the Cloudflared UI, and used HTTPS for the Cloudron Tailscale IP with No TLS Verify enabled.

@nebulon Hi!

Yea, everything is working great when hitting the server from outside my network. Your hosts file suggestion is a good one and is something I've done before. I'll dig into that. I seem to remember coming across a bit more of a graceful solution that handles internal/external requests. Thanks for jogging my memory!