For banks running Murex Mx.3

Every Murex environment.
Consistent. Auditable. Under control.

MxENV3 manages the configuration of all your Mx.3 environments — production, DR, UAT, SIT, DEV — as code: one place for every setting, differences visible at a glance, start and stop in the right order every time, and no password ever stored in a config file.

Request a demo See how it works

Runs on your hosts, no agents
Standard Ansible inventory format
Integrates with your vault

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

What your Murex team gets

Fewer environment incidents. Faster environment work. Clean audits.

No more silent drift

One command shows every setting that differs between PROD and UAT — before it becomes an incident in the batch or a failed release weekend.

Environment work in hours, not days

New environment, refresh, Murex version move: change a few lines in the inventory, render, apply. The knowledge lives in the repository, not in one engineer's head.

Audit-ready by construction

Configuration is versioned in Git with a full history. Credentials stay in your vault (CyberArk, Ansible Vault, Infisical) and are only resolved at apply time — nothing for an auditor to find in a script.

The everyday reality of Murex operations

Murex Mx.3 is business-critical. The tooling around its environments usually is not.

Environments drift apart

Ten, twenty environments, each configured by hand over the years. Nobody can say with certainty which JVM setting or database host differs between UAT and PROD — until it matters.

Start/stop lives in people's heads

Which service comes after which, what to wait for, which host runs what — encoded in shell scripts and the experience of a few key people. Holidays and turnover become operational risk.

Credentials in scripts

Database and admin passwords in start scripts and config spreadsheets are a recurring audit finding — and a real security exposure on every host they are copied to.

How MxENV3 helps

Built for the way banks actually run Murex.

MxENV3 sits next to Murex Mx.3 — it does not change the application. It takes over the environment configuration, its consistency and the orchestration around it.

One source of truth for every environment

Bank-wide defaults defined once, each environment overrides only what really differs — hosts, database, JVM options, paths. Adding an environment is a few lines, not a copy of a spreadsheet column.

Start and stop in the right order, every time

Services are described with their dependencies; MxENV3 derives the start order, runs independent services in parallel and shuts down in reverse. Dry-run first, then execute over SSH.

Murex upgrades without a config fork

Configuration templates and service catalogs are kept per Murex version. Running 3.1.26 in PROD and 3.1.35 in UAT is normal operation, not a special case.

Your vault stays the only place for secrets

Templates reference a secret by name; the value is fetched from your vault when configuration is applied. Ansible Vault and Infisical today, CyberArk on the roadmap — switching is configuration.

Production is protected

Any command that changes a production environment refuses to run unless explicitly confirmed. Read-only commands and dry-runs are always safe — also for the on-call engineer at 3 a.m.

See all environments at a glance

A configuration matrix — every setting across every environment — as a table, CSV or highlighted HTML report. Show only what differs, hand it to change management or the auditor.

How it works

Three steps, no new proprietary format.

01
Describe your environments
Each environment is a small inventory in the standard Ansible format: servers grouped by Murex role (session, processing, XML server …) plus the settings that differ from the bank-wide defaults. Your team already knows the format.
02
MxENV3 resolves and compares
Defaults, environment, role and host settings are combined into the effective configuration. Query a value, compare two environments, render the full matrix — always with a clear answer which value applies where.
03
Plan, apply, start, stop
Configuration files are rendered for the environment's Murex version and applied to the application directory. Services are planned and started or stopped in dependency order — dry-run by default, execution on request.

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

In practice

Made for operators, not for slide decks.

One command line tool, scriptable, dry-run first. Plain text, CSV or HTML output — the same on the jump host, in a change ticket and in the audit evidence.

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 & compliance

Designed for a regulated environment.

Runs entirely on your infrastructure

MxENV3 is a single, statically compiled binary. No agents, no cloud service, no outbound connections — it runs on your jump host or on the Murex hosts themselves, inside your network perimeter.

Licensed per bank, transparent

Each delivered binary is built for your institution with a license and expiry compiled in. You always know what you run and until when — no license server, no phone-home.

Credentials never leave your vault

MxENV3 stores no secrets. Passwords are referenced by name and resolved from your vault at apply time — the repository, the inventory and the rendered files never contain them in plaintext by design.

Traceable and reviewable

Configuration lives in Git: who changed what, when and why. Every apply is reproducible from the repository, every environment comparison is a report you can attach to a change or an audit request.

FAQ

Questions Murex teams ask first

See MxENV3 on your own environments.

Send us an anonymised overview of your Murex environments — or just the number and the versions — and we will show you the resulting inventory, the configuration matrix and a start plan in a 45-minute session.

Request a demo

Every Murex environment.Consistent. Auditable. Under control.