maxicfg

Overview

maxicfg reads configuration files, checks them against a schema and compares them across environments. It is a single static binary with no runtime dependencies.

Core concepts

Sources

A source is any file maxicfg can read. Supported formats are YAML, TOML, JSON, dotenv and INI. Format is detected by extension, and can be forced with --format when the extension is misleading.

Schema

A schema declares which keys are allowed, which are required, and what type each value should have. Schemas are themselves YAML files — there is no separate schema language to learn. 

keys:
  database.host:      { type: string, required: true }
  database.port:      { type: int, default: 5432, min: 1, max: 65535 }
  database.pool_size: { type: int, default: 10 }
  logging.level:      { type: enum, values: [debug, info, warn, error] }
  features.*:         { type: bool }

Profiles

A profile is a named group of sources — typically one per environment. Profiles let you run a single command against every environment instead of scripting a loop.

Typical workflow

  1. Write a schema describing the configuration your service expects.
  2. Run maxicfg lint in CI so invalid configs never merge.
  3. Run maxicfg diff before a release to review what changed.
  4. Run maxicfg scan to make sure no secrets slipped into git.

What it does not do

maxicfg is deliberately narrow. It does not manage secrets, does not talk to remote configuration stores, does not deploy anything and does not run as a daemon. It reads files, prints findings and sets an exit code.

If you need dynamic configuration at runtime, use a configuration service. maxicfg is for the files sitting in your repository.

Next steps