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

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). This discovery phase identifies candidate files using three specific detection heuristics implemented in 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 (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. 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-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:

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

To identify which Kustomize overlay assembles a particular Service:

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
Graph schema and node definitions	src/pipeline/pipeline_internal.h (lines 350-424)
Test coverage for Dockerfile parsing	tests/test_pipeline.c (lines 3838-4082)
Language detection tests	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 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}