Coordimap Configuration Overview

The Coordimap agent reads a YAML configuration file that tells it which systems to crawl and how those systems should be identified.

At a minimum, each data source configuration should answer two questions:

1. Which Coordimap connector record should this crawler write into?
2. Which real upstream system owns the assets being discovered?

Important Note About id vs data_source_id

If you look at some current agent repository examples, you may still see datasource examples written with id.

For Coordimap docs, prefer data_source_id when describing the agent configuration contract because that is the field used in the runtime payload model and in current validation and error paths.

If you are working from older examples, verify the expected field in your deployed agent version before copying them directly into production configuration.

How Identity Works In Coordimap

Coordimap uses two different identifiers for two different jobs:

• data_source_id identifies the data source record you created in the Coordimap UI.
• scope_id identifies the real upstream ownership boundary for the assets.

This is the most important configuration detail to get right.

If you recreate a data source in Coordimap but keep the same scope_id, Coordimap can continue to treat the discovered assets as the same infrastructure. If scope_id changes when the upstream system did not, you usually end up with duplicate assets, broken references, or flow mappings that no longer attach cleanly.

Read the full reference here: Shared Configuration Options.

Recommended scope_id Values

• Kubernetes: cluster UID
• GCP: project number
• AWS: account ID
• PostgreSQL: system identifier
• MySQL or MariaDB: server UUID
• MongoDB: replica set or cluster identity

A Minimal Agent Configuration Example

coordimap:
  api_key: ${COORDIMAP_API_KEY}
  data_sources:
    - type: kubernetes
      data_source_id: <YOUR_DATASOURCE_ID_FROM_UI>
      config:
        - name: scope_id
          value: "<YOUR_STABLE_UPSTREAM_ID>"
        - name: crawl_interval
          value: "5m"

Data Source Guides

• Shared Configuration Options
• Kubernetes Configuration
• Google Cloud Platform Configuration
• AWS Configuration
• AWS Flow Logs Configuration
• PostgreSQL Configuration
• MySQL and MariaDB Configuration
• MongoDB Configuration

Environment Variables

Use environment variables for secrets and credentials whenever possible.

Examples:

• COORDIMAP_API_KEY
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• POSTGRES_PASSWORD

That keeps your configuration portable and prevents secrets from being committed into source control.