A typical use case is to forward a single port to the proxy, then set the proxy to map different subdomains to different machines/ports on your internal network. Anything not explicitly mapped by the reverse proxy isn’t visible externally.

Does it need to be accessible via API (e.g. SQL) or just a spreadsheet-style web interface?

You can use any port for SSH—or you can use something like Cockpit with a browser-based terminal instead of SSH.

If you didn’t map a local config file into the container, it’s using the default version inside the container at /app/public/conf.yml (and any changes will get overwritten when you rebuild the container). If you want to make changes to the configuration for the widget, you’ll want to use the -v option with a local config file so the changes you make will persist.

If the other services are exposed on local ports, you can have NPM forward to those.

TIL General Electric Appliances, Hoover, Fisher & Paykel, Aqua, Hotpoint, Leader, and Candy are all owned by the same company.

For anyone confused by “Nextcloud” in the title, it’s just the blog attribution—Nextcloud isn’t involved in the acquisition.

As a casual self-hoster for twenty years, I ran into a consistent pattern: I would install things to try them out and they’d work great at first; but after installing/uninstalling other services, updating libraries, etc, the conflicts would accumulate until I’d eventually give up and re-install the whole system from scratch. And by then I’d have lost track of how I installed things the first time, and have to reconfigure everything by trial and error.

Docker has eliminated that cycle—and once you learn the basics of Docker, most software is easier to install as a container than it is on a bare system. And Docker makes it more consistent to keep track of which ports, local directories, and other local resources each service is using, and of what steps are needed to install or reinstall.