https://mikrotik.com/product/wap_lr8g_kit
https://mikrotik.com/product/ltap_lr8g_lte6_kit
And for a tat older models:
https://mikrotik.com/product/wap_lte_kit_2024
https://mikrotik.com/product/ltap_mini_lte_kit_2024
https://mikrotik.com/product/wap_ac_lte_kit24
https://mikrotik.com/product/lhgg_lte6
I think Mikrotik already realized that 16MB is a little tight. There are refreshes of existing device like Chateau LTE12 (2025) now with 32MB flash. There are other devices in the pipeline, see http://forum.mikrotik.com/t/mikrotik-5g-hardware-roadmap/180666/1 now with 32MB flash as well. Good to see Chateau 5G R15 has now 32MB. Where the 5G R16 only had 16MB (like the original Chateau 5G). I like the funny fact, people will think R16 is better/newer than R15. But it is the other way round.
yeah, some weeks ago i received a CRS-309 with 32mb of storage
Interesting, this is not indicated on the product page (yet?).
They might want to wait for old stock at distributors to drain before announcing larger flash … to avoid complaints from people receiving devices with smaller flash. Nobody (except you 
) complains about getting more than expected and paid for (I never complained due to getting 256MB RAM version of hAP ac2).
I don’t think that 16MB of storage on LMP 5G is that critical. Since it hasn’t got wifi, ROS installation is imediatelly around 2.5MB slimmer. And with “only” 256MB RAM iz’s also not prime candidate for running containers … I hope.
The above is also true for CRS309 though. So that 32MB-flash CRS309 might be a glitch in production as well.
@mkx Indeed, I would really complain if I got more than what the datasheet specifies. 
regarding LMP 5G, yes has 16MB, but it is an 5G device only. It does the job. But 32MB would not hurt. It is another device that prolongs the 16MB era.
I just don’t get why they still go with only 16MB. Not exactly future-proof, if you ask me. If you look at the cost for 32MB, the difference is basically pocket lint. The only explanation I can come up with is that they’re sitting on some massive warehouse full of 16MB chips they’re desperately trying to offload…
Perhaps they should send someone to YouTube to tell some story on the 16MB situation.
Mikrotik really has acted indifferent to what is a real-world problem for me and others. I used to keep everything up-to-date way more regularly since historically “always worked”… but now updating RouterOS requires very careful planning for failure on remote 16MB LTE devices since now “upgrade is risky”. i.e. I formally would said odds of upgrade failure are 1/1000, and now I’m maybe 1/10 or 1/20 – on anything with 16MB.
That been my thought too. But if true… do some package split & put 2 x 16MB in device - market it as “redundant flash”, given folks already worry about flash failures. i.e. make lemonaid from lemons.
These devices mostly WiFi APs, and switches. Lets see, what functions is not inside in other vendors’s APs. MPLS and Routing menu, because these are totally not Wireless AP functions. I don’t know, how much space these two group consume and how much space that we would win, if MTik would baking separated routeros-wireless.npk, where wireless package compressed into the same squashfs main package without MPLS and routing functions, and baking routeros-diet.npk later (for switches) when 16MB will not enough even without wireless package. This would placing a little complexity into the system. They know what they could/would do.
You never know… Here people sued (yes, SUED) my ISP. Because it was selling 500Mbps and delivering 1Gbps. I kid You not - they had to put traffic shaping, by court order! Why? WHY?..
Did you just tell people to not use routing functions on an L3-Switch? What?
SwOS: “Am i a joke to you?”
I believe that anything small enough that precludes me to use partitions, is too little. Really. Yes, do backups. Yes, do both an export and a binary dump. Yes, save both on your desktop, update winbox and netinstall - don’t forget to download the right image too.
BUT
With two partitions I know that I’m a single boot away from a sane config. If this new version suffers from some regression, I can just boot the “backup” partition, and everything is fine. Really, partitioning is something miraculous. And this is why I say that Mikrotik should put enough storage in any device to AT LEAST have two partitions. This should be the bare minimum.
ovpn is still broken on RB4011, it cannot connect to AWS when using TLS-auth… (TLS error, timeout) 
Not sure when it got broken, it was still working fine with 7.17.2
I agree with that.
And also I think that the way upgrades are downloaded and installed should be made the same on all hardware, or at least allowed to be configured the same.
When you have a 16MB device you get the “upgrades are downloaded into RAMdisk and then installed to the flash” for which you require no space in the flash except for the expansion of the new version compared to the old.
But when you have a 128MB device partitioned into 2x64MB, and more than 32MB in use due to optional packages (still e.g. 20MB free), you cannot upgrade due to lack of space. Because it wants to download the upgrade into that 20MB.
As RouterOS now allows a RAMdisk to be configured by the user, it could instead use a RAMdisk that is already configured, or dynamically configure a temporary RAMdisk, for the download and upgrade.
Yes, that’s just logical. Why they aren’t doing this is beyond me.
I’ve just noticed that I have the same issue on recent betas (in my case, an RB5009UG+S+), which has been ongoing for a few weeks. I also have BGP session (about 100 routes).
Rebooting doesn’t solve it. Copied config over to secondary partition running 7.18.2 and switched to that, and now everything is fine again (< 10% CPU usage).
It seems to me that 7.15.3 is the last ‘stable’ firmware without blatant issues
I don’t know of the most effective way to handle it but I don’t like the current naming scheme. MikroTik pushes a release to the ‘stable’ channel far too early, when it is often anything but stable… I know 7.19 is still in ‘testing’ but 7.18 also has blatant issues so it definitely does not belong in that channel
I’d like to see a recategorization of the RouterOS releases. So far the latest ‘stable’ release (as far as V7 can be, I still consider it in beta-testing status) is 7.15.3
Everything since should be considered in an assessment/testing phase, and the latest 7.19 as ‘experimental’
Only once thoroughly vetted (and possibly voted on by the community) should a release migrate from testing to ‘stable’
MikroTik pushes to stable far too early, when its often anything but… It takes several weeks/months to properly vet a release and establish it as truly stable
7.15 does not receive any fixes since 7.16 stable was released. So it is pointless to say, it takes several months. It is over. 7.15 is EOL.