Your Firebase
admin panel
Firestore collections, Storage files and Auth users in one interface your whole team can use — with roles, validation and permissions the Firebase console was never meant to provide.
My demo app
/
Products
256
An admin panel over a live Firestore products collection — your documents, your bucket, your auth.
The console is not an admin panel
The Firebase console is a developer tool. It shows raw documents, it has no concept of your data model, and it gives every person who can open it the same total access. Handing it to a content editor or a support agent means handing them a production database with no guard rails.
An admin panel is the opposite: it knows a priceis a number in euros, that category is one of six values, and that support can read orders but not delete them. FireCMS builds that layer directly on the Firebase project you already have — no export, no sync, no second copy of the truth.
- Typed fields, not JSON
- Dates, enums, references, markdown, arrays and maps get real editors with validation, instead of a raw document blob.
- Storage in the same form
- Image, video and file properties upload straight to your Firebase Storage bucket and preview inline.
- Per-collection permissions
- Roles resolved per user or per document, so one deployment serves editors, support and admins differently.
- Nothing leaves your project
- FireCMS runs against your Firestore instance under your own security rules. There is no migration to adopt it and none to leave it.
One deployment, three panels
This is the thing the Firebase console cannot do at all: everyone who can open it sees everything. In FireCMS the role decides which collections exist, which actions are available and which fields are writable — so the same deployment is a different tool for each person who signs in.
Roles
| Role | Is admin | Default permissions | |
|---|---|---|---|
| |||
| |||
|
Or let an agent build it
FireCMS ships an MCP server, so Claude or any MCP client can list your Firebase projects, connect one, read the shape of its collections and generate the whole panel — without you opening a config file.
Connect my Firebase project to FireCMS and build the collections from what's already in Firestore.
Where the defaults stop, React starts
The reason teams abandon generic admin tools is the one field the tool cannot represent. In FireCMS any React component can be a form field, and any React view can be a page in the navigation — so the panel bends to your domain instead of the other way round.
MedicalMotion
bodyParts: ["chest", "triceps", "abs"]
location: { lat: 40.4262, lng: -3.7038 }Hosted, or hosted by you
FireCMS Cloud
Connect your Firebase project and have a working admin panel in minutes. Automatic updates, custom React views still supported.
Start buildingSelf-hosted
MIT-licensed source in your own infrastructure, with custom auth, SSO and whatever compliance story you need.
Set up your Firebase projectFirebase admin panel FAQ
- What is a Firebase admin panel?
- A Firebase admin panel is an internal interface over your own Firebase project: Firestore documents, Firebase Storage files and Firebase Auth users, presented as tables and forms your team can safely use. It is not the Firebase console — the console is built for developers debugging a project, while an admin panel is built for the people who work with the data every day, with per-collection permissions and validated forms.
- Firebase CMS vs building a custom admin panel — which should I choose?
- Building your own gives you total control and costs weeks up front, then keeps costing every time the data model changes: new field types, new validation, file uploads, permissions, pagination, search. FireCMS gives you that layer on day one and stays extensible — any React component can become a form field, and you can add entirely new views. The usual answer is to start with FireCMS and drop to custom code only where the defaults genuinely do not fit.
- Can one admin panel manage Firestore collections and Storage files together?
- Yes. FireCMS treats Firebase Storage as a first-class field type, so an image, video or file property on a Firestore document uploads to your bucket and renders as a preview inside the same form. Editors never touch two tools, and the files stay in your own bucket.
- How do roles and permissions work?
- FireCMS builds on Firebase Authentication. You define roles and per-collection create, edit and delete permissions, and can resolve them dynamically per user or per document — so a marketing editor, a support agent and an admin each see a different panel from the same deployment.
- Do I have to migrate my data?
- No. FireCMS reads the documents already in your Firestore collections and infers a schema from them, so an existing project gets a working panel without an import step. Your data never leaves your Firebase project, and nothing is copied to FireCMS.
- Is there an open-source Firebase admin panel?
- FireCMS is MIT licensed. You can self-host the framework in your own infrastructure with full source access, or use the managed FireCMS Cloud if you would rather not run it. Both support custom React fields and custom views.
- How long does it take to get a Firebase admin panel running?
- Connecting a Firebase project to FireCMS Cloud and generating collections from existing data takes a few minutes. Self-hosting adds the time to scaffold and deploy the app — see the Firebase setup guide for the Firestore, Auth and Storage configuration it expects.
