Switch Audience
You Need Your Own Box
You just spent time learning what Drupal actually is. You understand content types. You understand fields. You understand views. You are ready to build something. So you do what any reasonable person does — you go looking for somewhere to build it.
That is when the internet gets its hands on you.
Suddenly everyone has a solution. Managed Drupal hosting with a one-click installer. A branded local development environment with a friendly interface and a monthly fee. A cloud-based sandbox that lives on someone else's server and disappears when you stop paying. Tools wrapped in tools wrapped in subscriptions, each one promising to make this easier, each one standing between you and the thing you actually want to do.
Here is what nobody selling you those tools wants you to know: you don't need any of them.
What you need is a computer. A small, cheap, quiet computer that sits on your desk, runs Linux, and does exactly what you tell it to. No subscription. No monthly fee. No branded interface. No one else's decision about when to update it or change the pricing tier or sunset the free plan. Your computer. Your tools. Your toolbox.
A good tradesperson owns their tools. The tools live in their truck. Nobody charges them a monthly fee to use their hammer. There is no reason your development environment should work any differently.
Drupal itself is free. It is open source, community built, nobody's product. The entire philosophy of Drupal is that the tools belong to the people who use them. It would be almost comic to pay a monthly fee for a managed environment to run the free thing — except that a lot of people do exactly that, because nobody showed them the alternative.
The alternative is a $200 micro computer, an afternoon, and this chapter.
And here is the thing nobody tells the nervous builder: the person who sets up their own Linux server has crossed a threshold. They know something real now. They understand what a server actually is, because they built one. That knowledge transfers directly to every production server they will ever manage. The $200 box on your desk and the DigitalOcean droplet running your live site are the same machine. Same Linux. Same stack. Same skills.
You are not setting up a development environment. You are building the practice court — and it is exactly the same dimensions as the game court.
You need a small, unbranded micro computer — sometimes called a mini PC or NUC-style machine. Look for something with a modern Intel or AMD processor, at least 8GB of RAM, and 256GB of storage. Brands like Beelink, Trigkey, and similar unbranded manufacturers sell perfectly capable machines in the $150–$250 range. You do not need anything powerful. Drupal development is not resource intensive.
Buy the box. The next article in this chapter will walk you through everything else.
What about DDEV?
If you spend any time in Drupal community spaces — Slack channels, YouTube tutorials, official documentation — you will notice that DDEV comes up constantly. It is the community's preferred local development environment and for good reason. DDEV is well built, actively maintained, and wraps Docker into a genuinely friendly interface. Many experienced Drupal developers use it every day and swear by it.
So why aren't we using it here?
DDEV runs on Docker. Docker is a containerization system that packages your entire development environment — web server, database, PHP, all of it — into portable containers that run identically on any machine. It is powerful technology and it solves real problems, particularly for teams where multiple developers need identical environments.
It also puts a significant layer of abstraction between you and the thing you are trying to learn.
When something goes wrong in DDEV — and something always goes wrong eventually — you are debugging Docker, not Drupal. You are learning container networking instead of Apache configuration. You are reading Docker documentation when you should be reading Drupal documentation. The tool that was supposed to make things easier has become the thing you need to understand before you can understand the thing you actually came to understand.
This chapter is opinionated. We believe the person who sets up a real Linux stack — Apache, MySQL, PHP, configured by hand — understands what is actually happening when Drupal runs. That understanding transfers directly to production. Docker containers do not run on your hosting service. A LAMP stack does.
Learn the real thing first. Once you understand what a virtual host is, what a database user is, what PHP configuration actually does — DDEV may make more sense -
There are perfectly good reasons to use DDEV right from the start - much of what is covered in this manual has a one to one relationship with a sitebuilder using DDEV, however we will not be providing instructions for DDEV - there is excellent documentation on the DDEV site.