this post was submitted on 16 Mar 2025
17 points (100.0% liked)

Selfhosted

45148 readers
1026 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Disclaimer: I am running personal website on cloud, since it feels iffy to expose local IP to internet. Sorry for posting this on selfhosting, I don't know anywhere else to ask.

I am planning to multiplex forgejo, nextcloud and other services on port 80 using caddy. This is not working, and I am having issues diagnosing which side is preventing access. One thing I know: it's not DNS, since dig <my domain> works well. I would like some pointers for what to do in this circumstances. Thanks in advance!

What I have looked into:

  • curling localhost from the server works well, caddy returns a simple result.
  • curl <my domain> times out, currently trying to inspect packets - it seems like server receives TCP without HTTP.
  • curl <my domain>:3000 displays forgejo page, as forgejo exposes at 3000 in its container, which podman routes to host 3000.

EDIT: my Caddyfile is as follows.

:80 {
    respond "Hello World!"
}

http://<my domain> {
    respond "This should respond"
}

http://<my domain 2> {
    reverse_proxy localhost:3000
}

EDIT2: I just tested with netcat webserver, it responds fine. This narrows it down to caddy itself!

EDIT3: (Partially) solved, it was firewall routing issue. I should have checked ufw logs. Turns out, podman needs to be allowed to route stuffs. Now to figure out how to reverse-proxy properly.

EDIT4: Solved, created my own internal network between containers, besides the usual one connecting to the internet. Set up reverse-proxy to correctly connect to the container. My only concern left is if I made firewall way permissive in the process. Current settings:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
3000/tcp                   ALLOW       Anywhere                  
222/tcp                    ALLOW       Anywhere                  
8080/tcp                   ALLOW       Anywhere                  
80/tcp                     ALLOW       Anywhere                  
8443/tcp                   ALLOW       Anywhere                  
Anywhere on podman1        ALLOW       Anywhere                  
22/tcp (v6)                ALLOW       Anywhere (v6)             
3000/tcp (v6)              ALLOW       Anywhere (v6)             
222/tcp (v6)               ALLOW       Anywhere (v6)             
8080/tcp (v6)              ALLOW       Anywhere (v6)             
80/tcp (v6)                ALLOW       Anywhere (v6)             
8443/tcp (v6)              ALLOW       Anywhere (v6)             
Anywhere (v6) on podman1   ALLOW       Anywhere (v6)             

Anywhere on podman1        ALLOW FWD   Anywhere on ens3          
Anywhere on podman0        ALLOW FWD   Anywhere on ens3          
Anywhere (v6) on podman1   ALLOW FWD   Anywhere (v6) on ens3     
Anywhere (v6) on podman0   ALLOW FWD   Anywhere (v6) on ens3

podman0 is the default podman network, and podman1 is the internal network.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 week ago (2 children)

What do you mean? I have only heard that phrase meaning not in a container or VM. But I am not a native speaker.

[–] [email protected] 2 points 1 week ago

Not in a VM is better usage - but "metal" refers to the hardware. Traditionally it's used for embedded devices - no OS. But containers run on the hardware / OS in exactly the same way that non-containerized processes do. They even share the kernel of the same OS. There is no way non-containerized processes run on "metal" any more than containers do.

[–] [email protected] 2 points 1 week ago (1 children)

The distinction is between bare metal and virtual machine. Most cloud deployments will be hosted in a virtual machine, inside which you host your containers.

So the nested dolls go:

  • bare metal (directly on hardware)
  • virtual machine (inside a hypervisor)
  • container (inside Docker, podman, containers, etc.)
  • runtime (jvm, v8, clr, etc) (unless your code is in C, Rust, or other such language)
  • your code
[–] [email protected] 2 points 1 week ago

Thanks for the clarification. So I go on bare metal, but probably in op case was not the case.

I have a real server at home and I rent a real server (which I often incorrectly call VPS).