Mule 4 Standalone Runtime: Configuration Settings, Folder Structure, and Deployment Properties

1. Runtime Configuration Files Overview

Note: Any change to wrapper.conf or scheduler-conf.properties requires a full Mule runtime restart to take effect.

2. The .mule Folder : Structure and Purpose

The .mule folder exists at two levels:

• Runtime level: $MULE_HOME/.mule/  :— cluster config, runtime-wide state
• Application level: $MULE_HOME/.mule/<app-name> :— per-app state, Object Store data, deployment properties

Application-level .mule Folder Contents

  $MULE_HOME/.mule/<app-name>
  ├── deployment-properties/
  │   ├── artifact.status.deployment.properties
  │   ├── deployment.properties
  │   └── flows.deployment.properties
  ├── objectstore/
  │   └── <store-name>/     <-- Persisted Object Store data
  └── (other app-specific runtime state)
  

What to Delete vs. What to Preserve

Do not delete the entire .mule folder for maintenance or upgrade purposes if applications rely on persisted Object Store data. Target specific subfolders instead.

3. Deployment Properties Files : Detailed Reference

Location: $MULE_HOME/.mule/<app-name>/deployment-properties/

These three files are runtime-generated and runtime-managed. They are not packaged inside the application JAR. Mule writes and reads them automatically as part of application lifecycle management.

3a. deployment.properties

Purpose: Stores the runtime-resolved snapshot of deployment-time properties for the application.

Example content:

  anypoint.platform.client_id=abc123
  anypoint.platform.client_secret=xyz789
  api.name=my-api
  api.version=v1
  

When Mule writes it: At application deployment time, combining properties from the control plane, command line, and app-bundled files into a single resolved snapshot.

When Mule reads it: During property resolution for the running application and on restart to restore deployment configuration.

Behavior if deleted:

• Mule regenerates the file on next full redeployment.
• If deleted while the runtime is running, property resolution may fail until the app is redeployed.
• For ARM-managed runtimes, control plane properties will be re-pushed on next sync.

3b. flows.deployment.properties

Purpose: Tracks the start/stop state of individual flows within the application. This is the mechanism that persists flow-level start/stop changes made via Runtime Manager or the Mule Runtime API.

Example content:

status=started

When Mule writes it: Each time a flow's running state is changed — either through the Runtime Manager UI, the ARM API, or the local Mule runtime API.

When Mule reads it: At application startup — Mule restores each flow to its last known state. A flow that was stopped before a restart remains stopped after restart.

Behavior if deleted:

• All flows default to started state on next application startup.
• Any individually configured flow stop states are permanently lost.
• No error is thrown — the missing file is treated as "all flows start normally."

3c. artifact.status.deployment.properties

Purpose: Tracks the overall deployment lifecycle status of the application artifact.

Example content:

status=STARTED

Possible status values:

When Mule writes it: As the application transitions through lifecycle states — deploying → started, started → stopped, any state → failed.

When Mule reads it: At Mule runtime startup, to distinguish between applications that were intentionally stopped and those that failed.

Behavior if deleted or corrupted:

• Mule cannot correctly restore the application's prior lifecycle state.
• An intentionally stopped app may attempt to start automatically after restart.
• A previously failed app may not be correctly reported as failed in monitoring.
• Can cause app state in Runtime Manager to not match actual runtime state.

Note: artifact.status.deployment.properties has no official public MuleSoft documentation by name. Its behavior is based on runtime internals, naming convention analysis, and support case patterns. Do not modify this file manually.

Deployment Properties Files

4.Anchor Files 

Location: $MULE_HOME/apps/

Each deployed application has a corresponding anchor file (e.g., my-app-anchor.txt) in the apps directory.

Purpose: Signals to the Mule hot-deployment layer that the application is active and should remain deployed.

Deleting an Anchor File to Undeploy an App

Deleting the anchor file is the recommended method for undeploying an application from a standalone runtime:

rm $MULE_HOME/apps/my-app-anchor.txt

The runtime detects the missing anchor and initiates a clean, graceful shutdown and undeployment of the application. The application folder is removed by the runtime only after the app has fully terminated.

Why this is preferred over deleting the app folder directly:

• Avoids JAR file locking issues (especially on Windows).
• Prevents race conditions with the hot-deployment watcher.
• Ensures a clean shutdown sequence: resources, connections, and schedulers are properly released.

5. Troubleshooting Guidance

App Stuck in Wrong State After Restart

1. Check artifact.status.deployment.properties : verify the status value matches the expected state.
2. Check flows.deployment.properties: verify per-flow states are correct.
3. Do not edit these files manually unless directed by MuleSoft Support.
4. Redeploy the application to regenerate all deployment-properties files cleanly.

Property Values Not Resolving Correctly

1. Check deployment.properties: verify the resolved values are what you expect.
2. Review the property precedence order in Section 4.
3. For ARM-managed runtimes, check the Runtime Manager UI:  control plane properties override all local values.
4. Check mule_ee.log for messages indicating which property values are being used at deployment time.