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 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. These files also includes a timestamp comment.

3a. deployment.properties

Purpose: Stores deployment-time properties which are set via Runtime Manager UI. These properties are available for resolution within the application.

Example content:

#deployment properties
#Thu Jul 09 01:36:16 IST 2026
anypoint.platform.client_id=abc123
anypoint.platform.client_secret=xyz789

When Mule writes it: 

• At application deployment time
• When properties are updated via Runtime Manager UI and application is redeployed

When Mule reads it: 

• During property resolution when the application references ${propertyName}  or p('propertyName') in flows or configuration
• At application startup to restore deployment configuration

Behavior if deleted:

• If deleted while the runtime is running, property resolution for UI-set and CLI properties may fail until the app is redeployed
• Application-bundled property files continue to work normally (not affected)
• Properties set via Runtime Manager UI are not lost — they persist in the control plane and repopulate on redeploy

3b. flows.deployment.properties

Purpose: Tracks the individual start/stop preference for each flow within the deployed application. This file is used by the Mule Runtime to determine whether a specific flow should be started automatically on deployment, and persists any flow-level start/stop changes made via Runtime Manager.

Format: One entry per flow, following the pattern <flowName>_startFlowOnDeployment=true|false.

Example content:

#deployment properties 
#Fri Jul 18 18:55:28 IST 2025 
test-app-flow_startFlowOnDeployment=true

When Mule writes it: Each time a flow's running state is changed through the Runtime Manager UI(Runtime Manager->Application->Flows Tab).

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.

3c. artifact.status.deployment.properties

Purpose: Controls the application's auto-start behavior on deployment and restart.

Format: Single property — startArtifactOnDeployment=true|false

Example content: 

#deployment properties
#Thu Jul 09 01:36:16 IST 2026
startArtifactOnDeployment=true

When Mule writes it: Only after the application's running state is explicitly changed via Runtime Manager or the ARM API. A freshly deployed application that has never been stopped through ARM will not have this file.

When Mule reads it: At Mule runtime startup and during hot-deployment to determine whether the application should auto-start.

Behavior if deleted or corrupted:

• Mule defaults to startArtifactOnDeployment=true and application will auto-start on next deployment or restart
• Can cause application state in Runtime Manager to not match actual runtime state

Note: This file's behavior is based on observed runtime patterns. Do not modify this file manually — use Runtime Manager UI or runtime API to control application start/stop state.

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.