Fast MongoDB Launcher - A convenience interface for managing multiple local MongoDB instances. Uses aliases and a configuration file to manage instances.

• jq - JSON processor
• m - MongoDB version manager
• mrun - MongoDB cluster launcher (the standalone successor to mlaunch)
• mongosh - MongoDB shell

• mongodump / mongorestore - For dump, restore, and dump_restore commands
• mongoexport - For the export command

fml looks for its JSON configuration file in this order:

1. $FML_CONFIG, if set (explicit override)
2. $XDG_CONFIG_HOME/fml/config.json (defaults to ~/.config/fml/config.json)
3. The legacy ~/fml/fml_config.json, if it still exists

New installs should use ~/.config/fml/config.json. The legacy path is still honored so existing machines keep working until you move their config over:

mkdir -p ~/.config/fml
mv ~/fml/fml_config.json ~/.config/fml/config.json

{
  "test7": {
    "directory": "mrundata/test7",
    "startPort": 27000,
    "mongoVersion": "7.0.9",
    "initArgs": "--replicaset",
    "connectionString": "mongodb://localhost:27000,localhost:27001,localhost:27002",
    "comment": "Test replica set on MongoDB 7.0"
  },
  "standalone": {
    "directory": "mrundata/standalone",
    "startPort": 27017,
    "mongoVersion": "6.0.15",
    "initArgs": "--single",
    "connectionString": "mongodb://localhost:27017",
    "comment": "Single node for quick tests"
  },
  "sharded": {
    "directory": "mrundata/sharded",
    "startPort": 27100,
    "mongoVersion": "7.0.9",
    "initArgs": "--replicaset --sharded 2",
    "connectionString": "mongodb://localhost:27100",
    "comment": "Sharded cluster with 2 shards"
  },
  "test_latest": {
    "directory": "mrundata/test_latest",
    "startPort": 27200,
    "mongoVersion": "8.3.2",
    "upgradePolicy": "*",
    "initArgs": "--single",
    "connectionString": "mongodb://localhost:27200",
    "comment": "Tracks the latest installed MongoDB across all majors"
  }
}

fml upgrade <alias> and fml upgrade --all look up the highest installed MongoDB version that matches the alias's upgradePolicy and upgrade to it. "Installed" means what m shows on this machine — fml will never pick a version m doesn't have, so the binaries you maintain are the candidate set.

Pre-releases (versions containing -, e.g. 8.4.0-rc1) are always excluded from auto-selection. You can still pin to one with the explicit 2-arg form.

The typical flow on a machine that auto-upgrades:

# Keep the m-managed binaries fresh (your existing daily script)
m 8.2 && m 8.3 && m 9.0

# Roll fml-managed clusters forward to match
fml upgrade --all

1. Install the core dependencies (jq, m, mrun, mongosh)
2. Source the script in your shell profile:

# Add to ~/.bashrc or ~/.zshrc
source /path/to/fml.sh

3. Create your configuration file at ~/fml/fml_config.json

# Initialize a new cluster (installs MongoDB version if needed)
fml init myproject

# Start an existing cluster
fml start myproject

# Stop a running cluster
fml stop myproject

# Open a mongosh session
fml sh myproject

# Run a quick eval command
fml eval myproject 'db.version()'

# Stop and delete data directory
fml cleanup myproject

# Stop, delete, and reinitialize
fml reinit myproject

# Upgrade MongoDB version (e.g., 7.0.9 to 7.0.12)
fml upgrade myproject 7.0.12

# Dump all databases
fml dump myproject

# Dump with additional mongodump options
fml dump myproject --db=testdb --out=/tmp/backup

# Restore data
fml restore myproject --dir=/tmp/backup

# Copy all data from one cluster to another
fml dump_restore source_alias target_alias

# Export a collection to JSON
fml export myproject mydb mycollection /tmp/data.json

# List all running instances
fml list

# Show full configuration
fml config

# Show help
fml help

Many commands accept either an alias or a connection string:

# Connect to a remote cluster
fml sh mongodb://user:pass@remote-host:27017

# Dump from remote, restore to local
fml dump_restore mongodb://remote:27017 local_alias

If you have data directories that were initialized by mlaunch (the predecessor to mrun), run:

# One alias at a time
fml migrate myproject

# Or every pending alias
fml migrate --all

This renames .mlaunch_startup to .mrun_startup in each data directory. The two tools use the same startup-file schema, so no data is touched and the migration is safe on a running cluster. After migrating, fml start/stop/etc. operate via mrun.

fml includes bash autocompletion support. After sourcing the script, tab completion will suggest:

• Commands after fml
• Appropriate aliases based on context (running, stopped, initialized, etc.)

The script also provides standalone helper functions:

# List MongoDB processes
psgm    # All MongoDB processes
psgmd   # mongod processes only
psgms   # mongos processes only

# Kill MongoDB processes
killmongod    # Kill all mongod processes
killmongos    # Kill all mongos processes
killmongo     # Kill all MongoDB processes

A bash-only test suite lives under tests/. It exercises the pure-bash helpers (fml_conf_var, _fml_running_ports, fml_delete_dir, fml_migrate_one, dispatcher exit codes, etc.) with mocked process listings, so no real mongod is required.

bash tests/run.sh

Note: fml init exports M_CONFIRM=0 to suppress m's install-confirmation prompt. The export persists for the rest of the shell session.