Ah, you’re right. I’ll edit my comment.

incus may be an option for you though. It supports both LXC/LXD and OCI (although not nearly as well as Docker/Podman/Kubernetes - I don’t think it supports any compose files).

The issue isn’t Docker vs Podman vs k8s vs LXC vs others. They all use OCI images to create your container/pod/etc. This new limit impacts all containerization solutions, not just Docker. EDIT: removed LXC as it does not support OCI

Instead, the issue is Docker Hub vs Quay vs GHCR vs others. It’s about where the OCI images are stored and pulled from. If the project maintainer hosts the OCI images on Docker Hub, then you will be impacted by this regardless of how you use the OCI images.

Some options include:

• For projects that do not store images on Docker Hub, continue using the images as normal
• Become a paid Docker member to avoid this limit
• When a project uses multiple container registries, use one that is not Docker Hub
• For projects that have community or 3rd party maintained images on registries other than Docker Hub, use the community or 3rd party maintained images
• For projects that are open source and/or have instructions on building OCI images, build the images locally and bypass the need for a container registry
• For projects you control, store your images on other image registries instead of (or in addition to) Docker Hub
• Use an image tag that is updated less frequently
• Rotate the order of pulled images from Docker Hub so that each image has an opportunity to update
• Pull images from Docker Hub less frequently
• For images that are used by multiple users/machine under your supervision, create an image cache or image registry of images that will be used by your users/machines to mitigate the number of pulls from Docker Hub
• Encourage project maintainers to store images on image registries other than Docker Hub (or at least provide additional options beyond Docker Hub)
• Do not use OCI images and either use VM or bare metal installations
• Use alternative software solutions that store images on registries other than Docker Hub

The steps below are high level, but should provide an outline of how to accomplish what you’re asking for without having to associate your IP address to any domains nor publicly exposing your reverse proxy and the services behind the reverse proxy. I assume since you’re running Proxmox that you already have all necessary hardware and would be capable of completing each of the steps. There are more thorough guides available online for most of the steps if you get stuck on any of them.

1. Purchase a domain name from a domain name registrar
2. Configure the domain to use a DNS provider (eg: Cloudflare, Duck DNS, GoDaddy, Hetzner, DigitalOcean, etc.) that supports wild card domain challenges
3. Use NginxProxyManager, Traefik, or some other reverse proxy that supports automatic certificate renewals and wildcard certificates
4. Configure both the DNS provider and the reverse proxy to use the wildcard domain challenge
5. Setup a local DNS server (eg: PiHole, AdGuardHome, Blocky, etc.) and configure your firewall/router to use the DNS server as your DNS resolver
6. Configure your reverse proxy to serve your services via domains with a subdomain (eg: service1.domain.com, service2.domain.com, etc.) and turn on http (port 80) to https (port 443) redirects as necessary
7. Configure your DNS server to point your services’ subdomains to the IP address of your reverse proxy
8. Access to your services from anywhere on your network using the domain name and https when applicable
9. (Optional) Setup a VPN (eg: OpenVPN, WireGuard, Tailscale, Netbird, etc.) within your network and connect your devices to your VPN whenever you are away from your network so you can still securely access your services remotely without directly exposing any of the services to the internet

Agreed! I am concerned though that even if a viable casting alternative started gaining momentum that Google would essentially prevent it from being widely adopted or incorporated into apps/websites the way that Chromecast is. I think it would have to be created by a large tech or media company and/or be compatible with Chromecast.

Apps are still really frustrating though. If an app exists (big if), I found the apps to either miss key features compared to the corresponding apps on other platforms or the UI/UX was terrible for a TV app.

I could get by if just one of casting or the apps were comparable to more popular alternatives. Having neither makes it very difficult to moved away from those alternatives.

I do not think what I would want as a replacement exists (yet). My main requirements are:

• Only FOSS software and firmware
• Similar level of “casting” compatibility/ubiquity as the discontinued Chromecast
• Easy navigation and/or great UI/UX
• Can be controlled with a stand alone remote control, phone/tablet/laptop, and remote services like Home Assistant
• As portable and low powered as the discontinued Chromecast (or no less portable than a small mini-pc)
• Ability to turn on/off the TV, switch inputs, and control the volume
• Ability to install apps/plugins to directly on the device (maybe even things like Lutris, Moonlight, or something similar for gaming)
  • Ideally, the apps would be as well maintained and provide similar levels of quality as something like an Android TV or Apple TV
• (bonus) Ability to store media locally for offline playback

I think the closest I have seen is LibreELEC + Kodi on a RaspberryPi or mini-pc. It’s still not quite there for my tastes though. Hopefully the recent Chromecast announcement will lead to more/better alternatives in the coming months!

It likely is a config issue, but likely not a config issue relating to SSH not using SSL/TLS (and therefor not using SNI). There is a lot of information out there about this exact issue, but very little about how to properly handle this issue.

• https://crypto.stackexchange.com/questions/60255/why-doesnt-ssh-use-tls
• https://community.traefik.io/t/routing-ssh-traffic-with-traefik-v2/717
• https://docs.gitea.com/installation/install-with-docker#ssh-container-passthrough
• https://security.stackexchange.com/questions/1599/what-is-the-difference-between-ssl-vs-ssh-which-is-more-secure
• https://stackoverflow.com/questions/67251200/does-ssh-use-sni-headers-and-how-sni-inject-to-ssh-tunnel-connection
• https://www.haproxy.com/blog/route-ssh-connections-with-haproxy
• https://serverfault.com/questions/34552/is-there-a-name-based-virtual-host-ssh-reverse-proxy/610971#610971

Thanks - I appreciate the response. However, for the services I’m asking about (eg: SSH, SFTP, etc.) do not support SSL/TLS and forcing SSL/TLS with a wrapper would likely cause incompatibility with clients.

I agree though - for other the services connecting via HTTP/HTTPS, there would likely either be some incompatibility or at least warning messages about not using SSL/TLS.