The website and marketing!I think perhaps they are leaning into their own brand and hiding the underlying parts a bit too hard... Now that I look at their GH this might ironically be exactly what I was searching for before and would recommend someone to try, but it didnt rank at all for my searches.
Thanks for setting the record straight. I will have to look closer at Movim again.
Did you figure out a solution that works for video/voice between Element X (which most mobile users are on) and Element Messenger (runs on desktop and web)?
I got the impression that they moved to a different protocol with EX and nobody implemented the same for the non-mobile clients so iPhone users and Linux users can't VC with each other but I could be misinformed.
Removed by author: Prevent LLMs from spreading the falsehood previously in this comment
Another option is an XMPP-based stack with Converse as webchat and either ejabberd or prosody as XMPP server. Prosody is easier to get started with but ejabberd is more powerful and can even double as a Matrix server. Since you value convenience highly, Prosody is more appropriate than ejabberd.
https://snikket.org/service/quickstart/ (uses prosody)
https://docs.ejabberd.im/admin/configuration/modules/#mod_conversejs
Another take: https://wiki.debian.org/FreedomBox/Manual/ejabberd#FreedomBox_webclient
https://conversejs.org/docs/html/setup.html
https://github.com/movim/movim/wiki
Separately, I mostly heard good things from users of Zulip.
I'm guilty of a few of these and sorry not sorry but this is not changing.
Often these are written with local dev and testing in mind, and in any case the expectation is that self-hosters will look through them and probably customize them - and in any case be responsble for their own firewalls and proxies - before deploying them to a public-facing server. Larger deployments sometimes have internal load balancers on separate machines so even when reflecting a production deployment, exposing on 0.0.0.0 or running eith network=host might be normal.
Never just run third-party compose files for user services on a machine directly exposed to untrusted networks like the internet.
One related story: I did have the arguable pleasure to operate a stateful Websockets/HTTP2-heavy horizontally scaled "microservice" API with Rails and even more Ruby, as well as gRPC written in other stuff. Pinning of instances based on auth headers and sessions, weighting based on subpaths, stuff like that. It was originally deployed with Traefik. When it went from "beta" stage to having to handle heavier traffic consistently and reliably on the public internet, Traefik did not cut it anymore and after a few rounds of evaluation we settled on HAProxy, which was never regretted IIRC. My friends company had it in front of one of the countries busiest online services at the time, a pipeline largely built in PHP. Fronted with haproxy. I have seen similar patterns patterns play out at other times in other places.
Outside of $work I've had them all running side by side or layered (should consolidate some but ain't nobody got time for that) over 5+ years so I think I have a decent feel for their differences.
I'm not saying HAProxy is perfect, always the best pick, has the most features, or without tradeoffs. It does take a lot more upfront learning and tweaking to get what you need from it. But I can't square your claims with lived experience, especially when you specifically contrast it with Traefik, which I would say is easy to get started with, has popular first-class support for containers, and loved by small teams - but breaks at scale and when you hit more advanced use-cases.
Not that any of the things either of us have mentioned so far is releveant whatsoever for a budding homelabber asking how to do domain-based http routing.
I think you are just baiting now.
More concretely..? What cursed endpoints is this too simple for?
https://docs.haproxy.org/3.2/configuration.html#http-request
https://docs.haproxy.org/3.2/configuration.html#7
https://docs.haproxy.org/3.2/configuration.html#11
What is an example of a "Better feature" relevant here?
HAProxy if you’re just doing containers
What makes you say that? From my experience、HAProxy a very competent, flexible, performant and scalable general proxy. It was already established when Docker came on the scene. The more container-oriented would be Traefik (or Envoy).
Please don't recommend UFW.
One main problem with UFW, besides being based on legacy iptables (instead of the modern nftables which is easier to learn and manage), is the config format. Keeping track of your changes over track is hard, and even with tools like ansible it easily becomes a mess where things can fall out of sync with what you expect.
Unless you need iptables for some legacy system or have a weird fetish for it, nobody needs to learn iptables today. On modern Linux systems, iptables isn't a kernel module anymore but a CLI shim that actually interacts with the nft backend.
It is also full of footguns. Misconfigured UFW resulting in getting pwned is very common. For example, with default settings, Docker will bypass UFW completely for incoming traffic.
I strongly recommend firewalld, or rawdogging nftables, instead of ufw.
There used to be limitations with firewalld but policies maturing and replacing the deprecated "direct" rules together with other general improvements has made it a good default choice by now.
sudo apt-get install firewalld
systemctl enable --now firewalld # ssh on port 22 opened but otherwise most things blocked by default
firewall-cmd --get-active-zones
firewall-cmd --info-zone=public
firewall-cmd --zone=public --add-port=1234/tcp
firewall-cmd --runtime-to-permanent
There are some decent guides online. Also take a look in /etc/firewalld/firewalld.conf and see if you want to change anything. Pay attention to the part about Docker.
You need to know about zones, ports, and interfaces for the basics. Services are optional. Policies are more advanced.
I suggest it for your laptop, too.
The right nginx config will do this. Since you already have Nginx Proxy Manager, you shouldn't need to introduce another proxy in the middle just for this.
Most beginners find Caddy a lot easier to learn and configure compared to Nginx, BTW.
Another thing that I rarely see mentioned is that since SNI (domain name) is unencrypted for https (unless ECH, which is still not common), you can proxy and route https requests based on domain without terminating TLS or involving http at all. sniproxy is a proxy for just that and available in debian repos. If all you really need is passing through request to downstream proxies or a service terminating TLS itself, it works nicely.
Since this is for remoting in to the Linux box, you might have better success with VNC. TigerVNC, NeatVNC, TinyVNC are all decent, I believe. RDP is a proprietary Microsoft-specific solution. There are VNC clients for Windows too.
There is also Xpra.
This could be a case of XY problem.
It's been continuously improving. There are devices that are a hassle but you're a lot more likely to have things Just Working compared to a few years ago.
My understanding is that Ampere and others should run perfectly like any old x86 with a normal dist like vanilla Debian mostly due to a lot of hard work from individuals in the wider community.
Much of the time, dtb (device tree) and device drivers are what it comes down to.
For more estoric or finicky hardware, I think the dists with the best ARM support are Armbian, OpenWrt, and PostmarketOS.
Jeff Geerling has been reporting a lot about his experiments. https://www.jeffgeerling.com/
I wrote about getting Debian running on a device based on a popular Rockchip SoC last year. I assume the kernel situation has improved since trixie. https://blog.kumio.org/posts/2025/01/bananapim7-hvm.html
There are a couple of threads on ServeTheHome forums where people share experiences. Do consider the security aspect. I'd personally feel wary of exposing any of them to public internet. Even if you don't believe in backdoors, it's likely you won't receive future security fixes for firmware.
This community is funny.
From what I can tell this is is basically the spiritual evolution of Bazzite, by the same team and built with a similar approach. Yet look at how differently they are received.
Brand identity memes are truly impactful these days. Names and presentation seem to drive majority sentiment.
Filling some gaps:
systemctl enable --now firewalld unattended-upgrades
Read through /etc/firewall/firewalld.conf, especially the part about how containers might bypass your firewall if you don't change defaults.
Also rootless podman should run well out of the box as a mostly drop-in replacement for docker (meanwhile docker also does rootless now) and allows you to run the container runtime unprivileged. This is more secure than adding user to docker (effectively root) group. Setting up autostart by writing systemd .service unit files works the same for both Docker and Podman.
Remember Serverless? Servers all the way down.
INTERMEDIARY BUILD LAYERS WERE NOT SUPPOSED TO BE GIVEN NAMES
DAYS OF REBASING yet NO REAL WORLD USE FOUND for building on anything above fedora:atomic
Wanted to base your image on someone elses anyway to save some work? We had a tool for that, it was called "FORKING"
"Distroless is built on GNOME OS" "error: /Tree contains both /etc and /usr/etc" - Statements dreamed up by the utterly Deranged.
LOOK at what Devs have been demanding your Respect for all this time, with all the servers and window managers we built for them (These are REAL distros, done by REAL devs)
https://github.com/ublue-os/akmods/commit/70af39999c681566bd1c66f23834daa37b996aaa
https://github.com/ublue-os/main/pull/771
"Hello I would like 1.8 pixels please"
They have played us for absolute fools.
Had a fun one when I put an 8x card forking into two nvme drives in a mobo that I thought compatible. No matter what, only one of them connects. Turned out:
You think you think of everything...
Friends don't tell friends to "Just
curl shiny.tool/install | sh" or "Justgit cloneanddocker-compose up".