Dropmin: What Is It and Why Does It Exist?

About three years ago, I started doing some freelance work offering PHP development. One of the smaller projects I landed involved building an internal data management backend. It was a nice project because the overall scope was well-defined — you could wrap your head around it quickly and understand what needed to be done.

The required data structure wasn’t too complex—just some datasets with optional relationships between each other. The structure wasn’t expected to change often or grow much over time. And if that ever did happen, the client was fine with paying a developer to make the necessary adjustments.

So overall, nothing groundbreaking. All the client needed was a well-enough-looking administration dashboard to manage the data conveniently.

When specializing in a technology, it’s easy to start using it as a golden hammer for every possible use case. Despite that being an anti-pattern, it still happens often. And I find myself doing this too—immediately thinking, “How would I solve this with Drupal?”

Fortunately, I had good company, and someone suggested using a different toolset: EasyAdmin. I agreed it was a good choice—plus, I was already familiar with the underlying framework and programming language. That decision turned out to be absolutely right. EasyAdmin fit the project almost perfectly and met nearly all requirements. Day-to-day use confirmed it was the right choice. Maintenance was straightforward — just regularly updating the codebase via Composer and using simple CI/CD to deploy updates. As a bonus, other developers in the same company were familiar with Symfony and could take over if needed.

Had I used Drupal for that project, I probably could have achieved the same results eventually, but with more risk. No other developers available had experience with Drupal, so I would have been on my own. I’d have had to polish the UI for flexible data management and remove irrelevant elements.

I would also have needed to deal with extra layers of complexity, such as configuration management and Inline Entity Forms, just to get the right editing tools for nested data. Plus, I’d have had to strip out UI components that didn’t make sense for the use case.

The cost of the project could have easily doubled if I’d used Drupal. Maybe someone more skilled could have done it with half the budget, but that wasn’t realistic for me.

After the project ended, I occasionally reflected on how things had gone. EasyAdmin was a great fit. Still, I found myself wondering, “What would I need, so that next time I could use Drupal instead?” It seems I can’t help but try to make my golden hammer even shinier.

Fields Are the Core Value of Drupal Core

This is essentially what drew me to Drupal when I discovered it around 2011, with the release of Drupal 7. The ability for site builders to define content structure via the UI was what set Drupal apart from my regular Symfony + Doctrine ORM projects.

Most things in our CMS platforms are built around fields. We use them in Views, loop over them in code or ECA, and print their values in Twig templates.

The ability to manage data structures—bundles of fields—through the UI remains the foundation of Drupal to this day.

You May Like

Interview

Meet Maya Schaeffer — Candidate for the 2025 Drupal Association Board Election

Interview

Meet Maya Schaeffer — Candidate for the 2025 Drupal Association Board Election

I wanted to leverage this core strength to replicate the kind of data management project I’d done before, except this time, make it possible to adjust the structure without needing a developer.

The "Idea" Was Born

Let me explain the meaning behind the name Dropmin.

My initial idea was to build an administrative backend, similar in spirit to EasyAdmin. That’s where the “min” came from: short for “admin”. Later, I gave it another interpretation: “min” as in “minified Drupal core”. Dropmin doesn’t literally minify Drupal; it just strips away the parts not relevant to data management and hides them from end users.

As for the “Drop” part, yes, it partly references Drupal’s roots. However, the original idea was to allow users to drop a CSV file into the browser and let Dropmin handle the rest. It would automatically suggest a content type with the appropriate field types, let the user confirm, then create the structure and import the data. That idea was later... well, dropped. So now the “Drop” of Dropmin primarily refers to Drupal’s roots.

So... Many... Ideas!

At first glance, Dropmin doesn’t seem like much. But for me, it’s been a personal journey in managing ideas, knowing when and how to pursue them, and when to let go. Sometimes, that means discarding months of work done in your free time.

I have a folder full of ideas with detailed descriptions, and a trash folder for the ones I abandoned entirely.

As ideas grow, projects quickly balloon in complexity. I had total creative freedom, and things got wild fast. Several months in, I had to draw the line. I couldn’t solve everything at once. So I cut things down and re-focused on the original idea.

Throwing away months of work was painful. But getting back to the basics, the mission got clear again. Then I finally knew what was essentially needed.

Cutting Off Complexity

Dropmin’s mission includes a side quest: cut out anything unnecessary, enabling fast and focused content creation and distribution. This also lowers the barrier for newcomers to Drupal.

Installing Dropmin locally doesn’t require setting up a database. By default, it uses SQLite.

Drupal CMS also aims to simplify setup (e.g. recipes and install wizards). Dropmin takes a different approach by removing everything outside its limited scope: being an API-first editorial backend.

It’s Released; Now What?

Earlier I asked, “What would I need, so that next time I could use Drupal?”

Can the answer now be: “Let’s use Dropmin?”

Personally, I think yes; but I’m obviously biased 

Ultimately, it’s up to others to decide.

What Does Dropmin Actually Do?

Dropmin trims down Drupal to its essentials for basic content and data management. It doesn’t offer a UI for installing new modules. You can’t create new roles. Many content-type-specific permissions are gone.

All these cuts are intentional. The backend becomes a standalone tool with minimal room for complexity to grow. What’s available is what you get, and that’s the point. It makes maintenance easier. Dependencies are minimal: just Drupal core, plus Bootstrap icons.

Out-of-the-box Features:

• A dashboard to manage content—no need to configure Views.
• UX helpers: double-click editing, reusable filters, sorting by weight, icons, and content channels for different API users.

Fixed roles:

• Administrator: Full access to everything Dropmin provides.
• Editor: Can manage all content, but nothing else.
• API User: Can access published content via JSON API. Best to create one per external app.

By default, everything is protected. You must log in to access anything, and API access is locked down to JSON API only, unless explicitly set otherwise. Files are always stored as private.

Dropmin is configured to work as a JSON API backend. It integrates seamlessly with the Drupal source plugin for Gatsby.

A Drupal Bridge

I’ve also created a Drupal Bridge, which allows you to access the entire Drupal service container within another PHP application.

Using this, I built a quick Symfony + Tailwind prototype for fun, with most of the coding done by an AI. It worked surprisingly well, and I see potential for future projects—possibly as an alternative to Drupal’s theming system. Why not build the frontend separately?

You’ll find quick starters and examples in the README of Dropmin’s official repository.

That’s It

I hope this post piqued your curiosity about Dropmin and what it can do. Maybe give it a try?

I’d love your feedback—please drop a note in the issue queue on GitLab or Drupal.org. Thanks for reading!

PS: Here’s my first YouTube video showcasing Dropmin. Sorry for the small fonts—next time, I’ll do better 😊