For Murex Mx.3 operations teams

Murex Mx.3 environments,
as code.

MxENV3 replaces hand-maintained MxENV.csv spreadsheets and MxENV.xml start scripts with plain Ansible inventories and a single Go binary — define a value once, override only what differs, and start, stop and configure every environment from one command line.

  • One static binary
  • Ansible-native inventory
  • No secrets in config
mxenv matrix PROD UAT --diff-only
$ mxenv matrix PROD UAT --diff-only   VARIABLE            PROD                       UAT* db_financial_host   db-prod.example.com        db-uat.example.com* mx_app_dir          /appl/murex/mx3P01/mxenv   /appl/murex/mx3U01/mxenv* mx_domain           prod                       uat* mx_environment      MX3P01                     MX3U01* mx_secret_provider  infisical                  ansible-vault* mx_version          3.1.35r3l                  3.1.26 $ mxenv applyconfig PRODmxenv: refusing to applyconfig the PRODUCTION environment "PROD" without --iknowwhatimdoing

The legacy problem

Every Murex site grew its own environment tooling — and it doesn't scale.

One CSV column per environment

MxENV.csv holds hundreds of variables across dozens of columns. Adding an environment means copying a column; finding a difference means eyeballing cells.

Hand-numbered start sequences

MxENV.xml orders services with <sequence> numbers. Insert one service and you renumber everything — on every environment.

Perl scripts and plaintext passwords

The old tooling shipped as cleartext Perl with database credentials sitting inside the config. Auditors do not like that. Neither do you.

What MxENV3 does

Everything the old mxenv did — engineered properly.

The frontend is a standard Ansible inventory your team already understands. The backend is one compiled binary that parses, compares, renders and orchestrates.

Hierarchical inventory

Global defaults in group_vars/all.yaml, per-environment overrides, per-role and per-host variables. Define once, override only what differs — no more column copying.

Dependency-based start/stop

One YAML file per service with after: dependencies. MxENV3 topologically sorts them into parallel stages and reverses the order for shutdown. Add a service, never renumber.

Version-aware templates

Each environment declares its mx_version. Config templates and service catalogs resolve from a matching directory, so 3.1.26 and 3.1.35 coexist without forks.

Pluggable secrets

Templates reference secrets — {{ secret "DB_PW" }} — and the value is fetched at apply time from Ansible Vault, Infisical or the environment. Nothing sensitive is ever stored in the inventory.

Production guard

Destructive commands refuse to touch a production environment unless --iknowwhatimdoing is given. Read-only commands and dry-runs are always safe to run.

Config matrix & diff

mxenv matrix renders every variable across every environment as an aligned table, CSV or highlighted HTML — differences flagged, --diff-only for what actually changed.

How it works

Three layers, no bespoke config format.

  1. 01

    Describe environments as Ansible inventories

    hosts.yaml groups servers by Murex role (mxsession, mxprocessingscript, xmlserver …). group_vars hold the variables. The same inventory can drive your own Ansible playbooks.

  2. 02

    MxENV3 resolves the hierarchy

    Global defaults → environment → role → host. mxenv get, compare and matrix show you exactly which value wins where — and why.

  3. 03

    Plan, apply, start, stop

    mxenv applyconfig renders version-specific templates into the app dir, applies renames and symlinks. mxenv plan/start/stop orchestrate services over SSH — dry-run by default.

inventory/
  group_vars/all.yaml      # global defaults
  PROD/
    hosts.yaml             # servers grouped by Murex role
    group_vars/all.yaml    # PROD overrides only
  UAT/
  services/
    fs.yaml
    xmls.yaml              # after: [fs]
    mxsession.yaml         # after: [mandatory, rtbs]
  templates/
    3.1.26/start.sh.tmpl
    3.1.35r3l/start.sh.tmpl

The command line

Built for operators, not for slides.

Every command is scriptable and dry-run first. Output is plain text, CSV or HTML — no UI to click through at 3 a.m.

mxenv compare
$ mxenv listPROD             prod     PROD ProductionUAT              uat      SAMPLE UAT $ mxenv get PROD db_financial_hostdb-prod.example.com $ mxenv compare PROD UAT db_financial_hostdb_financial_host        db-prod.example.com      db-uat.example.com       * $ eval "$(mxenv export PROD --shell)"# MX_ENVIRONMENT, MX_HOME, DB_FINANCIAL_HOST … now in your shell

Security & licensing

No source on your hosts. No secrets in your repo.

Compiled, stripped, obfuscated

Clients receive only a static Go binary — symbols stripped, identifiers and string literals obfuscated. Contrast the legacy Perl mxenv whose full source sat in cleartext on every host.

Baked-in license with expiry

Each client build carries LicensedTo and an expiry date at compile time. It cannot be edited in a config file, and a build without an expiry fails closed.

Your vault stays your vault

Database and admin passwords live in your Ansible Vault or Infisical, never in the inventory. Switching vaults is configuration, not code.

Honest threat model

Obfuscation is not encryption. We document exactly what the binary protects against and what it does not — read SECURITY.md before you sign, not after.

FAQ

Questions Murex teams ask first

See MxENV3 on your own inventory.

Send us a sanitised MxENV.csv or a description of your environments and we will show you the equivalent inventory, the config matrix and a start plan — in a 45-minute call.

Request a demo