FireCMS: an admin panel framework that generates itself from a Firestore schema

A framework for a database you already have

FireCMS is described as a developer-first, open-source Firebase CMS and Firestore admin panel framework built with React and TypeScript. It connects natively to Firebase and Firestore, and to MongoDB, and auto-generates CRUD interfaces, forms and data management tools from your schema.

That framing decides most of the adoption questions. This is not a CMS with its own database, it is an administration layer over the database you already run. If your product data lives in Firestore documents, FireCMS is a way to get a decent editing interface in front of them rather than a place to migrate that data into.

The project offers two delivery shapes. FireCMS Cloud is a fully managed SaaS where you connect your Firebase project and go live with no deployment and no maintenance, with a free one-month trial that needs no credit card. The self-hosted route is available in a Community and a PRO flavour, deploys anywhere, gives you full source access, and the documentation describes it as suited to agencies and custom builds. The README badge states MIT.

The audience is therefore a developer rather than an editor, which is the point of developer-first. The schema is code, the extensions are React components, and the whole thing is a set of npm packages in a monorepo rather than an app you configure through a settings page.

The project states it is trusted by teams at Google, Microsoft and IKEA, and by thousands of developers worldwide, and it maintains a Discord community and a documentation site at firecms.co/docs.

Scaffolding a self-hosted project

The self-hosted quick start is a single scaffolding command, and the project offers it for three package managers:

npx create-firecms-app

yarn create firecms-app
pnpm create firecms-app

The documentation points to a full setup guide from there, and the examples in the repository show the shape of a working project. There are directories for a plain example, an Astro example, a cloud example, a graph example, a Next example and a PRO example, and the root package scripts run each of them, with a dev script that changes into examples/example and runs it, and separate pro, next, graph and cloud scripts for the others. There is also a deploy:demo script that runs the deploy step in the PRO example.

The repository is a pnpm workspace with lerna handling the build across packages, and the build script is simply lerna run build. There are also deploy scripts for staging, production and canary, each of which runs the lerna build first and then the deploy step in the saas directory, and the production deploy ends by creating an annotated release tag named with a timestamp.

The source tree is broader than a single library, and the directory listing shows why. Besides the packages and examples there is a website-astro directory for the documentation site, a demo_backend, a discord-bot directory with its own Cloud Build configuration, a saas script target in the root package for the hosting product, and a set of agent-oriented directories, .agent, .agents, .claude, .antigravity, plus an .mcp.json and an .aiexclude. A separate .opensource directory and an AGENTS-style setup suggest the project uses an open development tooling configuration alongside the code.

Schema in code, and a visual editor over the same model

The schema is the central artefact, and FireCMS offers two ways to produce it.

The first is declaring it in code, which is the developer-first path. The second is the visual schema editor, which lets you design Firestore data models from the UI and modify them there, with automatic schema inference from existing collections. The inference path is the interesting one for adoption, because it removes the need to describe a database you already have. Connect to an existing Firestore or MongoDB database and let FireCMS infer the schema, and the documentation claims you can go from zero to admin panel in minutes.

Inference is also the place where the risk sits. An inferred schema is a guess about the shape of your documents, and a guess that is wrong in a subtle way produces an editing interface that silently does the wrong thing, for example treating a string field that sometimes holds a number as a string. The visual editor exists partly to let you correct that inference, and the safest workflow is to run inference against a copy of a production collection and review the result before pointing the CMS at live data.

The model supports more than twenty field types, and the field types listed in the documentation include Firestore references, markdown, file uploads, arrays, maps, enums, date and time, and geopoints, with advanced validation rules on top. For anything outside that set you write a custom field as a React component, and there is a separate entity view mode that opens a document in a side panel or expands it to full screen, with subcollection navigation, custom views, secondary forms, and undo and redo plus local draft persistence.

The collection view, the AI features, and what they call

The collection view is the screen most users will live in, and it is described as a spreadsheet-style, windowed view with inline editing, real-time updates, filtering, sorting and text search. You can switch between a spreadsheet table, a card grid and a Kanban board, and the Kanban option is automatically available for collections that have enum properties, which is a nice piece of domain awareness for a generic tool.

The AI features are the most distinctive part and the part that changes what the CMS is for. AI Autofill generates titles, descriptions and translations with context-aware prompts powered by OpenAI and Google Gemini. AI Collection Generation takes a natural language description of your data model and builds the schema. And DataTalk lets you query and update your data in natural language, with examples like showing all products over a hundred dollars or updating all out-of-stock items.

DataTalk is the feature that turns an admin panel into something more, since an update across a collection in natural language is a bulk operation with a natural language interface. It is also the feature with the sharpest edge, because a bulk update driven by a language model is a bulk update you cannot review before it runs, and Firestore has no undo. The safest pattern is to use the natural language to generate the query, inspect the matched documents, and then confirm the write.

The AI features also have a deployment consequence. They call out to OpenAI and Google Gemini, so a self-hosted install in a restricted network either does not have them or needs its own credentials and egress. The core transforms, forms and validation do not need that, and the documentation is explicit that your data stays in your Firebase project with no vendor lock-in for the non-AI paths.

Permissions live in Firebase rules, not in the CMS

Roles, permissions and user management are a first-class feature, described as granular role-based access control for collections, fields and actions, with users and roles manageable from the UI or permissions definable programmatically in code. There is a dedicated security page in the documentation, and the security-by-design claim is that your data stays in your own Firebase project.

The important thing to understand is where the enforcement happens. The claim that there is no vendor lock-in means the data is in your project, and it also means the rules are your project's rules. FireCMS is an interface that respects the security rules you have written, and it is not the thing deciding who may read or write a document. A role configuration in the CMS UI describes what the interface offers; Firestore security rules decide what the data layer actually permits.

That division is correct and is the right design for a tool that claims to add no lock-in, but it means an adoption has two pieces of work rather than one. You configure roles in the CMS and you write security rules in the Firebase project, and the two have to agree. A team that assumes the CMS roles are the access control will find out otherwise at the worst time.

Two other feature areas round out the picture. Data import and export covers CSV, JSON and Excel with a field mapper and validation UI on import, and export of Firestore collections to CSV or JSON with customizable date formats and array serialization. And there is entity history with an audit trail, tracking every document change, letting you compare versions, see who changed what and when, and revert to a previous state. The audit trail depends on the same rule-based access control, since it records who did what.

Where the framework stops

The first limitation is the data model. FireCMS is built around documents and collections, and it supports Firestore and MongoDB, but the Firestore shape is the one the features are written for: references, geopoints, subcollections, the array and map types. If your data is relational, you are either modelling it in a document store already or using something else, and no amount of schema configuration will change that.

The second limitation is the dual licensing shape, and the repository metadata needs reading carefully. The repository is identified as having a custom licence that GitHub cannot classify, with a LICENSE file at the root, while the README badge states MIT and the self-hosted section describes an MIT licensed core with a PRO tier. So the core is MIT and something beyond it is not, and the PRO features and the cloud product are where the terms differ. For a team that wants to self-host the Community edition, the core MIT terms are the relevant part, and the boundary between the Community and PRO packages is what you need to check before building on the paid features.

The third limitation is the AI dependency, which I covered above but is worth naming as a boundary for procurement. A self-hosted install that must not send data outside the customer's infrastructure cannot use the autofill, collection generation or DataTalk features as they are described, because they are powered by external model providers.

On maintenance, the repository is not archived, the last push was on 2026-10-14, and the releases are v3.2.0 and v3.1.0 both on 2026-06-23 after v3.0.0 on 2025-12-03. The v3.0.0 release is the kind of major version that carries a migration, and the project maintains a CHANGELOG.md, a CONTRIBUTING.md, a SECURITY.md, a PUBLISHING.md and a REBASE_PORT_NOTES.md, the last of which suggests active work on porting the repository across branches.

Editorial conclusion

FireCMS suits a team that already stores its data in Firestore or MongoDB and needs an internal back office, a catalogue manager or a headless CMS in front of it without writing the CRUD layer by hand. It is a poor fit if you want a self-contained CMS with its own datastore, since the whole design is a view onto data you already have, and a poor fit if you need the AI features to work in an air-gapped environment, since they call out to OpenAI and Google Gemini. Before adopting, run npx create-firecms-app against a non-production project, connect a schema inference to a copy of an existing collection to see how well the generated model matches, and read the permissions documentation, because access control is enforced in your own Firebase rules rather than by FireCMS itself.

Frequently asked questions

Official sources

1. firecmsco/firecms on GitHub
2. Issues
3. Project website
4. README
5. Releases