Toolpad Core in Maintenance Mode: What the React Dashboard Components Still Give You

The problem Toolpad Core addresses: dashboard scaffolding you would otherwise write yourself

Every internal tool starts with the same work. A sidebar that collapses, a header with a title and actions, breadcrumbs that follow the route, a navigation model that survives a refresh, and a page shell that does not fight the router. None of that is the product you were asked to build, and all of it has to exist before the first useful screen appears. Toolpad Core is MUI's answer to that layer. The README describes it as "a set of high level React components that abstract common concepts such as layout navigation and routing", aimed at helping you build and maintain dashboards and internal tooling faster. It sits on top of Material UI rather than replacing it, so the styling system, theme provider and component set you already know still apply. The audience is React developers with a Material UI codebase, especially teams building admin panels, CRUD screens and self-hosted internal tools, which is exactly the topic list the repository carries. If your stack is not React, or you have deliberately moved off Material UI, this is not a layer you can use.

What sits inside the repository: components, a Studio branch, and a deprecation

The repository holds two things with different statuses, and conflating them is the most common mistake when reading about Toolpad. The first is Toolpad Core, the React component set published as @toolpad/core, which the README presents as the current product and links to a documentation section on mui.com. The second is Toolpad Studio, described in the README as "a self-hosted low-code admin builder designed to extend the Toolpad Core React components", with drag-and-drop from a catalogue of pre-built components and connections to data sources. Studio is explicitly deprecated. It is not deleted: the README states the project can be found in the toolpad-studio branch of the repository, where it can also be published from. That branch arrangement matters operationally. If you clone the default branch, you are not looking at the Studio source, and if you file an issue about Studio behaviour against master, you are pointing at the wrong tree. The beta notice in the README applies to the project as a whole: "Toolpad is in its beta stages of development."

The maintenance warning is the first thing to read, and it is unambiguous

The README opens with a warning block, placed above the logo, that states the maintainers are primarily focused on other projects and are not actively working on Toolpad Core, and that they may not be able to respond promptly to issues or pull requests. That is not a hedge buried in a roadmap document. It is the first content on the page. The same warning offers a substitute: the CRUD dashboard template from the Material UI React templates page, described as an easy-to-customize, copy-pastable alternative to the main Toolpad Core components, including dashboard layout and CRUD features. Read together, those two sentences tell you what MUI thinks the migration path looks like. If you want the layout and CRUD pieces and you are comfortable owning the code, copying a template into your repository removes the dependency question entirely. If you want a maintained package with a release cadence behind it, the warning is telling you that this is not it. The repository is not archived, and pushes are still happening, but "not archived" and "actively maintained" are different claims, and only the second one matters for a dependency.

Getting a project running: the CLI and the Studio flag

The README gives three interchangeable invocations for the current setup path, one per package manager:

npx create-toolpad-app@latest pnpm create toolpad-app yarn create toolpad-app

For a Toolpad Studio project, the same CLI takes a --studio flag and a target directory name:

npx create-toolpad-app@latest --studio my-toolpad-studio-app yarn create toolpad-app --studio my-toolpad-studio-app pnpm create toolpad-app --studio my-toolpad-studio-app

That is the full extent of the setup instructions in the README. There is no configuration key reference, no environment variable list and no deployment section in the material; those live in the documentation site, which the README links to for both Core and Studio. The README also points to a list of example apps on the docs site, which is the practical place to look before scaffolding, because the CLI gives you a starting point rather than a description of what the generated project contains. Note that the Studio path is documented in the README of a deprecated product. The command still exists and the README still shows it, but starting a new Studio project means starting on a branch that MUI has already retired from active development.

The beta label, the deprecated Studio, and the release cadence you are signing up for

Three signals in the material point the same direction, and none of them is a reason the code is bad. The first is the beta notice, which has not been lifted. The second is the deprecation of Studio, the low-code builder that the topic list and the project description still advertise. The third is the release history: v0.16.0 in June 2025, v0.15.0 in May 2025, v0.14.0 in April 2025. Monthly minor releases through that window, then a gap to the most recent push in June 2026. The version numbers themselves are the tell. Sixteen minor releases and no 1.0 means the API surface has never been declared stable. For a dashboard shell that is mostly layout and routing, that may be tolerable, because the surface you touch is small. For anything you build on top of it, a minor version bump can move things. The realistic failure mode is not a broken build tomorrow. It is a security or compatibility fix for a dependency that you end up applying yourself, or a Material UI major version that Toolpad Core has not been updated for, with no timeline for when it will be. The README's own suggested alternative, the CRUD dashboard template, exists precisely because MUI expects people to take the code rather than the dependency.

Where Toolpad Core fits against Refine and the template route

The closest comparison in the internal-tools space is Refine, and the difference is in what each one owns. Refine is built around data and resource abstractions: you describe a resource, wire it to a data provider, and the framework generates list, create, edit and show views with hooks for the data layer. Toolpad Core does not do that. The README frames it as high level React components that abstract layout navigation and routing, built on Material UI. There is no data provider concept in the material, no resource model and no generated CRUD views. Toolpad Studio was the piece that approached the data-source-connection problem, and it is deprecated. So the honest comparison is this: if your difficulty is connecting many backends and generating CRUD screens from a schema, Refine addresses that directly and Toolpad Core does not. If your difficulty is the shell around the screens, and you are already on Material UI, Toolpad Core is a smaller, more targeted layer. The third option is the one MUI itself recommends in the warning: copy the CRUD dashboard template, own the layout code, and skip the dependency entirely. That route costs you the upstream fixes you would never have received anyway.

MIT licence, upgrade cost, and what the licence does not settle

Toolpad is MIT licensed, and the README links to the licence file in the material-ui repository rather than a local one, which is worth knowing if you are auditing dependencies and expecting a LICENSE at the root of this repo. MIT is permissive: you can use, modify and redistribute the code, including in commercial and closed-source products, provided the copyright notice and permission notice are preserved. That is a summary of the licence's usual terms, not legal advice, and it says nothing about the licences of the Material UI packages Toolpad Core is built on, which you should check separately because they are separate packages with their own terms. The practical cost of adopting Toolpad Core is not licence fees. It is the upgrade path. With monthly minor releases through early 2025 and a stated lack of active work, you should assume that moving to a new Material UI major or a new React major will be your problem to solve. Budget for reading the changelog link in the README yourself before each upgrade, and for the possibility that a future release never arrives. The cheapest mitigation is the one MUI suggests: keep the layout code thin enough that replacing it with a copied template is a day of work rather than a quarter.

Editorial conclusion

Adopt Toolpad Core only if you are building a Material UI dashboard or internal tool and you accept that the maintainers are not actively working on it, so fixes and features will come slowly or not at all. Do not adopt it if you need a supported component library with a response time on issues, or if you were hoping for the drag-and-drop low-code builder: Toolpad Studio is deprecated and lives on a separate branch. Before committing, check the roadmap page and the release history for how far apart the last releases are, read the deprecation notice on the toolpad-studio branch, and confirm which layout and CRUD components you actually need, since the README points to the free CRUD dashboard template as a copy-pastable replacement for the main Toolpad Core components.

Official sources

1. License: MIT
2. mui/toolpad on GitHub
3. Project website
4. README
5. Releases