Good breadth of options tried already. Here's how this is typically approached in practice, with tradeoffs for each:
Short answer: tunnel for quick iteration, sandbox BC for anything beyond local dev
1. ngrok/Cloudflare Tunnel, good for early iteration only Both work functionally for getting Copilot Studio's custom connector to reach your local Docker container, but treat this as throwaway dev-loop tooling, not something to build real testing confidence on:
- Free-tier ngrok URLs rotate on restart, which breaks your custom connector's registered host every time you restart the tunnel, annoying if you're iterating frequently
- Cloudflare Tunnel is generally more stable for this (named tunnels persist across restarts if configured), so if you're choosing between the two, lean Cloudflare for anything beyond a quick test
- Neither reflects real network latency/auth behavior you'll see in production, so don't validate performance or OAuth flows this way, only functional request/response shape
2. Sandbox BC environment, the better path once past initial prototyping Once your custom connector's request/response shapes are stable, move to a real Business Central sandbox environment (cloud-hosted, not Docker) as your dev target instead of tunneling to local:
- Removes tunnel flakiness entirely from your dev loop
- Lets you test actual BC API authentication (OAuth2/Azure AD app registration) exactly as it'll work in production, since local Docker BC often uses simplified/basic auth that doesn't match cloud BC's auth model
- Custom connector registration against a stable HTTPS endpoint is what you'll ship anyway, so testing against it earlier surfaces auth/schema issues sooner
3. Practical middle-ground some teams use: mock/stub layer If your Docker BC instance is mainly there for realistic sample data rather than testing actual BC business logic, consider standing up a lightweight mock API (Azure Function or simple Express/Flask app returning realistic JSON) that mirrors your BC API's OpenAPI schema. Point Copilot Studio's custom connector at that instead during early development. This decouples your Copilot Studio/connector development from Docker/tunnel stability entirely, letting you iterate on the AI/topic side without infrastructure flakiness, then swap to real BC endpoints once your connector schema is finalized.
Recommended sequencing:
- Mock API or tunnel for initial connector schema/topic development (fast iteration)
- Move to BC sandbox once schema stabilizes (real auth, real data shape)
- Production BC endpoint for final validation before go-live
This avoids the tunnel-stability problem entirely for the bulk of your development time, and gets your auth testing right earlier rather than discovering OAuth issues only when you finally point at a real BC environment.