[bayindirh]

Because some of the applications are "container native" and do not support configuration of IP/Port binding. Why? UNIX philosophy and working traditions be damned.

Exhibit A: Docmost: https://docmost.com/docs/self-hosting/environment-variables

I can understand the reverse proxy, but I want to run thing on a small VPS or a Raspberry Pi, etc. I want to use minimum resources so I can run more things per server.

If this thing was being installed at work, I can build a great wall in front of it, but for personal things, I rather have less moving parts, and just deploy and forget the thing.

[sofixa]

> Because some of the applications are "container native" and do not support configuration of IP/Port binding. Why? UNIX philosophy and working traditions be damned.

I'm not sure I follow. Docmost runs in a container, on a port which is configurable. By default, as all containers, that port is local to the container. The container orchestrator (be it docker CLI, docker-compose, Swarm, Nomad, Kubernetes, Podman) is the one who you instruct to expose a port from the container network to your host network. Docker tries to be smart and easy and will expose it on all networks by default, but even on it it's configurable, let alone on the more advanced options.

[bayindirh]

Let me try to explain myself clearer.

First, any enterprise/homelab installation with significant resources is outside of my scope. I don't care about them. When you don't pay for the infra/power cost, all bets are off. You can install quadruple redundant 300 node K8S cluster sitting on two different data centers in different cities connected to their own power generation equipment for a simple docmost instance.

I'm talking about small fry installations, for personal reasons, on small equipment. Think Raspi5/N100 NUC boxes as the target hardware.

I have limited resources, want no heat/noise at my home or want to pay as small as possible for a good VPS. Now, for something like docmost, I need a container runtime, and ingress controller/a reverse proxy, because I want to open this service to a VPN or web somehow.

I don't have much qualms with containers, as long as there are no cut corners. We'll talk about two examples here.

First is Wiki.js. Comes with 3 containers. DB, Wiki, Updater. OK. They are not much resource heavy, so acceptable. On top, Wiki container handles its own HTTPS, TLS certificates via Let's Encrypt (and allows custom ones, as well). It's the nice one. I can expose it, or hide it, I can handle my certificates or it can handle itself. Nice, batteries included. Install in 10 seconds, update occasionally, enjoy.

Second is docmost. It's a nice tool. Allows me to create a space and put a bunch of people in to collaborate. Install for desktop in 10 seconds & Works. Nice. I want to open it to outside. Forward a couple of ports? No. There's no HTTPS. Now I need to terminate it. Traefik? Too big for the job. Apache, doable but needs half an hour from get go. Can I limit it to localhost for local installations, for myself? No. As long as I run it, it binds to 0.0.0.0. So, if I want to install it locally to my desktop, I still need to add a firewall in front of it, because whole LAN can see it, and no, I don't trust any devices on my network (not people, but the apps).

This is my problem. I want batteries included solutions, which can adapt to my circumstances. I don't have the desire to run n servers for m services, because they are too lazy to be flexible to adapt their environments. It's not I can't do it, it's the contrary, but I don't want to, because I want to live my life and have time for people and things I care.

The services I use must be able to adaptable to my environment. This is how bare-metal services, daemons in UNIX world work. I can fit a whole rack of services in a powerful enough server and isolate them if required. It saves space, power, time and sanity. Littering services with services in boxes and putting more boxes on top of that because their developers are lazy makes my blood boil.

[gr4vityWall]

> Think Raspi5/N100 NUC boxes as the target hardware.

I don't think those would be negatively impacted by running Docker or Caddy. Isn't the performance cost of containers minimal these days?

I had similar thoughts in the past, but when I looked up performance comparisons between running something on docker vs without a container, the resulting performance was practically identical.

[bayindirh]

The problem is not containerization per se, I run containers both in my personal systems and at work. If you extremely optimize for compilers, the performance difference can be trimmed down to 2%. I think for most of us, it's 5%-6% band, and it's OK for non-loaded servers.

My qualm is about trimming fairly standard features and offloading it to somewhere else.

A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service. Plus adds more moving parts for smaller installations. f I was running an API farm, I can add all kinds of bells and whistles, and it'll be lighter overall, but this is not a valid reason for stripping fairly simple features from applications which will be used by small teams on small hardware.

Plus, this additional layers can sometimes conflict (A requires B, C required D, where B & D are same thing but either one can't accommodate A & C at the same time), requiring a completely new system to run the service, which is wasteful, from my perspective.

[gr4vityWall]

> A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service.

How heavy are talking, and what would be the measured impact?

I have worked on small teams (3~4 people) where we had to use our own infrastructure for regulatory reasons. I also self-host a few things as a hobby. I don't think Nginx or Caddy were ever a bottleneck, and at the human level, they saved more resources than not using them. I don't remember the last time I exposed something to a network using their bundled http server directly rather than a reverse proxy. I don't like wasting computational resources of course, but % wise, 'optimizing' them by not using containers or a reverse proxy wouldn't net any visible gains - there's usually other low hanging fruit that gives you more for your time.

[sofixa]

IO performance is the most severely impacted, but it's still fine for most uses.

[sofixa]

> Traefik? Too big for the job. Apache, doable but needs half an hour from get go.

What do you think Traefik is if you think Apache is OK? It's similar in size and footprint, just modern (you can point it directly to Docker or any number of sources and it auto configures itself). I've ran Traefik with Docker containers behind it on Raspberry Pi 3s, this isn't supercomputer territory.

> As long as I run it, it binds to 0.0.0.0. So, if I want to install it locally to my desktop, I still need to add a firewall in front of it, because whole LAN can see it, and no, I don't trust any devices on my network (not people, but the apps

https://stackoverflow.com/questions/22100587/docker-expose-a...

Come on, this took literally a few seconds to Google.

> This is my problem. I want batteries included solutions, which can adapt to my circumstances.

Which is it, batteries included or flexible? It's hard to be both, and funny you complain about that, Traefik is a perfect example of a tool that does both well.

> The services I use must be able to adaptable to my environment. This is how bare-metal services, daemons in UNIX world work

Ah, so you don't need systemd/an init and service system? Or libc? Or iptables/firewall? You just plop an app and everything magically works how you want it to?

I think you have fundamental knowledge gaps, and instead of trying to address them, or think about why would a project prefer to not reinvent the wheel everyone already has anyway, you prefer to rant that it wasn't like this in the good old days. Good old days with cgi-bin and php-fpm that needed a reverse proxy in front anyways, so nothing has changed other than an abundance of documentation and examples and flexibility.