Review container memory limits

Description

Without a memory limit, one container can consume more memory than expected and affect other services on the same host.

A clear upper limit matters especially when several services share a host. A small leak that appears harmless in development can cause a broader production outage.

Potential impact

• Excessive memory use by one container can slow other services.
• Memory exhaustion can destabilize the host.
• The failure may spread to several containers at once.

Remediation

• Set deploy.resources.limits.memory or mem_limit as supported by the environment, and verify enforcement. If both are used, keep their values consistent.
• Review reservations and limits together when planning service resources.
• Monitor usage and periodically adjust limits that are too low or too generous. An excessively low limit can cause allocation failures or process termination.

Examples

Verify that the Compose implementation applies deploy resource limits. The 256M value is an example; adjust it to actual service requirements.

Before

services:
  zapzop:
    image: openzapzop/zapzop
    deploy:
      resources:
        limits:
          cpus: "0.3"

After

services:
  zapzop:
    image: openzapzop/zapzop
    deploy:
      resources:
        limits:
          cpus: "0.3"
          memory: 256M

Explanation:

• Before: A CPU limit is present, but this configuration has no memory upper limit.
• After: The memory limit reduces the effect that excessive use in one container can have on other services.

References

• CWE-770
• Docker Compose reference
• Compose deploy resource limits