Administration AI-generated

Instance-wide configuration lives under Settings, separate from any one environment's own settings (see Environments). MockMotor is meant for internal/trusted-network use, not for exposing directly to the public internet.

Hardware sizing

MockMotor is multi-threaded and will use as many CPUs as it's given; since most mocked calls have a configured delay far longer than the actual CPU work they need, a thread releases its CPU early and many more calls can run concurrently than there are cores. As a starting point: roughly 4 CPUs per 100 expected TPS, and roughly 1 MB of RAM per reaction configured on the instance (every reaction's precompiled response lives in memory at all times). In a cluster, each node - admin and every clone - keeps its own full copy of every compiled reaction, so this RAM figure applies per node, not once for the whole fleet.

Installing

Download and unpack the latest release: curl -k https://mockmotor.com/download/latest | tar xvz (or via the download page). This produces mockmotor.jar, a mockmotor.config.xml.template, and the startMockMotor.sh/stopMockMotor.sh/updateMockMotor.sh scripts. The template's defaults are HTTP admin UI on port 7080, HTTPS on 7081, and cluster communication on 7082, with data/logs under the current directory - edit the template before first launch, or the generated config afterward, to change any of that.

Launching & first admin

Start with ./startMockMotor.sh (optionally passing an explicit config file path as an argument) - it runs java -cp mockmotor.jar -c mockmotor.config.xml, auto-generating mockmotor.config.xml from the template on a first run if it doesn't exist yet. By default the JVM claims all available system memory; cap it with export MM_JAVA_OPTIONS=-Xmx32g (or similar) before launching. It looks for Java at $JAVA_HOME/bin/java first, falling back to java on $PATH. Note that running the script again does not stop an already-running instance first - always stopMockMotor.sh before restarting.

Browse to https://hostname:7081/console (it redirects HTTP to HTTPS) - if you can't reach it, check mockmotor.log.0 for the ports actually in use. Accept the self-signed certificate warning (or install your own PEM cert+key under Instance Settings later). The very first user to log in - default username admin, choose your own password on first login - automatically becomes the instance's first admin; set your first/last name afterward so others can identify you.

Stopping & updating

./stopMockMotor.sh kills the running process by the PID recorded in mockmotor.pid (or, failing that, ps -ef | grep mockmotor | grep -v grep | awk '{print $2;}' | xargs kill manually) - there's no separate graceful-drain step. ./updateMockMotor.sh downloads the latest release, unpacks it, and renames the previous jar with a date suffix (e.g. mockmotor.jar.2022-01-25) so you can roll back; it leaves mockmotor.config.xml alone (only the template gets replaced). Stop and restart the process afterward for the update to take effect. In a cluster, always update and restart the admin node first, then every clone.

Instance Settings

• Instance ID / Disk Store Root - identity and where this instance persists its data on disk (read-only, set via config).
• Console HTTP/HTTPS Port - the ports the admin console itself listens on; changeable at runtime (an empty value closes that port), with the UI redirecting immediately once a newly opened port comes up. Host binding is config-file only.
• Private Key and Certificate / Private Key Password - PEM-format TLS identity for HTTPS, or fall back to MockMotor's own self-signed certificate; both fields are hidden from non-admin users, and the certificate field is left blank when a non-admin views the page.
• Logged-in Session Time - how long a login stays valid (defaults to 8 hours).
• Banner Message - an admin-set header shown to everyone, e.g. a maintenance notice or a way to tell instances apart; prefix it with ! to render it with a warning-triangle icon.

Ports Range

When a new environment is created, MockMotor auto-assigns it a free port pair from the configured Lowest/Highest range, so you don't have to track port usage by hand across many environments.

Authentication

Local login always stays available - it can't be turned off. On top of it:

• Active Directory/LDAP - authenticates MockMotor's own users against a real corporate directory (unrelated to LDAP Mode, which is about MockMotor acting as a mock LDAP server, not authenticating against one). Fields: Domain Name (shown in the login dialog), LDAP URL (must be ldaps:// - plain ldap:// isn't supported), Bind DN (a DN template with a {UID} placeholder substituted per login attempt), optional attribute mapping for first name/last name/email (givenName/sn/mail by default), and LDAP MockMotor Admin Groups - comma-separated group names whose members are automatically granted admin rights.
• OAuth 2.0 / OpenID Connect - e.g. Google Workspace sign-in, configured with an issuer URL, client ID/secret, and requested scopes.

Users & access control

Three levels of access, from broadest to narrowest:

• Admin - complete control of the instance: every environment, service and reaction, plus the ability to add/remove attachments and grant admin or owner status to other users.
• Environment Owner - automatically granted to whoever creates an environment (see Environments); can modify that environment and add/remove other owners of it.
• Everyone else - read-only on environments they don't own, though anyone can still clone an environment or service they can't edit (becoming the owner of the clone).

On top of that broad model, each environment also has its own Editors and Account Editors lists - finer-grained access independent of full ownership, so a team can be trusted with an environment's mock accounts without being able to touch its service/reaction definitions, or vice versa. Admins manage user status (e.g. promoting someone to admin) from the Users page. Each user's own account page carries their API key for scripted access - see MCP & REST API.

Customization

The console offers several color themes (Imperial Red, Royal Blue, Dominion Green) each with a dark-mode variant, purely cosmetic and per-user.

Clustering

Scaling out to multiple nodes, cluster join-token security, and clone provisioning have their own page - see Clustering & Clones.