Xdebug Support: PHP debugging

Hi @Kevin are we still on track for Q4 to fully support XDebug?

(asking because ipconfig getifaddr en0 returns an external IP address and I travel a lot for work so this address will keep changing! :hot_face: Also probably explains why @Greg36 had to mess with firewall rules as the traffic is crossing interfaces)

Hi @jamesgreenblue, I believe xDebug support will be released with the next DK version (within weeks). It will probably need tweaking based on user feedback, though. We’re mainly working to make it easier to set up.

The IP address issue seems to be more due to something changing with Docker. I did originally recommend a way to automatically get the correct IP with a click to our Devs but I’m not sure if that will be in this release.

I’ll post an update in here once the feature is live!


I just switched to WSL2 from HyperV and had to set up XDebug again.
I followed Kevin’s WSL adapted guide Xdebug Support: PHP debugging - #56 by Kevin and it’s working fine (PHP 8.0) for me. Thanks Kevin!

I’m relieved! :joy:

PS: You can just use the IP address of the Ethernet vEthernet (WSL) you can see in the task manager.

1 Like

Hi Kevin,

This post is music to my ears. +1 from me on the need for xDebug to complete the local dev env.

Was this released? I see no mention of xDebug in the latest release line items.


Hi @Konstantin_Brazhnik,
This was about to be released with the current DK version, but I found a huge issue with it and we had to push back the release. We figured it was better to wait/do it right to avoid introducing performance issues.

It’s currently slated for the next release of DevKinsta before the end of the year. I’ll announce if it gets pushed back again, but I’m hopeful for a November/December release.



Happy New Year!

I’m excited to see xDebug in the release logs of the latest version of DevKinsta. Is there any documentation you can point me to about how to use it with VSCode? I’d been using Valet for a while and had no issue configuring PHP and VSCode to work with xDebug, but I’m not 100% sure how this translates to DevKinsta and the docker containers it runs.

Thank you!


Here’s how I got it working. From the wrench/site configurations option in DevKinsta I made sure “enable xdebug” was checked. In the PHP.ini editor I had the following lines:

xdebug.profiler_enable_trigger = 1
xdebug.discover_client_host = 1

You can verify this with a phpinfo(); output, but the config on my system was still using the classic port 9000, not the 9003 XDebug 3 supposedly moved to.

I have the PHP Debugv1.30.0 extension installed in VS Code. With that in place you’ll have the ‘Run and debug’ option on the left. Or press Shift-Command-D to open it. Let it create a launch.json file for you.

I removed everything but the “Listen for Xdebug” configuration; it’s not possible to launch a script for remote execution as far as I know so they were just cluttering up the options.

here’s what one of mine looks like, where my workspace is in the wordpress wp-content directory (I don’t want any visibility into the stock WP code or have searches find Automattic’s classes)

    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "pathMappings": {
                "/www/kinsta/public/devwebsite/wp-content/": "${workspaceRoot}/",

My experience has been that setting breakpoints visually can be iffy for triggering; I tend to add an xdebug() call in my code where I want it to halt. Just be careful you don’t leave them in when you push to Kinsta.

1 Like

Hi Don,

Thank you for sharing this information/test you did! :bowing_man: .
Hopefully that will be useful for other users as well! :+1: :smiley: