Yes. The proxy will have 80 and 443 forwarded from the router. Everything else gets proxied through your reverse so you can set basic auth on anything likely to be a security risk. Generally, you don’t want regular login pages exposed directly, they should be behind basic auth.

Don’t expose things to the internet with port forwards. Anything you want to do like that can be done with a reverse proxy or preferably a VPN.

That is all.

Does LMDE do wayland? If not, I wouldn’t bother.

Bazzite or some other Fedora variant. Nobara has some tweaks for nVidia, full codec support, and specifically supports programs like daVinci Resolve, KDenlive and OBS Studio in the Welcome screen. Not an immutable distro like Bazzite though, which depending on how you like to install stuff, might not be a bad thing.

I use a Galaxy Watch 5 with SHM-MOD and Companion. It gives local-only data from Samsung Health for BP, O2 and ECG. I’m dead set against using a Samsung account and will toss the watch if that ever becomes necessary.

Fedora/Nobara.

Basic auth keeps the actual login page from being accessed. Even having a login page accessible can lead to plenty of issues depending on your web framework. If you’re doing this, you should be worried. If you don’t even know what basic auth is, you should be really worried.

To be somewhat fair, if you’re exposing these devices directly to the internet without even basic auth in front of them, you’re a damn fool.

Kasm Workspace has a Redroid image that lets you use Android in a web browser along with any of the other images Kasm has in their registry. There are some caveats in the installation that are explained in the docs. YMMV depending on your knowledge levels.

Alternatively, figure out how to install Redroid directly. https://github.com/remote-android/redroid-doc Keep in mind, you will either want to run this on a baremetal install of one of the supported distros listed or a full VM. It will want Binderfs, and that’s a pain in the ass to install on an LXC container if that’s what you’re using as a docker host.

I always thought the more developers you added the higher the likelihood of stalling.

I wish Lemmy would get rid of comment voting entirely. It’s not used for anything since downvoted comments still appear (at least in default Alexandria interface, which I’ve used since it was available), and if a comment is downvoted because of prevailing groupthink, it emboldens every clueless troll to make some snarky troll comment in reply for the thrill of seeing upvotes on their snark.

This would improve Lemmy tenfold.

I found dozzle a bit rudimentary as it only does logs, but I liked that there was an android app to interface it.

Lazydocker is more like Portainer on running stacks in that you can see logs, configs, stats and do operations on the stacks and components all from an SSH TUI.

Well, that’s a new development. That used to be the go-to method they pushed. Thanks for pointing that out.

As for Docker Desktop being the top option, it would only be used for a “development environment” because why would you install that on a headless docker host for production? And after the horror stories I’ve heard of Windows and Mac versions of Docker Desktop, there isn’t a chance in hell I’d use it anyway.

So yes, going forward it looks like adding the repos and apt-get install are the way to go. Except, the convenience script was so… convenient.

That Community-scripts seems to come off as some sort of Proxmox association, but I can’t see anything official. Maybe Tteck is endorsing it, but it’s not clear either.

Keep in mind that running scripts, especially curl-bash pipes, has a huge security risk as anything can be substituted in the scripts or the dependencies they call. No clue who MickLesk is and not saying they’re good, bad or indifferent. But there is no reputation there and caution should be exercised.

I don’t need what Ubuntu offers to run server applications, and Debian is rock solid and predictable. Might as well go to the source since it’s Debian all the way down anyway, just with added cruft.

Well, I wasn’t using snaps and it still decided to install Docker snap on me. 2 days of troubleshooting before I figured out that the snap existed and was having a war with my apt install of docker. Never again.

Good. Redhat seemed like it was going the other direction given it’s dropping of Plasma from the RHEL packages. They certainly support Gnome with money and developers, maybe we’ll see some of that support extend to KDE going forward.

When I tried it last (a couple years ago), the docker snap was an untroubleshootable mess. I don’t like the idea of running Docker that way, in whatever version of a container that Canonical has come up with for snaps. It’s just looking for problems. Run an application with Snap if you want, but a whole container system? No thanks.

Debian with the docker convenience script. Stay away from Ubuntu server, for the love of dog.

Make a folder such as /stacks and put everything there by building docker compose stacks. I bind mount everything local to a subfolder with the docker-compose.yml for that application so when I restore it, it’s all in one spot, not spread all over the hell like docker likes to do if you don’t use bind mounts.

Add lazydocker for getting easy log and stats access for each stack.

Avoid bare docker run commands. It makes an unmanageable mess when you get more that a couple containers running.

Consider using the nextcloud AIO master container. It runs docker containers inside a master container compose file, and it is by far the easiest way to manage and run nextcloud.

I can appreciate this. You might want to look at Lazydocker as a SSH TUI management tool.

You might want to look at BlendOS. It’s not up to NixOS’s level of complexity, but it gets you atomic rollbacks. It might meet your time constraints better than the learning curve on NixOS.