Hi Adrian,
Thanks for the reply.
Yes, I’m aware of the workaround suggested above, but that’s exactly the issue: in 2025, Composer (and even Node for Tailwind/Vite workflows) shouldn’t require manual Docker exec steps or container-level installs that disappear every time DevKinsta rebuilds.
Composer has become a core requirement for modern WordPress development — not an optional extra. Tools like Bedrock, Timber, TailPress, Sage, and even many WooCommerce setups depend on it. Without native Composer support, DevKinsta feels incomplete for any modern PHP workflow.
Right now the workflow is:
-
open an external terminal
-
run docker exec manually
-
install Composer manually
-
reinstall after container rebuilds
-
manually manage Node/Tailwind builds
It works, but it’s not sustainable or efficient for day-to-day development.
It would really help if DevKinsta included:
-
Composer preinstalled in the PHP container
-
Optional Node support for Tailwind/Vite
-
An integrated terminal that automatically opens the correct container
At this point they’re essential tools, not “nice to have”.
If DevKinsta wants to stay competitive with LocalWP, DDEV, Lando, and Herd, native Composer support is key.
Thanks again — hoping this can move forward soon.