The Work Behind the Workflow: Stas Zhuk and the Future of DDEV

When developer tooling works, nobody notices. When it breaks, everyone does. Stas Zhuk operates in that quiet space in between, helping ensure that DDEV continues to “just work” for thousands of developers across the Drupal and PHP ecosystems.

A seasoned PHP developer with over seven years of full-cycle experience, Stas joined the maintenance team of DDEV in October 2023, with part-time support from the DDEV Foundation. Since then, he has focused on testing, release reliability, documentation, and strengthening the project’s growing add-on ecosystem, stepping into greater responsibility at a crucial moment for the tool.

In this interview with The DropTimes, sub-editor Alka Elizabeth speaks with Stas about discovering DDEV as his entry point into Drupal, maintaining critical open source infrastructure amid external dependencies and container runtime shifts, and continuing that work from Ukraine during prolonged power blackouts.

TDT [1]: DDEV is widely used in the Drupal ecosystem and was also your entry point into it. How did discovering DDEV shape your first exposure to Drupal-focused tooling?

Stas Zhuk: At the start of my career, setting up development environments took hours to days. Each new project with a different stack meant even more configuration work.

When I was looking for a better solution, DDEV stood out because the documentation went beyond just the tool itself. It covered Docker concepts and service configuration. This showed me what good dev tooling should look like - flexible for any framework, but explained well so you understand what's happening underneath.

I came from Laravel and never touched Drupal before. But DDEV's approach and all the quick-start guides made it clear that the tool works for any PHP project.

TDT [2]: When you first adopted DDEV, what friction disappeared quickly enough that you stopped seriously evaluating alternatives? In hindsight, what did DDEV understand about day-to-day developer reality that other tools missed?

Stas Zhuk: Setup complexity just disappeared. Everything for development came prebundled - different PHP versions, databases, tools. You spend a bit of time selecting what you want, and you're ready to go.

Comparing with production setup on VPS servers, DDEV felt familiar to me. I got containers that worked like a real server environment while using Docker underneath. The balance between "works out of the box" and "customize anything" was exactly right.

You May Like

Blog

How TDT Is Evolving: Change Records from Late 2023

Blog

How TDT Is Evolving: Change Records from Late 2023

Also, HTTPS with mkcert and Xdebug just worked. I remember being excited - my only question was why I didn't find DDEV earlier?

TDT [3]: Before you contributed any code, what was the first limitation or rough edge in DDEV that made you think, “this shouldn’t work like this”?

Stas Zhuk: I read through the whole documentation before contributing. The issues I found were mostly formatting mistakes and unclear explanations. Small things, but they could confuse new users.

I submitted fixes for these docs issues. The feedback was encouraging and made me want to contribute more. It wasn't a major technical problem, just places where the documentation could be clearer. Our documentation has grown a lot since then. We always try to document every possible scenario - it can feel overwhelming but helps us support users better.

TDT [4]: What made DDEV feel like a project worth investing your time in, rather than just another tool to patch locally and move on?

Stas Zhuk: Active maintenance and a welcoming community made the difference. Quick responses to issues, good feedback on contributions—all of this creates an environment where you want to keep helping.

I test DDEV constantly now as a maintainer, so every contribution helps improve the tool and helps thousands of developers. Being part of building infrastructure that the Drupal and PHP communities depend on feels more meaningful than just fixing my local issues.

TDT [5]: Your recent work on the add-on ecosystem, including experimentation around FrankenPHP, touched some deep assumptions in DDEV. What underlying problem were you actually trying to solve with that work?

Stas Zhuk: Users wanted support for more services, but adding everything to DDEV core makes it too big and hard to maintain.

The add-on ecosystem solved this but created a new problem - how to keep quality when add-ons live in different repos with different maintainers. I built addons.ddev.com so users have one place to find add-ons. Then I created a maintenance guide to help with quality standards.

FrankenPHP is a good example. It's new tech and needs time to mature. As an add-on we can experiment without breaking DDEV for everyone. We had something similar with XHGui feature—it was an add-on first, became mature enough, and was sponsored by TYPO3 organization to become a part of DDEV.

TDT [6]: Supporting something like FrankenPHP means expanding flexibility without breaking trust. What were the most uncomfortable technical trade-offs you had to accept to keep DDEV stable for existing users?

Stas Zhuk: The biggest trade-off was accepting that not everything can work perfectly right away and that we can't fulfill every possible feature request.

As for FrankenPHP, it's a good thing that the generic web server feature already existed for custom servers like Node.js and Python - it fit perfectly for this experimentation.

The principle is simple: never break existing users to add new features.

TDT [7]: In your post about working through power blackouts in Ukraine, you describe continuing maintenance under conditions most developers never face. How did that period change the way you think about reliability, redundancy, and responsibility as a maintainer?

Stas Zhuk: Working through war and blackouts changed how I think about reliability completely. Before 2022, I thought about it in terms of tests, CI, and monitoring - standard stuff. Now I also think: what if I lose power, water, or heating for a day or more? How do I keep maintaining DDEV and not lose myself?

The DDEV community sponsored power stations that let me work during blackouts. I'm very grateful for this support. Sad to say, the electricity situation hasn't improved - but at least there's enough time to charge the EcoFlow stations.
People depend on DDEV for their work and how they earn their living. 

Also, having multiple maintainers means that DDEV stays stable even when one of us faces challenges. This redundancy isn't just good practice - it's essential, actually.

TDT [8]: Once you became a maintainer in 2023, your work shifted toward testing, CI, and release reliability. What parts of DDEV turned out to be far more fragile than you expected once you were responsible for shipping it?

Stas Zhuk: The most fragile part turned out to be external dependencies. DDEV relies on many projects - Docker, databases, various frameworks. Sometimes one dependency updates and breaks another dependency, and both are used in DDEV. We need to fix it fast or provide a workaround to make our users happy.

The scale of testing surprised me. DDEV has hundreds of tests that break constantly because of upstream changes. We adapt all the time or report issues upstream to get fixes.

DDEV works like a shield for users - our end-to-end testing catches breaking changes before users see them. Something breaks all the time, but we've gotten used to it. As a user, I never saw this complexity. As a maintainer responsible for releases, I see how much work goes into keeping DDEV stable when the ecosystem keeps changing.

TDT [9]: Many users only notice DDEV when it fails. What are the invisible systems or decisions that most often prevent those failures, and why are they hard to get right?

Stas Zhuk: Beyond the testing I mentioned, documentation prevents many failures. Good documentation helps users avoid mistakes before they happen. We update it constantly based on support requests. But we can't predict all user environments because someone always has a setup that breaks in unexpected ways.

And version compatibility testing is nearly impossible to do completely. DDEV needs to work with multiple Docker versions, different runtimes, various operating systems, many PHP and database versions, and different project types. We test common setups and rely on users to report edge cases.

TDT [10]: AI-assisted development is now unavoidable. As a maintainer, how has it changed the way you review contributions, reason about correctness, or think about long-term maintainability?

Stas Zhuk: I use AI to help start on features when I don't have a clear understanding of how to implement something. Having code to work with helps me begin. It also writes tests well - often better coverage than I would create manually.

But reviewing becomes harder. It doesn't understand the whole project - thinks just about the PR, not how it fits with everything else.

My rule is: don't accept code you can't maintain without AI. If you can't understand the code it wrote, you're only creating problems for your later self.

TDT [11]: Where do you see AI genuinely helping a project like DDEV today, and where does it risk producing confident but shallow solutions that maintainers will have to clean up later?

Stas Zhuk: AI genuinely helps with documentation improvements, test generation, routine refactoring, and first investigation of issues. These have clear patterns that AI handles well.

Where AI is shallow - complex architectural decisions and edge cases. It generates the "happy path" well, but doesn't consider all possible scenarios. And every AI suggestion needs review from someone who knows the project deeply.

TDT [12]: Developer environments have evolved quickly since 2023. Which of those shifts poses the biggest challenge to DDEV’s original promise of “it just works”?

Stas Zhuk: Container runtime diversity is the biggest challenge. Before, most people used Docker Desktop. Now DDEV supports OrbStack, Lima, Docker Desktop, Rancher Desktop, Colima, Linux Docker, and GitHub Codespaces. Each behaves differently.

We recently added experimental support for Podman and Docker rootless. People have been requesting this for years because of security concerns. But rootless brings challenges - file permissions, network setup, and volume mounts work differently than traditional Docker.

Looking ahead, AI integration is another shift. Frameworks like Laravel and Drupal have MCP modules, and developers want to use them with DDEV. We're going to explore AI sandboxing and MCP support in 2026.

The challenge is supporting new tech while keeping things simple for users who just want their sites to work locally.

TDT [13]: Looking forward, what direction are you personally investing in for DDEV, technically or structurally, that users may not fully see yet, but that you believe will matter more than any single feature?

Stas Zhuk: First - refactoring how DDEV talks to Docker container runtimes and uses Docker Compose features. Work in this area helped to add Podman and Docker rootless in DDEV v1.25.0, but there are still many things to improve.

Second - add-on ecosystem maintenance. Keeping all add-ons updated with DDEV changes is tedious. Not everyone has time to track what's new. We need better processes to help maintainers keep add-ons updated with less effort.

Third - documentation and communication. Users don't see code changes, but they benefit from clear error messages and good troubleshooting guides.

The most important work isn't flashy features—it's building foundations so DDEV keeps working as technology changes. My goal is making DDEV boring in a good way: it just works, and developers don't think about it.