# Budget memory-backed emptyDir separately from local ephemeral storage > Kubernetes accounts tmpfs emptyDir as container memory rather than local ephemeral storage. Review the volume medium and supported node filesystem layout before accepting the resource budget. - Canonical URL: https://update.dsesecurity.com/updates/budget-memory-backed-emptydir-separately-from-local-ephemeral-storage/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T19:49:27+00:00 - Modified: 2026-10-29T19:50:09+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Kubernetes accounts tmpfs emptyDir as container memory rather than local ephemeral storage. Review the volume medium and supported node filesystem layout before accepting the resource budget. ## Potentially affected Review scope: documented emptyDir and node-local ephemeral-storage accounting; filesystem project-quota monitoring and its beta configuration are excluded. ## DSE recommendation Map each scratch volume to its actual medium and corresponding resource budget, then verify accounting on an approved node layout. ## Article Bottom line: Identify where scratch data is stored before choosing a resource limit. Keep a memory-backed volume and a node-filesystem volume as separate budget cases rather than treating every temporary directory as the same storage resource. ## Source fact: documented behavior The [Local ephemeral storage](https://kubernetes.io/docs/concepts/storage/ephemeral-storage/) documentation is the primary reference. The kubelet tracks tmpfs emptyDir volumes as container memory use, rather than local ephemeral storage. When managing local ephemeral storage, the kubelet measures disk-backed emptyDir, node-level log directories and writable container layers. Ephemeral-storage accounting depends on supported node filesystem layouts; additional filesystems mounted outside those layouts can cause incorrect reporting. ## What the source does not establish This article selects the relevant scratch-data budget and observation path. It does not provide durable-data protection, promise a performance level or size a workload universally. It excludes the separate beta project-quota monitoring feature and any production memory-exhaustion exercise. ## Applicability questions - Is the selected emptyDir backed by tmpfs or a node filesystem? - Which resource budget should include its planned data? - Does the node use a documented supported storage layout? - What bounded workload can demonstrate the actual accounting without exhausting the node? ## DSE recommendation: map scratch data to its resource owner DSE recommends a volume worksheet with the workload, volume definition, medium and expected scratch-data envelope. Put the intended memory budget and local-storage budget in different columns. Have the application owner state the required data lifetime and cleanup behavior without treating the word temporary as a sizing decision. Review the node layout with the cluster administrator before interpreting a storage observation. Name the filesystems that hold the scratch volume, container layers and relevant logs. Keep any separately mounted location visible in the review instead of assuming that a familiar directory name establishes supported accounting. Choose proposed limits from the workload requirement and an authorized test envelope. Keep application heap or process-memory demand alongside any planned memory-backed scratch allocation. For disk-backed scratch, include the other in-scope local-storage consumers in the review. Do not transfer a value between the two budgets merely to silence an alert. Agree an observation and stop condition before testing. Use harmless data and a fixed maximum write amount, with the node owner monitoring the selected resource. Preserve an unexpected accounting gap as a finding about the configuration or collector rather than increasing the limit until the symptom disappears. ## Verification and evidence Proposed verification, not performed: prepare two disposable workload definitions that differ only in the reviewed scratch-volume medium and use a small fixed set of harmless files. Write which budget should reflect each case before running it, and inspect the actual node and workload observations through approved tools. Record the volume definition, filesystem layout, amount written, resource observations and cleanup result. Stop before either memory or storage pressure exceeds the approved envelope. Compare an unexplained measurement with the supported-layout review before repeating the test. Accept only the observed medium and node arrangement; keep data durability and application performance under their separate requirements. ## Official references - [Local ephemeral storage](https://kubernetes.io/docs/concepts/storage/ephemeral-storage/) — Kubernetes. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Local ephemeral storage - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/storage/ephemeral-storage/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Budget memory-backed emptyDir separately from local ephemeral storage,” DSE Security, https://update.dsesecurity.com/updates/budget-memory-backed-emptydir-separately-from-local-ephemeral-storage/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.