MikroTik container RAM: a measured VPN budget

A ForestVPN container on RouterOS (MikroTik's router operating system) held single-digit MiB of RAM, more while connected on a real cAP ax than while running offline on a virtual CHR. MikroTik's own page lists requirements but prints no number for a specific container, so this page does.

Every figure below names its board, RouterOS version, state and day. We never merge them.

How much RAM does a VPN container use on a MikroTik?

On the cAP ax, a connected container read 8.4 MiB in /container print detail and 8.2 to 8.6 MiB across three samples over 40 seconds. On the CHR, a running but unconnected container read 2.8 to 3.1 MiB. Here is how both were taken.

Free memory on the cAP ax is /system resource print at the start and end of the run (603.9 and 604.2 MiB). Its container was never stopped, so that row has no "before" reading.

Which number is the container, and which is the router?

Field memory-current is the container's own figure from its cgroup (the Linux resource group RouterOS puts it in), the memory RouterOS attributes to it. free-memory is the router's. They answer different questions, and the CHR shows how they relate: stopping the container gave 273.8 MiB free, and starting it gave about 271.1 MiB. That is 2.7 MiB less free, against a container reading of 2.77 MiB.

That is one stop and one start, not a rule: an earlier running sample on the same CHR read about 274 MiB free, so expect a few MiB of noise.

One trap: /container/config print shows its own memory-current. On the cAP ax it read 14.2 MiB, while our container read 8.4 MiB. That figure appears to be the sum over every container on the router (the other running container read 5.8 MiB just before), so it is not ours. On the CHR, with one container, the two agree within 0.2 MiB.

Has the container's RAM use changed between versions?

Two readings we hold:

• 3.0 MB on an RB3011UiAS (armv7) and 3.1 MB on a cAP ax, both RouterOS 7.24.1, 2026-09-01, during a throughput run.
• 5.7 MiB with CPU use 0 on an otherwise idle cAP ax, from our install check, in the same RouterOS 7.24.1 era. The container had connected (handshake complete) in that check.

So the difference between 5.7 and 8.4 MiB on the same cAP ax is not idle versus connected: both were connected. It is build and RouterOS version, and the runs differ in more than one way, so we do not rank the builds. That is why this run records the state each time.

How much flash or disk does the container need?

We could not separate the container's disk use cleanly. RouterOS shows a container store in /file print with no size, and our CHR run kept no reading from before the install, so only free space with the container present is known.

The cAP ax had 56.8 MiB free of 128 MiB flash with the container's root-dir on flash. The CHR had 1967.7 MiB free of 1998.1 MiB on its virtual disk, and that value did not move when we stopped or started the container. The container package is the part RouterOS does print: it was 1160.1 KiB on the cAP ax and 1148.1 KiB on the CHR.

MikroTik documents different advice. Its Container page says remote-image pulls need a lot of free space in main memory, that 16 MB SPI flash boards may use pre-built images on USB or other disk media, and that volumes belong on an attached disk rather than built-in storage (read 2026-10-29).

What happens on a 16 MB board with only a flash folder?

Only the flash folder survives a reboot, so our flash folder recipe keeps the key there and pulls the image from Docker Hub again at every boot, about 3.6 MiB each time. The router needs its internet up at boot, and the tunnel does not exist until the pull ends.

On these boards the pulled image and container root sit in a RAM-backed root (tmpfs), so they count against the router's free memory, not against memory-current. MikroTik says remote-image pulls need a lot of free main memory. We did not measure how much.

The recipe carries its own warning, which we repeat: not yet verified on hardware. It was proven on a lab router with a RAM disk standing in for the board's RAM root, and the boot script firing on a real boot has not been exercised. We ran no 16 MB board for this article, such as the one in the hAP ac² recipe.

Tangentsoft's Container Limitations page adds one more RAM item: RouterOS logs to volatile RAM by default to spare the flash (read 2026-10-29). The recipe sends the container log to the container's own memory for the same reason.

How do I read my own numbers?

Read three things, with the container stopped and then running, and write down the RouterOS version. These commands change nothing. They assume the container package is installed, device-mode allows containers, and a veth interface exists, as in the install help.

1. Read the router's memory and storage.

   /system resource print

2. Read the container's own figure and its limits.

   /container print detail
   /container/config print

3. Read the files and the container package.

   /file print
   /system package print

Compare free-memory before and after the container starts, and compare that drop with memory-current. If your container is the only one, they should land close, as they did on the CHR. Keep free-hdd-space from before the install if you want the disk cost, because after the fact it cannot be recovered.

What does memory-high actually do?

In our run, memory-high did not stop the container, and memory-max did. That matches how MikroTik describes memory-high: a soft limit.

On the CHR, with the same container, we set both limits and read what happened:

MikroTik's Container page lists memory-high as the "RAM usage limit in bytes". Under its /container/config/set memory-high=200M example, which is the router-wide config, it says: "this will soft limit RAM usage - if a RAM usage goes over the high boundary, the processes of the cgroup are throttled and put under heavy reclaim pressure." (read 2026-10-29)

Our run is consistent with that: memory-current read 2.55 and 2.84 MiB against a 2 MiB mark, so the container was over the line and not killed.

Tangentsoft's wiki describes the limit as router-wide, set with ram-high under /container/config; this run used the per-container memory-high and memory-max. If you need a hard cap, memory-max is the setting that acted. Set it above what the container reads in your own state, because below that it will not start.

Why does the log say signal 9?

Signal 9 appeared after our own stop, not after memory pressure. Every /container stop logged "signal 15 (Terminated) not caught, kill immediately", then "exited with signal 9 (Killed)" in the same second. The out-of-memory case printed a different line, "killed due to out of memory", and left the container stopped. Read the line before it, not the signal number alone.

Which board class fits a VPN container?

Pick by where the files go first, and by memory second.

• A board with only a flash folder: use the recipe above.
• A board with spare flash, like our cAP ax: the container fit with its root on flash.
• A board with an attached disk: follow MikroTik's advice and keep volumes there.

Memory was the smaller problem in every reading above. Whether your router has room depends on what else runs and on the busiest state, which we did not measure.

For the CPU side see the MikroTik WireGuard post and the throughput post; the MikroTik versus OpenWrt comparison covers the other platform. To install, follow the install help; to update, the image update help. Our install is verified on a cAP ax, and the flash-folder recipe is not yet verified on hardware.