# How Codebase-Memory-MCP Handles Infrastructure-as-Code Indexing for Docker, Kubernetes, and Kustomize

> Discover how Codebase-Memory-MCP indexes Infrastructure-as-Code for Docker Kubernetes and Kustomize treating them as graph nodes for detailed analysis.

- Repository: [Martin Vogel/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp)
- Tags: how-to-guide
- Published: 2026-07-22

---

**Codebase-Memory-MCP treats Dockerfiles, Kubernetes manifests, and Kustomize overlays as first-class graph nodes**, parsing them through dedicated detection functions and representing them as typed nodes with relationship edges in a SQLite-backed graph.

The open-source **codebase-memory-mcp** repository implements a specialized indexing pipeline that transforms static IaC files into queryable graph structures. Unlike traditional code search tools that treat infrastructure files as plain text, this engine extracts semantic relationships—such as a Deployment referencing a ConfigMap or a Kustomize overlay importing specific resources—enabling precise, structure-aware queries across your infrastructure code.

## Detection and Discovery

The indexing process begins with a filesystem walk performed by `cbm_walk_fs()` (defined in [`src/pipeline/pipeline_internal.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pipeline_internal.h)). This discovery phase identifies candidate files using three specific detection heuristics implemented in [`src/pipeline/pass_infrascan.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_infrascan.c):

- **Dockerfile detection** – The function `cbm_is_dockerfile()` recognizes files literally named `Dockerfile` or bearing the `.dockerfile` extension.

- **Kubernetes manifest detection** – The generic YAML scanner `cbm_is_yaml_file()` validates all `.yaml` and `.yml` files, subsequently filtering for documents containing both `apiVersion` and `kind` top-level fields to distinguish K8s resources from configuration files.

- **Kustomize overlay detection** – The function `cbm_is_kustomize_file()` identifies directories containing a [`kustomization.yaml`](https://github.com/DeusData/codebase-memory-mcp/blob/main/kustomization.yaml) (or `.yml`) manifest, flagging the entire directory as an overlay module.

## Parsing Strategies

Once detected, files enter language-specific parsing passes that extract structural information without requiring external dependencies.

### Dockerfile Parsing

A lightweight, handwritten parser processes Dockerfiles line-by-line in [`pass_infrascan.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/pass_infrascan.c). The scanner strips bracket syntax, normalizes whitespace, and extracts top-level directives including `FROM`, `RUN`, `ENV`, `CMD`, `ENTRYPOINT`, and `EXPOSE`. Security-conscious filtering automatically redacts secret-related environment variables from the graph.

When the parser encounters `COPY` or `ADD` directives referencing local paths, it records these relationships for later edge construction.

### Kubernetes and Kustomize Parsing

Both Kubernetes manifests and Kustomize configuration files leverage the vendored **tree-sitter-yaml** grammar already embedded in the binary. After AST construction, the code walks the tree to extract:

- Resource identifiers: `kind`, `apiVersion`, `metadata.name`, `metadata.namespace`
- Cross-resource references within `spec` sections (e.g., `envFrom` pointing to `ConfigMap` or `Secret` objects)
- Kustomize-specific fields: `resources`, `bases`, `patchesStrategicMerge`, and `configMapGenerator`

This approach ensures zero-dependency operation while maintaining parsing speeds measured in milliseconds per file.

## Graph Representation

Parsed IaC artifacts are converted into strongly-typed nodes stored in SQLite with specific schemas:

- **DockerImage nodes** – Created for each Dockerfile, annotated with properties such as `base_image`, `env`, and `cmd`.

- **Resource nodes** – Typed by Kubernetes `kind` (e.g., `Deployment`, `Service`, `ConfigMap`), containing `name`, `namespace`, and raw spec snapshots.

- **Module nodes** – Represent Kustomize overlays, capturing the directory context and composition metadata.

The graph construction phase adds relationship edges between these nodes:

- **IMPORTS edges** – Connect DockerImages to source files referenced by `COPY`/`ADD` directives, or link Kustomize Modules to their constituent resource files.

- **USES edges** – Bridge Resource nodes when a Kubernetes manifest references another resource (e.g., a Deployment using environment variables from a ConfigMap).

## Querying IaC Relationships

The graph structure enables precise queries across infrastructure boundaries using the project's query API or CLI.

To find all Deployments referencing a specific ConfigMap:

```c
/* C-API example (pseudo-code) */
cbm_query_t *q = cbm_query_new(
    "MATCH (d:Resource {kind:'Deployment'})-[:USES]->(c:Resource {kind:'ConfigMap', name:$cfg}) RETURN d.name",
    cbm_param("cfg", "my-config")
);
cbm_result_t *r = cbm_query_execute(q);

```

To list every Docker image with its base image and command:

```bash
codebase-memory-mcp query \
  "MATCH (d:DockerImage) RETURN d.path, d.base_image, d.cmd"

```

To identify which Kustomize overlay assembles a particular Service:

```bash
codebase-memory-mcp query \
  "MATCH (m:Module)-[:IMPORTS]->(s:Resource {kind:'Service', name:'my-svc'}) RETURN m.path"

```

## Implementation Files

The following source files contain the core IaC indexing logic:

| Component | Path |
|-----------|------|
| Detection functions (`cbm_is_dockerfile`, `cbm_is_yaml_file`, `cbm_is_kustomize_file`) | [`src/pipeline/pass_infrascan.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_infrascan.c) |
| Graph schema and node definitions | [`src/pipeline/pipeline_internal.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pipeline_internal.h) (lines 350-424) |
| Test coverage for Dockerfile parsing | [`tests/test_pipeline.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/tests/test_pipeline.c) (lines 3838-4082) |
| Language detection tests | [`tests/test_language.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/tests/test_language.c) (line 496) |

## Summary

- **Codebase-Memory-MCP** indexes Infrastructure-as-Code files as native graph entities rather than plain text.
- **Dockerfiles** are parsed using a custom line-by-line scanner that extracts directives and links `COPY`/`ADD` references to source files via **IMPORTS** edges.
- **Kubernetes manifests** are identified by the presence of `apiVersion` and `kind` fields, parsed with the vendored tree-sitter-yaml grammar, and represented as **Resource** nodes with **USES** edges for cross-resource dependencies.
- **Kustomize overlays** are detected via [`kustomization.yaml`](https://github.com/DeusData/codebase-memory-mcp/blob/main/kustomization.yaml) files and modeled as **Module** nodes that import their constituent resources.
- All IaC processing occurs within a three-stage pipeline (filesystem walk, language parsing, graph construction) that maintains millisecond-level performance per file.

## Frequently Asked Questions

### How does the indexer distinguish between regular YAML files and Kubernetes manifests?

The `cbm_is_yaml_file()` function scans all `.yaml` and `.yml` files, but only those containing both top-level `apiVersion` and `kind` fields are promoted to Kubernetes **Resource** nodes. Documents lacking these fields are either treated as generic configuration or passed to other language handlers.

### What Dockerfile directives are extracted during the parsing phase?

The handwritten parser extracts `FROM`, `RUN`, `ENV`, `CMD`, `ENTRYPOINT`, `EXPOSE`, `COPY`, and `ADD` directives. Local path references in `COPY` and `ADD` instructions generate **IMPORTS** edges to corresponding source files, while secret-related environment variables are filtered out automatically.

### How are relationships tracked between Kustomize overlays and Kubernetes resources?

Each Kustomize directory generates a **Module** node. Files listed under the `resources`, `bases`, or `configMapGenerator` fields in [`kustomization.yaml`](https://github.com/DeusData/codebase-memory-mcp/blob/main/kustomization.yaml) receive **IMPORTS** edges from the overlay node. This graph structure allows queries to traverse from a specific Service or Deployment back to the overlay that composes it.

### Can the graph database answer cross-reference queries between ConfigMaps and Deployments?

Yes. When a Deployment manifest references a ConfigMap (for example, via `envFrom` or volume mounts), the indexing pipeline creates a **USES** edge connecting the Deployment **Resource** node to the ConfigMap **Resource** node. This enables graph queries to identify all Deployments dependent on a specific ConfigMap or Secret.