If you build for the Power Platform, you know the tax: change a web resource or a PCF control, package it, publish it, wait, hard-refresh, repeat. Every small tweak turns into a deployment. It slows you down and pulls you out of a fast iteration loop.
To alleviate that friction, we're sharing @hummingbirdworks/proxy, a lightweight developer proxy that lets you skip the upload and publish step when developing. It redirects Dataverse / Dynamics 365 web resources and PCF control assets to your local builds — or to a running dev server such as Vite — so you can iterate locally without deploying on every change.
Why we built it
Many of us relied on Fiddler Classic to intercept and redirect requests during Power Platform development. Fiddler Classic's license no longer permits commercial use, and no paid commercial version of it is offered.
Even with AutoResponder, mapping web resources meant maintaining regex rules by hand, one at a time, and sharing them meant exporting and importing rule sets. We wanted to map a whole folder or a PCF control in a couple of lines — in a config file we could check into source control.
That led us to build a thin wrapper around the open source mitmproxy that knows the URL patterns Dataverse uses for web resources and PCF assets. The result is a small, declarative configuration that maps what the browser requests to what you're actively editing on disk.
How it works
The proxy sits between your browser and your Dynamics 365 environment. When the browser requests a web resource or PCF that you're working on, the proxy serves your local version instead of the deployed one. Everything else passes through untouched, so you're still working against your real environment and its data.
You describe the redirects in a proxy.config.toml file. Each [[rules]] entry is a single redirect, and there are a few rule types to cover the common cases:
# Single web resource file -> local file
[[rules]]
type = "single"
web-resource-name = "test_/ribbonscript/opportunity.js"
local-path = "./src/webresources/ribbonscript/opportunity.js"
# Folder of web resources -> local folder
[[rules]]
type = "folder"
web-resource-folder = "test_/custom-app/"
local-path = "./src/webresources/custom-app"
# Folder of web resources -> local dev server (e.g. Vite)
[[rules]]
type = "devserver"
web-resource-folder = "test_/bookings-editor/"
local-url = "http://localhost:5173"
domain = "myorg.crm.dynamics.com"
# PCF control -> local build output folder
[[rules]]
type = "pcf"
control = "test.BookingsEditor"
local-path = 'C:\Users\me\repo\bookings-editor\out\controls\BookingsEditor'
Any rule can be scoped to specific hosts with domain, or temporarily switched off with disabled = true. And if you work across several projects against the same environment, you can include their configs so a single running proxy covers all of them — no more restarting a different proxy as you navigate.
Getting started
Install mitmproxy, then add the package as a dev dependency and run the initializer:
npm install -D @hummingbirdworks/proxy
npx hummingbird-proxy init
That scaffolds a proxy.config.toml in your project and adds a proxy script to your package.json.
From there, start the proxy and point a browser at it:
npm run proxy
msedge.exe --proxy-server="http://localhost:8080"
# or
chrome.exe --proxy-server="http://localhost:8080"
The first time through, install the mitmproxy root certificate so HTTPS interception works: with the proxied browser open, visit http://mitm.it/ and follow the instructions. After that, edit a file locally, refresh the Dynamics-hosted page, and you'll see your changes without needing to upload and publish.
Hot module reload with Vite
If you use Vite to develop HTML web resources, the powerAppsWebResource Vite plugin configures your app to work with the proxy and produces stable output for built web resource files.
import { defineConfig } from 'vite'
import { svelte } from '@sveltejs/vite-plugin-svelte'
import { powerAppsWebResource } from '@hummingbirdworks/proxy/vite'
export default defineConfig({
plugins: [
svelte(), // or react(), vue(), etc.
powerAppsWebResource({ prefix: 'test_/myapp/' }),
],
server: { port: 5173 },
})
Point a devserver rule at that same port, run npm run dev and npm run proxy, and open the page that hosts your web resource. Edit, save, and watch it update in place.
A couple of practical notes
Chrome and Edge share one background process across windows, so close all of their windows first — or launch a separate profile — before starting a proxied session. And because Power Apps caches assets aggressively, a hard refresh (Ctrl+Shift+R) is sometimes needed; you may also want to bypass the service worker cache from DevTools while developing.
Try it out
@hummingbirdworks/proxy is open source, MIT-licensed, and available now on npm. Give it a spin on your next web resource or PCF control, and let us know how it fits into your workflow.