# Keep component path context explicit with Compose include > Compose include gives each component its own project directory for relative paths. Review that context and the override layer when assembling a modular application. - Canonical URL: https://update.dsesecurity.com/updates/keep-component-path-context-explicit-with-compose-include/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:09:45+00:00 - Modified: 2026-10-29T00:10:35+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: IT - Reading time: 3 minutes ## What you need to know Compose include gives each component its own project directory for relative paths. Review that context and the override layer when assembling a modular application. ## Potentially affected Review scope: the documented include workflow requiring Docker Compose 2.20.3 or later; component trust and application compatibility remain separate decisions. ## DSE recommendation Map each included file to its own project directory and inspect the assembled model, with resource conflicts and intentional override layers identified. ## Article Bottom line: Review a component Compose file in the directory context that should interpret its paths. Keep that context visible when several teams assemble one application, and distinguish inclusion from an intentional override of the assembled model. ## Source fact: documented behavior The [Include](https://docs.docker.com/compose/how-tos/multiple-compose-files/include/) documentation is the primary reference. The include documentation requires Compose 2.20.3 or later and loads each included application with its own project directory for relative paths. Included resources are copied into the current application model, and include applies recursively. The guide distinguishes include resource-conflict errors from the separate global override that can adjust the resulting model. ## What the source does not establish This article concerns the documented include model and path context. It does not approve a remote component, make its application compatible or define every merge rule. Review source trust and requested customization independently. Do not treat a successful file load as acceptance of the resulting service configuration. ## Applicability questions - Which included file and project directory own each relative path? - Are further files included by a component itself? - Which resource names could conflict when the models are assembled? - Where is an intentional customization applied and reviewed? ## DSE recommendation: map the component boundary before customization DSE recommends a component map listing each included file, its responsible team and expected project directory. For every path important to the exercise, write the intended resolved file or directory beside the component entry. Use harmless lab paths in shared review examples. Inspect the inclusion chain as part of that map. Follow nested includes and identify the actual source revisions used by the assembled application. Keep an included building block separate from the main application’s choice to depend on it. A reviewer should be able to trace a resource to its component without searching several unrelated repositories. Make customizations explicit. Decide whether the documented dedicated override for an include or the global override layer expresses the intended change. Record that choice with the expected resulting resource. Investigate a resource-name conflict instead of solving it by renaming or duplicating definitions without a clear ownership decision. Check path context and changed values separately. Confirm the intended component files are used, then review the resulting service settings. Keep environment-precedence and exposed-port reviews distinct from this path-ownership question. Those checks may be required for the assembled application, but none should conceal which directory supplied a file. ## Verification and evidence Proposed verification, not performed: prepare two harmless component directories with distinct resource names and a recognizable local file in each. Assemble them through the documented include structure and inspect the model using the installed version’s documented workflow. Compare each important relative path with the component map. Use a separate deliberate resource-conflict case to examine error handling. Then test one explicitly reviewed customization through the chosen override layer, retaining the original component definition. Record the actual result of each case without reporting the proposed inputs as observations. Keep source revisions, include chain, directory map, selected override and assembled model together for another operator to reconstruct. ## Official references - [Include](https://docs.docker.com/compose/how-tos/multiple-compose-files/include/) — Docker Docs. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Docker Docs — Include - Authority: docs.docker.com - URL: https://docs.docker.com/compose/how-tos/multiple-compose-files/include/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep component path context explicit with Compose include,” DSE Security, https://update.dsesecurity.com/updates/keep-component-path-context-explicit-with-compose-include/ 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.