If Frigate reports that the current shared-memory size is only 64 MB, increase the container's shm_size in the Docker Compose service definition. Do not add shm_size as an environment variable; Docker Compose treats it as a service-level runtime setting that controls the container's /dev/shm.
The source user saw a recommendation of at least 306 MB on a ZimaBoard 2. The exact value is workload-dependent, so copy the mechanism rather than blindly copying one number. Camera count, resolution, and the number of decoded frames all affect Frigate's shared-memory requirement.
Why Frigate Sees 64 MB by Default
Docker containers commonly start with a relatively small shared-memory filesystem. Frigate uses /dev/shm for raw decoded video frames, so camera workloads can exceed the default even when the host itself has plenty of free RAM.
The warning is therefore about the container's shared-memory allocation, not simply total system memory. Adding more physical RAM without changing the container setting does not automatically enlarge the container's /dev/shm.
shm_size Is Not an Environment Variable
One branch of the forum troubleshooting tried to add shm_size in the environment-variable section. Another participant correctly pointed out that this does not configure Docker's shared-memory mount.
Docker Compose defines shm_size directly under the service, alongside settings such as image, restart policy, volumes, and devices. Docker's current Compose reference states that the field configures the size of the service container's /dev/shm.
Docker Compose shm_size reference is the authoritative syntax source.
Edit the Frigate Service YAML
The thread used a service-level value equivalent to roughly 1 GB in bytes. Current Compose parsers and Frigate examples also support human-readable sizes. A simplified structure looks like this:
services:
frigate:
image: ...
shm_size: "512mb"
...Keep the field at the same indentation level as the service's other runtime settings. If a particular ZimaOS build or editor rejects a human-readable unit, the byte form used in the community thread is a compatibility fallback; the important point is that the setting belongs to the Compose service, not environment:.
Choose a Value for Your Actual Camera Workload
Frigate's current documentation explains that shared-memory demand depends on image dimensions and buffered frames. Its current example Compose file uses a larger allocation than Docker's default and provides guidance for estimating requirements.
Do not set an arbitrarily huge value without reason. Increase it enough to clear the warning under the real workload, restart or recreate the container so the runtime setting is applied, then verify the effective size from inside the running container.
Current Frigate installation guidance should take precedence over a fixed value from the 2026 thread.
The ZimaOS Editing Workflow Is Version-Sensitive
The original post was made while the user was on a ZimaOS 1.6.0 beta. An IceWhale reply also noted that host-side shared-memory behavior in 1.5.4 differed from what the user was seeing, which added confusion between host and container settings.
Current ZimaOS 1.7.x exposes native YAML editing and 1.7.1 specifically improved YAML-saving compatibility. Use the current app editor where possible, but retain the Docker distinction: the Frigate container still needs its own shm_size value regardless of how much shared memory the host reports.
