DDEV and Lando are excellent tools, but they solve a broader problem space than our WordPress-on-WSL2 workflow. In that specific case, we were repeating more options, layers, and decisions than each project needed. Docal was born from that. Not to do more things. To have to decide less.
The problem wasn't spinning up WordPress
Spinning up a local site today isn't hard. There are many mature tools for it, and most of them handle the basics well: containers, local domains, databases, HTTPS, and various services. The problem showed up afterward. Importing a real site.
The repeated setup included adjusting versions, sorting out certificates, making sure WP-CLI used the right PHP, and disabling production-only behavior.
Regenerating files was not difficult either. The cost came from repeating the same setup across projects.
DDEV and Lando solve a bigger problem
DDEV and Lando cover different CMSs, architectures, additional services, complex configurations, and teams with very different needs. That flexibility is a strength. But if your case is smaller and repetitive, it also means there are a lot of decisions you'll probably never need to make.
Docal starts with a narrower scope: WordPress, WSL2, Docker, HTTPS, and WP-CLI. That is the entire field it tries to cover.
Being specific lets you automate more
When a tool knows exactly what kind of project it's spinning up, it can assume things. It can know where WordPress lives. It can use the same PHP version for the site and for WP-CLI. It can set up HTTPS without asking every time.
It can run a search-replace that understands serialized data. It can recognize common plugin situations and adapt the environment. Every decision we lock in is one less decision to repeat on every project.
Importing a real site had to be part of the flow
Creating an empty WordPress is fine for a demo. In real work, we often start with something else: a .wpress file, a SQL dump, an uploads folder, or an existing site that needs to be reproduced locally. That is why Docal treats importing as a normal operation rather than a special task. The guide to importing WordPress from production into local development covers serialization, external services, and generated files in detail.
The goal isn't just creating environments. It's getting to the point where we can actually start working, faster.
WSL2 isn't a detail
Docal doesn't try to hide that it's built for WSL2. It's a deliberate decision. That lets it lean on a real Linux environment and skip some of the layers that show up when Windows, Docker Desktop, and the development environment split responsibilities between them.
That doesn't mean it's the solution for everyone. It means exactly the opposite. If you work differently, there's probably a better tool for you.
Less compatibility can also be an advantage
In software, compatibility is often expected to keep growing across more systems, options, and scenarios. Every new scenario, however, also adds code, tests, and edge cases. Docal accepts trading away breadth in exchange for doing one concrete workflow better. That also keeps the tool simpler to understand.
We didn't want to replace mature tools
Docal doesn't exist because DDEV or Lando are poorly built. It exists because our problem was smaller than the problem those tools are trying to solve. And when the problem is smaller, sometimes the best solution can be smaller too. Its deliberately narrow scope makes that workflow easier to automate. Outside it, DDEV or Lando may still be the better choice.