If you’re evaluating MuleSoft or trying to make sense of your existing contract, the first thing you need to understand is vCores. They’re the unit of compute that MuleSoft uses to meter your usage on CloudHub, and they’re the single biggest driver of your annual spend. Understanding how vCore pricing works — what you’re getting, what you’re not getting, and how the economics compare to alternatives — is essential for budgeting and for evaluating whether a migration makes financial sense.
This post breaks down the vCore model in detail: the technical definition, the actual dollar amounts, how to estimate what you need, and why the pricing structure creates a cost trap that gets worse over time.
A vCore is a virtual CPU core allocated to your Mule application when it runs on CloudHub, Salesforce’s managed hosting platform. When you deploy a Mule application, you assign it a “worker” — and the size of that worker is measured in vCores. Each worker size comes with a fixed amount of memory:
The key thing to understand is that you’re paying for reserved capacity, not actual usage. When you assign a 1-vCore worker to an application, that vCore is allocated to you whether the application processes 10,000 transactions per hour or zero. The meter runs whether you’re using it or not.
This is fundamentally different from how cloud-native compute pricing works. On AWS, GCP, or Azure, you can run containers that auto-scale based on demand and pay only for the CPU seconds you actually consume. With MuleSoft, you’re buying a fixed reservation and paying for it around the clock, regardless of utilization.
MuleSoft doesn’t publish a price list. Pricing is negotiated per contract, and Salesforce reps will tell you it “depends on your needs.” But after working with dozens of companies on their MuleSoft contracts, here’s what the actual numbers look like.
For CloudHub — MuleSoft’s fully managed hosting — the typical range is $50,000 to $70,000 per vCore per year. Where you land within that band depends on several factors:
Runtime Fabric is MuleSoft’s self-managed option — you provide the underlying Kubernetes infrastructure and MuleSoft provides the runtime layer. vCore pricing for Runtime Fabric is typically $30,000 to $40,000 per vCore per year. That’s cheaper than CloudHub on the license line, but you also need to factor in the cost of running and managing the underlying Kubernetes cluster yourself. Once you add infrastructure and ops overhead, the total cost difference narrows.
Here’s the number most teams don’t plan for: renewal pricing almost always increases 5–8% per year. Your initial contract might be negotiated competitively, especially if Salesforce is trying to win your business. But once you’re deployed, migrated onto the platform, and your team has learned the tooling, your negotiating leverage drops substantially. Salesforce knows this, and the renewal quotes reflect it. Over a five-year horizon, that compounding uplift turns a $60K-per-vCore deal into a $78K-per-vCore deal — without you adding a single new application.
Understanding per-vCore pricing is only half the equation. You also need to know how many vCores your deployment requires. Here’s a practical sizing guide based on what we see across client environments:
Most companies we work with end up running 4 to 16 vCores across all their applications. But that’s just the production number.
Here’s what catches people: CloudHub requires minimum worker sizes per environment, and you typically need separate environments for development, staging, and production. That means you often need 2 to 3 times your production vCores to cover your lower environments. If you’re running 6 vCores in production, you might need 4 more in staging and 2–4 in development. Suddenly your 6-vCore deployment is actually a 12–14-vCore commitment.
The vCore pricing model creates a cost structure that works against you in several ways. Understanding these dynamics is important whether you’re negotiating a new contract or evaluating whether to reduce your current spend.
You pay for idle capacity. If your API handles 10 requests per hour at 3 AM, you’re still paying for the full vCore. There’s no way to scale down to zero or even to a fraction of a vCore during off-peak hours. You’re paying peak pricing around the clock.
Scaling means buying more vCores. CloudHub doesn’t have auto-scaling that reduces cost. You can add workers to handle more load, but each additional worker consumes vCores from your allocation. There’s no “burst” capacity that lets you handle traffic spikes without a permanent vCore commitment. If you need to handle Black Friday traffic, you need to buy enough vCores to cover the peak — and pay for them the other 364 days of the year.
Lower environments consume vCores too. Every developer working on a flow, every QA environment running regression tests, every staging deployment validating a release — they all consume vCores from the same pool. This is compute that delivers zero business value but can easily account for 40–60% of your total vCore allocation.
You can’t easily downsize mid-contract. If you commit to 12 vCores on a three-year deal and then consolidate your flows to only need 8, you’re still paying for 12. MuleSoft contracts don’t have a “return unused vCores” clause. You might be able to negotiate adjustments at renewal, but that’s 1–3 years of paying for capacity you don’t use.
The pricing doesn’t scale linearly with value. Doubling your vCores doesn’t double the business value of your integrations. But it does double the cost. As your integration needs grow, the gap between what you’re paying and the value you’re receiving widens.
Compare this to Kubernetes: a pod scales up when traffic increases and scales back down when it subsides. You pay for actual compute consumption. Development environments can share cluster resources. There’s no per-application licensing overhead. The pricing model naturally aligns cost with usage.
Let’s make the comparison concrete. Take a typical mid-size deployment running 4 MuleSoft vCores in production:
The gap is staggering — roughly 10x to 20x — and it exists because you’re not paying for compute. You’re paying for the MuleSoft software license. The compute itself is a small fraction of the vCore price. The rest is Salesforce’s margin.
You can model this with your own numbers to see what the difference looks like for your specific deployment.
If you’re looking to bring your vCore costs down — whether as a short-term optimization or as a step toward broader cost reduction — here are the most effective levers:
Audit utilization. Pull the monitoring data from Anypoint and look at actual CPU and memory utilization per worker. In most environments we assess, a significant number of vCores run at less than 20% utilization. You may be able to downsize workers without any impact on performance. This is the lowest-effort optimization available.
Consolidate applications. Multiple small applications each running on their own 0.1- or 0.2-vCore workers can sometimes be consolidated onto fewer, larger workers. This reduces the total number of workers and can free up vCore allocations. Be careful with this one — there are legitimate isolation reasons for separate workers — but when flows are logically related and low-traffic, consolidation often makes sense.
Use Runtime Fabric if you have existing infrastructure. If your organization already runs Kubernetes clusters with available capacity, moving from CloudHub to Runtime Fabric can cut the per-vCore licensing cost by 30–40%. You take on more operational responsibility, but if you already have the infrastructure team and the clusters, the marginal cost is lower.
Negotiate multi-year commitments. If you’re staying on MuleSoft for the foreseeable future, a multi-year deal gives you leverage to negotiate 15–25% better per-vCore rates. This only makes sense if you’re confident in your commitment. Locking into three years of vCore spend to save 20% isn’t a good deal if you end up migrating in year two.
Or: eliminate vCore costs entirely. Migrate your integrations to open-source runtimes like Apache Camel on Kubernetes, and vCore pricing becomes irrelevant. There’s no per-application compute license. You pay for infrastructure at commodity cloud rates. The migration investment typically pays for itself within 12 months through eliminated licensing alone.
The path you choose depends on your timeline and appetite for change. Optimization buys you time and savings within the MuleSoft ecosystem. Migration eliminates the cost model entirely. For a deeper look at the full range of options, see our guide on reducing MuleSoft costs.