If you run MuleSoft’s Private Cloud Edition (PCE) in an air-gapped or tightly controlled environment, you’ve probably watched the AI coding boom from the sidelines. The usual tools assume your code, your API specs, and your platform all sit within reach of a public cloud. In your world they don’t. Your Exchange assets and API policies live in PCE, behind your own network boundary. Your Mule code lives on your laptop. Between the two sit a lot of browser tabs and manual copy-and-paste, and an AI agent has no good way to bridge that gap.

PCE 4.3.0, generally available since October 6, 2026, changes that. Anypoint Code Builder (ACB), MuleSoft’s VS Code-based IDE, powered with MuleSoft Vibes can now connect directly to your own PCE control plane. Your code, your specs, and Anypoint CLI all run from the same workspace, against your own instance. That connection is what makes AI useful here. MuleSoft Vibes skills give your coding agent the MuleSoft knowledge it would otherwise lack. Each skill bundles instructions and scripts for one job, such as building flows, running, securing, or upgrading an app. The agent picks the right skill for your request, works through Anypoint CLI against PCE, and hands back a build for you to review.

This tutorial is for MuleSoft developers on PCE. By the end, you’ll have:

ACB signed in to your PCE instance
Anypoint CLI pointed at PCE, with the PCE plugins installed
MuleSoft Vibes skills installed for your coding agent
A phased, build-gated way of working with the agent

The one-time setup takes about 10–15 minutes. How long a build takes depends on the scope of the app.

What Anypoint Code Builder brings to PCE

ACB is MuleSoft’s IDE, built on VS Code. Connected to PCE, you can do most of the work without opening a browser:

Design and validate API specs locally, then mock them with the API Console before the backend exists.
Implement an API from its spec through the Command Palette, and build integrations on the design-time canvas.
Write DataWeave and MUnit tests, and pull in components from Exchange.
Package the app for Runtime Manager, with Parent POM support for your Maven standards.

It all sits in one window. The MuleSoft extension is in the activity bar. Your flows show up as code or on the canvas. The status bar shows whether you’re logged in, plus your MUnit coverage. The output panel shows responses when you run and test. The Command Palette is how you talk to PCE.

Here’s where it pays off once an agent is writing code. ACB renders the Mule XML as flows and components, so you review something you can follow instead of hundreds of generated lines. You can check the business logic, see where error handling sits, and spot a missing step.

Figure 1. A flow the agent generated, shown in the ACB canvas

MuleSoft Vibes supplies the skills the agent uses. They follow MuleSoft best practices and work with coding agents such as Claude Code, Cursor, Cline, and Codex. Because the skills are files on your machine, you can add your own rules, such as naming conventions, standard headers, or required logging. You can also keep private skills in your own repositories, so the agent starts from your standards.

Set up ACB, Anypoint CLI, and Vibes skills

What you need

PCE 4.3.0, and an account you can sign in with
VS Code on your desktop
Node.js 22.0.0 or later and npm 7 or later
Maven and a JDK on your terminal’s `PATH`, because the agent runs `mvn clean package` at each build gate. Run `mvn -v` to check.
A connected app in PCE, for Anypoint CLI and the skills
Network access to the VS Code Marketplace and npm, or the offline install packages for ACB, Anypoint CLI, and MuleSoft Vibes, available from your customer success manager (CSM)
A coding agent your organization approves. Point your coding agent at your organization’s internal model endpoint so prompts and code stay inside your network.

Install Anypoint Code Builder

You can install Anypoint Code Builder (ACB) from the VS Code Marketplace or from the private distribution bundle.

Install from the Marketplace

In VS Code, open the Extensions view, search the Marketplace for Anypoint Extension Pack, and install it. When the install finishes, the MuleSoft icon appears in the activity bar on the left.

Install the private distribution bundle

The private distribution bundle is on the Customer Portal page in the Salesforce Help customer portal. It includes an installer script that installs every ACB extension in one step.

1.Unpack the bundle and run the installer.

macOS: Decompress the private-dist archive. Open a terminal in the resulting folder and run:
Windows: Unzip the private-dist archive at the root of C:\ (for example, C:\win32-x64-dist). If you unzip it into a deeply nested folder, the install fails because the file paths exceed the Windows path-length limit. In the extracted folder, right-click install-bundle-windows.ps1 and select Run with PowerShell.
Note: If you see an error like install-bundle-windows.ps1 cannot be loaded. The file … is not digitally signed, open PowerShell in the extracted folder, run the following command, and then run the script again from that same window:

2. When the installer asks Would you like to clean up your currently installed ACB extensions? (Y/n), enter Y. This removes all ACB extensions you already have installed so you start clean.

3. When the install finishes, reload the VS Code window (Developer: Reload Window in the Command Palette). The MuleSoft icon appears in the activity bar on the left.

Connect ACB to your PCE control plane

By default, ACB talks to the MuleSoft-hosted control plane. To switch it to your instance, open Settings → Extensions → Anypoint Code Builder (Platform) and set two values:

Mule: Control Plane = `Private Cloud Edition`
Mule: Control Plane PCE Url = your PCE URL, for example `https://<your-pce-host>/`

Figure 2. Both settings live under Anypoint Code Builder (Platform). The URL is your PCE host, not anypoint.mulesoft.com.

You can only change the control plane in the desktop IDE, not in a browser-based Anypoint Code Builder. Then open the Command Palette and run MuleSoft: Login to Anypoint Platform. ACB opens your PCE sign-in page in the browser, and after you sign in, the status bar shows you’re logged in.

The Configure ACB for PCE guide covers every setting.

Install Anypoint CLI and point it at PCE

ACB covers the editor. Anypoint CLI covers everything you’d rather script. On PCE, its plugins let you manage business groups, roles, and federated identity settings; work with Design Center projects; publish, search, and discover Exchange assets and Maven dependencies; and register APIs, enforce contracts and service level agreements (SLAs), and apply policies in API Manager.

Because it runs in the VS Code terminal, it sits right next to your code. It also runs anywhere else a shell does. You can drive packaging and deployment from your continuous integration and delivery (CI/CD) tooling, apply the same policies and configuration to every environment from a script, and run structured batch scripts with shell autocomplete for Zsh, Bash, and PowerShell. All of it runs against your PCE instance, inside your own network.

Install the CLI globally and confirm it runs:

The second command prints the CLI version. If you get “command not found,” add npm’s global bin directory to your `PATH`.

Then add the four plugins PCE supports:

If you’re installing from the offline package, unzip the Anypoint CLI installer and run the install script from that folder. It installs the CLI and the plugins in one step:

Run `anypoint-cli-v4 plugins`, and you should see all four listed.

Next, make the CLI trust your PCE instance’s TLS certificate. Anypoint CLI runs on Node.js, which rejects certificates it doesn’t recognize, so without this step every CLI call fails.

On macOS or Linux, save the certificate and point Node.js at it:

Add the `export` line to your shell profile, such as `~/.zshrc`, so new terminals and your coding agent pick it up.

On Windows, open your PCE URL in Chrome or Edge, view the site’s certificate, and export it as Base64-encoded PEM. Then point Node.js at it, and restart VS Code so the change applies:

If your PCE uses a certificate from an internal CA, point `NODE_EXTRA_CA_CERTS` at your organization’s root CA file instead.

Then point the CLI at your PCE host, organization, and environment, and give it your connected app’s credentials. These commands are the same on every operating system:

Use the hostname only, without `https://`. The CLI keeps the `conf` values in its local config, and your agent acts with whatever the app can do. Grant the connected app only the scopes the skills need.

To confirm the connection, list your business groups:

If your PCE business groups come back, the CLI is talking to your instance. The Anypoint CLI auth docs list the other `conf` keys.

Install MuleSoft Vibes skills

MuleSoft Vibes is an optional add-on on PCE. It ships 21 default skills that work with coding agents such as Claude Code, Cursor, Cline, and Codex.

The skills reach the platform through the Anypoint CLI you just configured. Setup comes down to two more things: add the DX Mule plugin to the CLI, then add the MuleSoft skills to your project:

If you’re installing from the offline package, install the DX Mule plugin from its local file, then add the skills from the unzipped skills folder:

The installer asks three questions:

1. Agents: keep Universal `.agents/skills`, and add any other approved agents you use, such as Claude Code `.claude/skills`.

2. Scope: choose Project or Global.

3. Method: choose Symlink, which is the recommended option.

The skills install guide has the full steps.

Verify the setup

Check each piece once before you build anything:

1. The ACB status bar shows you’re signed in to your PCE instance.

2. `anypoint-cli-v4 account:business-group:list` returns your PCE business groups.

3. The skills you picked appear under `.agents/skills` or `.claude/skills` in your project.

If all three pass, your IDE, your terminal, and your agent are working against the same PCE instance.

Build and review with the agent

Put the skills to work on real Mule apps

With setup done, give the agent real work. Each skill below handles a task you’d otherwise do by hand. Name the skill in your prompt, and the agent follows its instructions and calls Anypoint CLI when it needs the platform.

generate-doc-description for the apps nobody documented. Maybe you’ve inherited a Mule app with no docs. Point the agent at the project with this skill, and it reads the flows and writes descriptions for them. The next person to open it gets an explanation, not an archaeology project.

build-mule-integration for new flows and missing tests. This skill builds flows and whole applications from a spec, and it uses Anypoint CLI and the DX Mule plugin to do so. It’s just as useful on existing code. Ask it to write MUnit tests for flows that are already built, and you get coverage for the parts of an app that nobody wants to touch.

secure-mule-app before anything ships. This skill scans your configuration for security risks, encrypts secure properties, and suggests logging improvements.

Before 4.3, a PCE developer’s workflow was split in two: write code locally, then switch to the PCE web UI to look up an asset, check a spec, or apply a policy. Now you go from spec to flow to tests to a packaged app in one workspace, against your own PCE instance, and you review each step in the ACB canvas before it moves on. The local environment and the platform stop being two places you shuttle between.

Build in phases with build-mule-integration

If you ask an agent to build a whole API in one prompt, the result is hard to review. A phased plan gives you a build you can check after every step. Start by giving the agent the full context: source and target systems, schemas, and business rules.

Then break the build into small phases, such as project setup, one or two endpoints per phase, and tests. Each phase must pass `mvn clean package` with BUILD SUCCESS before the next one starts.

Your prompts then follow four stages:

1. Generate the phased plan from your API spec, data docs, and product requirements document (PRD).

2. Implement one phase at a time, and stop at the build gate.

3. Write MUnit tests for the finished flows.

4. Document the app.

Here’s an example of a stage-two prompt:

The prompt names the skill, limits the scope to one phase, and makes the build the gate. Each phase gives you a small, green change to review in the ACB canvas before you move on. If the build fails, or you spot a gap in the flow, paste the error or your notes back to the agent, or revert the phase and narrow its scope.

PCE 4.3.0 also includes platform and upgrade changes for administrators. For those, and for the full list of limitations, see the PCE 4.3.0 release notes and the PCE documentation.