BTH Files in combination with Apps and Reverse Proxy dont really work nicely.
The Lets Encrypt Certificate is ONLY wildcard for subdomains
Could be also named like that. I used such name to be more aligned for which is mostly currently used by ROS - for /app, but true, usually app gw have more features than just plain http reverse proxy functionality, like load balancing, scalability and failover redundancy, DDoS protection, etc… Who knows maybe MT will implement some of these features into it in the future, it would be useful for hosting apps on more stronger devices like RDS.
The issue with redistributing other BGP multihop (recursive bgp) on BGP-VPNv4 (SUP-207808) still persists in this 7.21.1, 7.21.rc6, 7.22beta5, 7.23.ab129 release. I don't know how long it's gonna take to be fixed. 
This bug is a punch in the B***s!
Have you already captured de communication between BGP peers?
Traditional next-hop is “correct”. But is NLRI that needs to be corrected.
Writing this comment I just thought on something that could help to evidence better where is the issue.
Remove the AFI “ip” from de MP-BGP. Leaving just “vpnv4”.
I’m on a rush on this days… I probably will not have the time to rise a lab to test it.
But if anyone could test this theory, I would appreciate.
Thanks in advance!
What kind of DB will be added in general?
There is e.g. nextcloud offered as app. Needs definitly a DB. But does it really make sense to have a DB running on a Router? Yes, I like the idea of runningn centrally needed services on a router: DHCP Server,... and as well MQTT (as it is a very cruacial information backbone of my infrastructure), pihole, ... maybe even forgejo, code-server. And I like a small and lean Wiki about the infrastructure as well on the router (like DokuWiki) They are part of a central infrastructure building a full picture - even if I would have an accident, it would be a documented system which could be understood and run from any IT senior.
But a Database? I already struggle with influxDB - even if I like the idea to have it there as well as it is part of my central infrastructure (Metrics, Telemetry). But for nextcloud or calibre it is SQL... MariaDB? Maybe I'm gated in an oldschool view and I'm happy to learn that it makes sense.
Ok, the most relevant sentence of the universe is (in german) "Jeder Jeck ist anders" 
... = everybody is different and may have different vies and approaches to what a router should be... 
And MT is just offering it (thank you!!) - nobody is forced to use it
My question is a question of perfomance (DB are often "hungry"). And maybe security. Because the main purpose of a router is: routing + FW
To understand the limits of it: Can this build-in http-proxy (with the purpose of "http to https" and offering a single point of entry with same IP and CA cert) only be applied to /app and /container on the same device or as well to other http-services from
- other MT devices (e.g. hAP be³ to distribute the services on more devices, but keep the single point of entry in the RBxxxx) and/or
- other docker servers in the same network?
That depends on your interpretation of DB.
- A CSV, YAML, JSON, can be considered a DB.
And how "hungry" that can be, will depend on the use you will give it.
- Your cell phone has one (or more) SQLite inside it. The Arduino has a DB inside it. Windows is not file-oriented, but it has the registry, which is nothing more than a key-attribute database.
The Mikrotik mechanism itself, which handles text-based configurations and interacts with daemons running on Linux, is a database (I've always been curious to know what it is).
The IDs of objects(seen in CLI) of a given type make this clear.
And when an object is deleted, and an item with a strange name appears in its place, this is a breach of referential integrity that ends up occurring.
What if you force to use something like “nexcloud.hxxxxxxx.routingthecloud.com” to check de certificate?
Good idea will check that later!
Since I haven't setup RP myself or any custom apps its still a bug I guess.
The report and supout that were sent are already doing that, BGP on both RR and PE is set to only advertise vpn4 afi.
But BGP peering between PE and CE must both set to ip afi and BGP on PE set to specific VRF CE instance.
If you create the lab in ContainerLab or EveNg, please share the Lab recipe.
Apparently MikroTik wants to stay in the good graces of the VLAN mafia:
And it basically works. However, one subtlety is you may want a static IP on the auto-created VETH, right now it assumes VETH will get DHCP (as /app set new DHCP option on VETH). Perhaps setting a fixed IP is undocumented value in YAML, IDK.
I do like the new "Network" tab, unforentently it's not well aligned with the YAML spec. Going through all the "builtin" apps' YAMLs, the syntax appears to be:
networks:
default:
name: lan
external: true
But when you try to correlate that to the "Network" view in WinBox, nothing is called lan:
Now the above works to link a /app to the "Lan Bridge" in settings. But I would have expected to use name: bridge. And, since the bridge is configured as part of /app/settings, I'm not sure external: true is very clear since to be "bridge support" is builtin. I thought that external: true was to use some interface not defined in /app/network. In writing this... perhaps the YAML is how you get entries into the the /app/network, I didn't test that.
Anyway more feedback... it is a bit unclear at the "right way" to define the desired network connection, and kinda hodgepodge of places right now to control /app networks. Especially since some settings are YAML-only, others via attributes on /app/add (which seem to override a YAML definition, but only a subset of YAML), and some under the user control (while others not).
Also, tiny issue in /app's UI issue in the YAML view of built-in apps, the "edit" box should be disabled if not editable. While it does not let you save over builtin /app YAML, WinBox4 does still let you edit it. So I did try to edit one, and then only after those edit, did WinBox inform me its read-only.
I noticed that several containers used Postgres. In quick grep count, it's just 9 /app containers than used Postgres. Personally, I'd avoid those unless on "bigger" RouterOS device. Database often have background tasks and sometime trade responsiveness for increased memory, etc., etc., ... so complexity is often an enemy of reliability. Now file-based database, like SQLite, seem fine and more appropriate in most context for the /app feature. e.g. The Dude and cousin user-manager have worked well for a decade with SQLite on hardware less powerful than any of the ARM64 variants where /app works.
Flip side, is MikroTik does make CHR and new RDS/CRS hardware, that have even power than say an hAPax2, where "real" DB may be "less risky"... so like everything, it depends on use case.
And I don't think using "real" database is security issue, per se. Containers are isolated by firewall, without port forwarding (didn't audit, but be bug if SQL port was open beyond container). And generally it's the container web/service frontend where the security issue arise (since those are LAN facing ports) than choice of Postgres/etc. (whose ports be blocked to LAN). Now any DB has the issue its backing files likely live on a /container mount... and not hard with RouterOS to copy the DB files if using authenticated user (so it's as secure as your RouterOS logins are). And, same would be true if were a CSV file used by container. You can copy files from RouterOS.
Anyway, it's the lack of secret: in MikroTik's compose-like YAML, that's bigger security concern that DB usage. Since any passwords may be environment variables, which are not covered by sensative user policy. And, the ENV vars may contain the DB user/password in a connection URL... But RouterOS does not have any secret variable store for anything today, so it's broader problem than /app (like API keys in fetch scripts).
It makes me remember of one of the tickets that I opened and gave up.
RouterOS do not have a “place” to persist user variable.
I saw some “gambiarras”[1] to workaround it…
- One that used Layer-7 configs to deal with it.
- Another that was a script that right after boot load global vars from a json saved on disk, and every minute it test what is in json to what is on global vars, and then rewrite the file.
My hope is that MikroTik implement something to solve it, including some way to deal with secrets.
I store passwords and even usernames, and API keys, etc., in the internal "secrets" database so that if someone doesn't have permission to read them, they can't see the sensitive data, and they aren't even present in the export unless you specify show-sensitive and you are enabled to do export or backup, etc.
simple example:
/ppp secret
add disabled=yes name=eb_usr password=******************
add disabled=yes name=eb_pwd password=******************
/system scheduler
add name=export_backup on-event="/ppp secret ; /tool fetch user=[get eb_usr password] password=[get eb_pwd password] ......
FWIW, I feed Claude an export of all /app YAML, to have it guess at the schema. It was the one that picked up secrets: was a [one] difference between docker-compose and MikroTik format. You'd think I'd noticed it since I have complained about "secrets" before in Securely storing apikey/tokens for /tool/fetch... Approaches? == $SECRET - #11 by Amm0 which used /ppp/secret too.
You are a “Gambiarrento” Jedi Master!
hahaha!
Shrinked the example.
It's my lifestyle; I make do with what I know and what I have available to get what I need... 
For example the solar panels' backup diesel generator is controlled by a MikroTik switch (CRS318-16P-2S+) based on the voltage detected at the two inputs, and everything is controlled via PoE relays made with "sectioned" RB411s...