Deploy MuleSoft ESB | (Just Updated) Mule 4 Runtime With Deploy API, Apps Survive Redeploys

Deploy and Host MuleSoft ESB on Railway

Built for an LLM agent to deploy and use. The deploy form has no fields. The Mule 4 runtime comes up with an authenticated REST API for deploying and removing integration applications, a volume that keeps them across redeploys, and a public gateway to their HTTP endpoints. The contract below lists every address, variable name and one script that deploys a sample application and calls it.

MuleSoft ESB here is Mule Runtime Community Edition 4.12.0, the open-source Mule 4 engine for building integration flows between APIs, databases, queues and files. The Community Edition ships no deployment API (that is Anypoint Runtime Manager, an Enterprise product), so this template adds a small authenticated admin front beside the runtime.

About Hosting MuleSoft ESB

This template runs one service from a wrapper image pinned by digest. It starts the Mule runtime and a small admin server on Railway's port. Applications are Mule archives built with mule-maven-plugin (the -mule-application.jar file); you send one with a single PUT and the runtime hot-deploys it, and a DELETE undeploys it. Applications are stored on the volume at /data/apps, so they come back after every redeploy. Applications declare their HTTP listener on port 8081 and are reachable through the public gateway at /gateway/ followed by the listener path. The admin token MULE_ADMIN_TOKEN is generated for you at deploy time. The runtime keeps about 1.2 GB of memory in use when idle, so size the service for at least 2 GB.

Agent contract

• Public URL: MULE_PUBLIC_URL (https:// plus the service's RAILWAY_PUBLIC_DOMAIN). Applications are served at /gateway/ followed by the application's listener path.
• Private URL: http://mule.railway.internal:8080 (also MULE_PRIVATE_URL) for the admin API and gateway; applications listen on http://mule.railway.internal:8081 directly for other services in the project.
• Credentials: MULE_ADMIN_TOKEN (generated, 48 characters).
• Auth: send Authorization: Bearer $MULE_ADMIN_TOKEN on every /admin/apps call. /health and /gateway/* need no credentials (an application can add its own).
• Health: GET /health returns 200 with {"status":"UP","runtime":"4.12.0"}.
• Admin API: GET /admin/apps lists deployed application names, PUT /admin/apps/{name} deploys the request body as application {name} (name matches [A-Za-z0-9_-]{1,64}; a second PUT of the same name redeploys it), DELETE /admin/apps/{name} undeploys it.

# needs: MULE_PUBLIC_URL and MULE_ADMIN_TOKEN from the mule service variables
curl -s -o /dev/null -w "health: %{http_code}\n" "$MULE_PUBLIC_URL/health"
curl -s -o /dev/null -w "no token: %{http_code}\n" "$MULE_PUBLIC_URL/admin/apps"
curl -sL -o hello-esb.jar https://github.com/bon5co/mule-railway/releases/download/v4.12.0/hello-esb.jar
curl -s -X PUT -H "Authorization: Bearer $MULE_ADMIN_TOKEN" --data-binary @hello-esb.jar "$MULE_PUBLIC_URL/admin/apps/hello-esb"; echo
until [ "$(curl -s -o /dev/null -w '%{http_code}' "$MULE_PUBLIC_URL/gateway/hello")" = 200 ]; do sleep 5; done
curl -s "$MULE_PUBLIC_URL/gateway/hello?name=agent"
curl -s -H "Authorization: Bearer $MULE_ADMIN_TOKEN" "$MULE_PUBLIC_URL/admin/apps"; echo
curl -s -X DELETE -H "Authorization: Bearer $MULE_ADMIN_TOKEN" "$MULE_PUBLIC_URL/admin/apps/hello-esb"; echo

A fresh deploy prints health: 200, then no token: 401, then {"deployed":"hello-esb"}, waits while the application starts (about 15 seconds), then prints {"message":"hello from Mule","echo":{"name":"agent"}}, then {"apps":["hello-esb"]}, and finally {"removing":"hello-esb"}. The sample application's source is samples/hello-esb.xml in the image repository; build your own with Maven and mule-maven-plugin, and a mule-artifact.json that sets "javaSpecificationVersions": ["17"].

Why Deploy MuleSoft ESB on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying MuleSoft ESB on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

• Agent-ready - no deployer fields, a contract block and one working deploy-and-call script.
• A deploy API the Community Edition lacks - push and remove Mule applications over authenticated HTTP instead of copying files into a server.
• Persistent - a volume holds the applications, and the image is pinned by digest.
• Public gateway - the applications' HTTP endpoints are reachable at /gateway/* without any extra networking setup.

Common Use Cases

• API integration layer - route, transform and orchestrate calls between SaaS APIs, databases and queues with Mule flows.
• Agent-driven integration deploys - an agent builds a Mule application, PUTs it, tests it through /gateway, and removes it.
• Mule application test bench - run a Mule 4 runtime on demand for CI or for trying a flow before it goes to an Enterprise environment.

Dependencies for MuleSoft ESB Hosting

• None. Applications may reach any database or queue you deploy alongside them in the same Railway project.

Deployment Dependencies

• Mule runtime documentation
• Mule Maven Plugin
• Wrapper image source

Implementation Details

The image runs the Mule 4.12.0 standalone runtime (download verified by SHA-1) on Java 17. The admin server listens on Railway's PORT (8080); Mule applications listen on 8081, which is forwarded under /gateway. Set MULE_APP_URLS (comma separated archive URLs) to fetch applications on first boot.