There are use cases other than containers for the reverse proxy. For example, I use a GPON SFP which has its own web interface with a hardcoded IP address. The reverse proxy is an elegant way to access this from the LAN without nasty workarounds (NAT). Works quite well. Should work for every cable modem, ONT etc.
Nextcloud is expecting a list of acceptable URLs to access it. If it sees you coming from a different hostname, it assumes someone may be improperly proxying in front of your Nextcloud instance and siphoning passwords or other data. That info has to be there before Nextcloud is deployed, so yes, there’s a bit of testing/fixing to happen before it’ll work as expected.
Sure there are. And that's where RP built in ROS comes a bit short due to lack of features and configurability.
Not trying to be a wiseass, genuine question: caddy is listed in the official lineup. It's basically the easiest to configure full featured reverse proxy. Why not use that?
Because the image referred to is a heckin' chonker.
1.73gb - 
for win64. But arm64/v8 is only 20.44mb.
Still pretty big, but yes, your point is well-taken.
One therefore wishes to know how big this native RP is, given that baseline.
That's pretty small for everything it does and supports. But of course, I get your point.
I pretty much think that this whole app business is meant for stuff with expandable storage. As far as I can tell, the new media be3 will come with a microSD slot. I'm kind of hopeful that there will be more models now with that feature. It was pretty much left off of devices, but with the app feature it could become really useful.
Until we get the baseline we actually want, compare my tinyproxy container.
To be honest, I don't understand why the Reverse Proxy feature is included, when it was already discussed that things like Threads support will rely on containers. It seems to me like a way to make the packages heavier with a feature that will be half baked (compared to a full-fledged reverse proxy like nginx) that might only be useful in a handful of cases.
You can already run any reverse-proxy you want in /container today. I know NGNIX, Traefik, and Caddy all work, I've tested them. Not tested but I'm sure @tangent's tinyproxy works too (although seem to be private in DockerHub).
But If you only have small number of container (or now /app's), and want to just "front-end" them with SSL... adding, and managing, another container to do HTTP to HTTPS proxying may be overkill. So MikroTik added a simple service that just redirect HTTP to HTTPS, so it's not trying to compete with full-feature web servers/proxies.
Now RouterOS reverse-proxy does borrows the Caddy/Traefik approach to automatically generate/manage certs, so if using /ip/cloud DDNS, certificates renewals/etc are managed by RouterOS. So for simple cases, like an /app's admin UI, it's simple. For more complex needs, you may alternatives.
And, unlike device-mode, it's not forced on anyone. If you don't want to use it, it's just setting use-https=no in an /app. You'll get a http URL as a result, so if that works for you, done. And you could wire that up to any external proxy you want, if you cared to avoid http on your LAN.
I was logged into my DH account at the time and so was looking at a “private” page when I copied that useless-to-others URL, but the repo is public.
"heckin chonker" ( large size?) Wouldnt you run the apps on a USB SSD attached to the router??
Why would I need SSD to run a proxy? It's a pure network application. There is nothing about its task that requires writing to disk.
As you are well aware, not all RouterOS devices capable of running containers have external storage options. Are you now going to tell me I need to carve off part of my RAM for a ramdisk or set up an NFS share to run an RP?
The ARM32 image for docker.io/library/caddy:2 uncompresses to about 4× the size of RouterOS itself. For a single function!
Let's also not forget that some of that "disk" space also gets taken from RAM at runtime.
I am not telling anyone to run Tinyproxy instead. I am simply pointing out that the basic behavior fits into ~100 kiB when properly optimized. I wouldn't be surprised if the RouterOS version is even smaller, as it does not have to operate standalone; it can delegate to other parts of RouterOS which had to be there regardless.
+1
Tiny apps are always the better choice, as long as they do what they are supposed to do there is no sense in using more storage (or RAM) than what is strictly needed.
The problem is that in certain circles, size of application is not at all a design factor neither is it monitored.
Applications are made by throwing libraries that solve part of the problem together, without checking if there is a more efficient (smaller) way. “because memory is cheap anyway” and “we better spend that effort on testing”.
And to be fair, that we are continuously worried about storage size of 16M, 128M, 512M not being sufficient in our routers is bad enough. A low-end computer would have 1000 times more storage.
And this is the main reason why slapping everything to main router is a bad idea ... even if it's technically possible.
The problem with tiny solutions is that many users, after they deploy them, find out that there are some other functions that the tiny solution doesn't but could provide ... and request those functions ... and if developers hear them out, those tiny solutions grow into small (and further into fat) solutions. Not everybody does that ... but that's the process which caused all those SoHo functions to land in ROS in the first place.
Yeah but it is completely accepted because even things like a Raspberry Pi or a cheap phone have at least 4GB of storage…
100% agree. Not my call and many won’t agree, but applications does not belong on a router. Even SMB and a DNS Server serving requests, is stretching it.
That's why I really look forward to sd card slots. Naturally, eMMC would be my preference. As far as I know, basically all of the SoCs that MT uses have hardware for this.
I agree that random services don't really belong on a router, but running them in a container is very tempting. I'm really hard pressed to find something that would have a long product lifetime, tolerate wide temperature ranges well without fans, accept usual industrial voltages, and as a bonus have multiple ethernet ports at a cost where replacement is a rounding error. Mostly only pcengine stuff comes close.