# How Codebase-Memory-MCP Handles Infrastructure-as-Code Indexing for Kubernetes and Dockerfiles

> Discover how Codebase-Memory-MCP indexes infrastructure-as-code by parsing Dockerfiles and Kubernetes manifests into graph nodes and relationships, streamlining your IaC management.

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

---

**Codebase-Memory-MCP treats infrastructure-as-code files as first-class graph nodes, using a dedicated pipeline pass to parse Dockerfiles with a lightweight scanner and Kubernetes manifests with a tree-sitter-yaml grammar, then linking them via typed nodes and relationship edges.**

The `codebase-memory-mcp` repository implements a specialized **infrastructure-as-code indexing** pipeline that transforms Dockerfiles and Kubernetes manifests into queryable graph entities. Unlike traditional code indexing tools that focus solely on source code, this engine performs dedicated passes to extract structural metadata from IaC files, enabling precise dependency queries across container images and cluster resources.

## Dockerfile Parsing and Graph Representation

### Detection and Parsing Strategy

The indexing pipeline identifies Dockerfiles through the `cbm_is_dockerfile()` function located in [`src/pipeline/pass_infrascan.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_infrascan.c). This matcher recognizes files named exactly `Dockerfile` or bearing the `.dockerfile` extension.

Rather than importing external dependencies, the engine employs a lightweight handwritten parser that processes the file line-by-line. This scanner extracts top-level directives including `FROM`, `RUN`, `ENV`, `CMD`, `ENTRYPOINT`, and `EXPOSE`. The parser normalizes whitespace, strips bracket syntax, and automatically discards secret-related environment variables to prevent credential leakage into the graph.

### Graph Nodes and Relationships

Each parsed Dockerfile generates a **`DockerImage`** node containing properties such as `base_image`, `env`, and `cmd`. When the parser encounters `COPY` or `ADD` directives referencing local paths, the system creates **`IMPORTS`** edges linking the Docker image node to the corresponding source file nodes. This enables queries that trace which source files contribute to a specific container image.

## Kubernetes Manifest Indexing

### YAML Detection and Validation

Kubernetes manifests are detected via the generic YAML scanner `cbm_is_yaml_file()` in [`src/pipeline/pass_infrascan.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_infrascan.c). The pipeline validates candidate files by checking for the presence of top-level `apiVersion` and `kind` fields—a heuristic that distinguishes K8s resources from arbitrary YAML documents.

The parser leverages the vendored **tree-sitter-yaml** grammar already embedded in the binary. After building the AST, the walker extracts `kind`, `apiVersion`, `metadata.name`, `metadata.namespace`, and relevant `spec` sections.

### Resource Nodes and Cross-References

Each manifest instantiates a **`Resource`** node typed by its Kubernetes kind (e.g., `Deployment`, `Service`, `ConfigMap`). The node stores the resource name, namespace, and a snapshot of the raw specification.

Cross-resource references—such as a `Deployment` using `envFrom` to reference a `ConfigMap`—are modeled as **`USES`** edges. This relationship mapping supports complex graph queries, including "which Deployments depend on a given ConfigMap?".

## Kustomize Overlay Support

### Overlay Detection and Module Creation

For Kustomize-based workflows, the function `cbm_is_kustomize_file()` identifies directories containing [`kustomization.yaml`](https://github.com/DeusData/codebase-memory-mcp/blob/main/kustomization.yaml) or [`kustomization.yml`](https://github.com/DeusData/codebase-memory-mcp/blob/main/kustomization.yml). The parser extracts the `resources`, `bases`, `patchesStrategicMerge`, and `configMapGenerator` fields from these overlay files.

Each overlay creates a **`Module`** node representing the Kustomize configuration. The system establishes **`IMPORTS`** edges from the Module node to every file listed under `resources` or `bases`, preserving the overlay-to-resource relationship for dependency analysis.

## The Three-Stage Pipeline

The infrastructure-as-code indexing operates across three distinct stages:

1. **Filesystem walk** – The `cbm_walk_fs()` function (defined in [`src/pipeline/pipeline_internal.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pipeline_internal.h)) discovers all candidate files, including Dockerfiles, `.env` files, shell scripts, and YAML documents.

2. **Language pass** – Files route to the "infra-pass," which reuses the existing tree-sitter-yaml grammar for Kubernetes and Kustomize files while applying the custom Dockerfile scanner.

3. **Graph construction** – Parsed data converts into SQLite-backed nodes and edges. Nodes are typed (`DockerImage`, `Resource`, `Module`) and enriched with properties extracted from the source files.

Because Dockerfiles and Kubernetes manifests share no additional external grammar dependencies, the binary remains zero-dependency while maintaining indexing speeds measured in milliseconds per file.

## Querying IaC Entities

The following examples demonstrate how to query the indexed infrastructure:

**Query all Deployments referencing a specific ConfigMap** (C API):

```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);

```

**List every Docker image with its base image** (CLI):

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

```

**Find the Kustomize overlay that builds a specific Service** (CLI):

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

```

## Summary

- **Dockerfiles** are detected by name or extension in [`src/pipeline/pass_infrascan.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_infrascan.c) and parsed line-by-line to create `DockerImage` nodes with `IMPORTS` edges for local file references.
- **Kubernetes manifests** are validated via `apiVersion`/`kind` checks, parsed with tree-sitter-yaml, and represented as `Resource` nodes with `USES` edges linking dependent resources.
- **Kustomize overlays** generate `Module` nodes that connect to their constituent resources via `IMPORTS` edges.
- The pipeline executes in three stages—filesystem walk, language pass, and graph construction—maintaining sub-millisecond performance per file without external dependencies.

## Frequently Asked Questions

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

The scanner `cbm_is_yaml_file()` in [`src/pipeline/pass_infrascan.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_infrascan.c) validates YAML files by checking for the presence of both `apiVersion` and `kind` fields at the document root. Only files satisfying this criteria are processed as Kubernetes resources and converted to `Resource` nodes.

### Which Dockerfile directives are extracted during parsing?

The handwritten parser extracts `FROM`, `RUN`, `ENV`, `CMD`, `ENTRYPOINT`, `EXPOSE`, `COPY`, and `ADD` directives. The parser stores these as properties on the `DockerImage` node and specifically tracks `COPY`/`ADD` paths to create `IMPORTS` relationships with source files.

### How are relationships between Kubernetes resources tracked?

Cross-resource references identified within `spec` sections—such as environment variables sourced from ConfigMaps or Secrets—are modeled as **`USES`** edges in the graph. This allows the query engine to traverse dependencies and identify which deployments rely on specific configuration resources.

### Does the tool support Kustomize overlays?

Yes. The system detects [`kustomization.yaml`](https://github.com/DeusData/codebase-memory-mcp/blob/main/kustomization.yaml) files via `cbm_is_kustomize_file()` and creates `Module` nodes representing each overlay. Fields such as `resources`, `bases`, and `patchesStrategicMerge` are parsed to establish `IMPORTS` edges, enabling queries that trace which overlay assembles a given deployment or service.