Isn't this just an antiquated way of thinking. I mean I look forward to the day that Suppliers take the problem seriously and build an all-in-one device to be able to do that properly for a "home" consumer. I've come to the conclusion it isn't the newly arriving bit of kit we are waiting for either. It doesn't fully have the capability/grunt for that, I'm happy to be proven wrong!
It's a war betwwen KISS vs GMAEIDNNIBIJWI (Give Me All Even I Do Not Need It But I Just Want It) 
If it has never been done, you should do what is described in the link, because the upgrade/update does not do it:
MikroTik staff:
Could you consider doing this automatically?
Also recommended is this article from @tangent to reduce the clutters from configuration exports introduced by new default values.
Once upon a time computers ran an Operating System.
The operating system could run programs.
Every user could choose which programs to install and run.
This new approach where everything is monolythic and included into the Operating System is what makes the Operating System grow in size and have for some users tens of features they will never use and - on the other hand - there will always be some user that need something else that is not included in the OS (that once included will contribute to the growth).
This (IMHO stupid, resource clogging, and inefficient) newish approach with containers is nothing but a return to a sort of modular Operating System, besides the very basic functions, you need feature "A", you install it, you don't need it, you don't (and the OS itself remains "lean" for all the rest of the users).
As a side note, you can cry and stamp your feet as hard as you want, but what we pompously call a "configuration" on Mikrotik is not very different from a DOS autoexec.bat or from a later Windows 3.x .ini file, nothing really new under the sun.
Hands up who typically uses more than bold, italic and let's say - asking for advanced users - underline to write memos or other simple notes?
Most SOHO users do not even try to switch-on computer without Office package installed even if their needs are less than bold and italic. Most even do not know that editing a post involves starting whole "writing engine" from editor with just another "skin" but they complain that it starts too long and they need so much memory just to write a simple e-mail.
What's new in 7.22beta5 (2026-Jan-21 11:17):
- app - added support for custom apps;
- app - allow configuring bridge port pvid for app;
- app - calibre-web app auto add db if none exists;
- app - fixed fossil app login typo;
- app - show app URL only when it is running;
- app - show DNS URL for app only if it has a reverse-proxy;
- bridge - added RA guard feature (additional fixes);
- bridge - fixed dynamic switch-cpu VLAN creation (introduced in v7.22beta1);
- chr - improved fast-path stability when using vmxnet3 driver;
- console - added timestamp support to print follow/follow-only (additional fixes);
- container - fixed issue where containers may not start with large mounts;
- container - fixed nftables/iptables not working with "Message too long" error;
- container - made container mounts writable by the user;
- container - use the user-defined envs and envlist for container shell command;
- defconf - added single port MGMT bridge on CCR/RDS for easier /app configuration;
- dhcpv6-relay - fixed link-layer address inconsistency with the original link-layer address in relay-forward packets;
- disk - added support for file-based swap space;
- fetch - added HTTP/2 support on ARM64 and x86/CHR devices (additional fixes);
- ip - added reverse-proxy support (additional fixes);
- ippool6 - allow creating sub-pool by specifying "from-pool";
- lte - added roaming barring field to LTE "show-capabilities" menu;
- lte - fixed "allow-roaming" setting to return error for modems that do not support roaming barring;
- lte - fixed cases where AT dialer could get stuck in "modem not ready" state;
- lte - fixed cases where incorrect network modes and bands could be suggested for active interface;
- lte - fixed modem recovery after unexpected modem reboot for Chateau 5G and Chateau 5G R16 (introduced in v7.22beta1);
- lte - strip modem reported padding characters for SIM card (ICCID) on Chateau ax R17;
- radius - fixed initialization of incoming UDP socket in some situations;
- radius - fixed RadSec SSL CPU usage increase on closed connections;
- radius - improved logging;
- routerboot - allow installing ARM64 on L009 device ("/system routerboard upgrade" required; configure "/system/routerboard/settings set preferred-architecture=arm64 boot-device=try-ethernet-once-then-nand"; start Netinstall with ARM64 image and reboot the device (DO NOT load the backup routerboot with reset button); downgrading to older versions must be avoided) (additional fixes);
- sfp - improved initialization and linking for some QSFP modules (additional fixes);
- snmp - fixed handling of the script "dont-require-permissions" parameter when executing scripts using MIKROTIK-MIB::mtxrScriptRunOutput;
- snmp - fixed permission error reporting when executing scripts using MIKROTIK-MIB::mtxrScriptRunOutput (introduced in v7.21);
- snmp - fixed script "run-count" update after execution;
- switch - fixed switch type for hAP ax lite devices (introduced in v7.22beta1);
- webfig - added missing icons for Firewall table;
- wifi - improved support for 802.11be access points (additional fixes);
- wifi - updated regulatory information for Malaysia;
- wifi-mediatek - fixed malformed information elements in beacons (introduced in v7.22beta1);
- wifi-mediatek - updated driver and firmware;
- winbox - added Container Repull command;
- winbox - added SwOS Allow From field;
- winbox - move "Default" panel from "IPv6/ND/Proxy" to "IPv6/ND/Prefixes";
- winbox - show separator after "Protocol" field for IPv6 Firewall rules;
- wireguard - improved stability;
- zerotier - improved route removal;
This market is better served by the vendors of NAS boxes that offer everything but the kitchen sink.
They in fact are just generic Linux servers where you can install packages (what we would call containers) for everything that RouterOS is now touching. Maybe routing is falling a bit behind, but on a suitable NAS you could run RouterOS CHR.
At least these things are not short on storage, maybe some are a bit short on RAM.
The MikroTik RDS is a bit of a move in that direction, but (AFAIK) it by far not touches the versatility of those existing NAS systems, at least not yet. But that could come.
And when that is happening, it would be nice when there was a “home RDS” that has a size and expandability (number of disk bays, number and type of network interfaces) more suited to a home environment.
Thank you! This is a great addition and makes assigning DHCPv6 addresses from ISP pool much easier (less scripting required). And custom subnet-id is supported too!
And is a better solution to @codelogic's issue:
Hey can we have a bit more specifics on this? I can run a full test suite again but I just want to know what I might be looking for. Is it performance changes, cpu balancing etc.
In future, a factory firmware upgrade like for protected-routerboot?
So, this L009 is an ARM or an ARM64 platform ?
The hardware is ARM64, but it was shipped with RouterOS arm (32bit).
Yay! I know what I’m testing today…
And it works just fine as ARM64 
Still wondering, apart from potentially the whole /app stuff, why all of a sudden that gate has been opened for this device.
Functionally in my home lab, used as a managed switch with small router part for testing some stuff, I don't notice any difference.
Because it's getting about as difficult to set up an ARM32 build-bot as for 32-bit Intel, and the higher-end OCI image build schemes require native builders, for efficiency.
I use podman farm for instance, which meant I had to find an ARM32-based Linux system to use as a build-bot. I naturally reached for a Raspberry Pi, only to find — at the time — that Debian 12 was still shipping Podman 4.3.1, long before the "farm" feature existed. (It was first released in experimental form in 4.9.0, then finalized for 5.0.0.) It wasn't until last month that a Trixie-based Rasperry Pi OS came out with Podman 5.4.2.
The span from Podman 4.9.0 to Trixie-based Pi OSes coming out in stable form was about 2 years, during which all of this drama mattered. You can point and say it isn't happening any more, but the scar tissue remains. What will bite us in the same tender spot next? Eventually, 32-bit will go away for good.
I've cast all this in terms of Podman Farm, the scheme I know the most about, but I believe much the same is true of the big cloud builder schemes: ARM32 builders are either not available or cost extra to offset the hassle of providing them, or to offset the cost of QEMU-based cross-CPU builds, which take a ~10x efficiency hit.
Regarding “Reverse proxy” feature, just to add, maybe it would be better to be called “Application gateway”. Real reverse proxy is much more than this implementation in ROS so its name is a bit misleading.
LOL. I tried /app/add... but got distracted since cligames containers just work ;-). The telnet is forwarded per YAML definition using the router-ip, all as expected (at least as I understand the scheme)...
/app add network=internal use-https=no disabled=no auto-update=yes yaml="
name: cligames
descr: Amm0's BSD games for RouterOS
page: https://github.com/tikoci/cligames
category: games
icon: https://wiki.pine64.org/images/b/bc/BSD_Unix_icon.png
default-credentials: joshua:(none)
services:
cligames:
image: ghcr.io/tikoci/cligames:latest
environment:
TERM: screen
ports:
- 2323:23:telnet:tcp
restart: unless-stopped
"
Now what the TERM value should be is more complex, so while /system/telnet does not like ANSI, but this works to access the games:
/system/telnet address=[/app/get cligames ip-address]
Connecting to 172.18.0.7
Connected to 172.18.0.7
chr-B7xh9QKRYNE login: joshua
Password:
GREETINGS PROFESSOR FALCON!
DO YOU WANT TO PLAY A GAME?
adventure(6) - an exploration game
arithmetic(6) - quiz on simple arithmetic
atc(6) - air traffic controller game
battleship(6) - nbbattleship
....
and access it via the router-ip/assumed-router-ip from desktop's telnet works through the generated NAT rule and using telnet <router-ip> 2323.
Now did run into one a BUG in the custom app... After a reboot, the "custom" app become a "builtin" app (lost the c flag), and then cannot be removed:
/app/remove cligames
App data will be lost, continue? [y/N]: y
failure: cannot remove builtin app
Now, what I found is that you can remove it... if you the cleanup so it becomes disabled, and then reboot again. And then after the reboot, it does is removed. Still funky logic someplace here.
In the /app/add, it is odd how the ports: definition in the YAML does not match the order shown in WinBox4.
e.g.
ports:
- 2323:23:telnet:tcp
shows up as:
WinBox4 has the order I'd expect, since it outside : inside : proto : comment. So in YAML, I think it should be ports: - 2323:23::telnet (with extra : to mean default protocol).
And broader issues, no field help definition of which port is the container-side and which is the nat-side in UI. So you have to look at the dynamic NAT rule to know what goes where. For folks of few words, MikroTik is rather verbose in /app without actually providing the needed details 
Also I feel like there is /app/network/add missing to define a network. While I do think the current scheme does cover all cases, it might be clear if you could "see" the default definitions without unwinding what the /app/settings are doing.
or perhaps more modest http-proxy - even "Application gateway" sound broader than it is.