A Firestore CMS
that builds itself
Point FireCMS at a Cloud Firestore collection and it reads the documents already there, infers the field types, and generates the tables, forms and validation your team needs to edit them.
Simple short text
Select a property widget
Simple short text
Text with multiple lines
Text with advanced markdown syntax
Text with URL validation
Text with email validation
The value refers to a different collection (it is saved as a string)
Boolean true or false field (or yes or no, 0 or 1...)
Select one text value from within an enumeration
Select multiple text values from within an enumeration
Select a number value from within an enumeration
Select multiple number values from within an enumeration
Select a user from the user management system. Store the user ID.
Simple number field with validation
Input for uploading single files
Input for uploading multiple files
The value refers to a different collection (it is saved as a reference)
Multiple values that refer to a different collection
A date time select field
Group of multiple fields
Flexible field that allows the user to add multiple key-value pairs
A complex field that allows the user to compose different fields together, with a key/value format
A field that gets repeated multiple times (e.g. multiple text fields)
The visual schema editor — field types inferred from existing documents, then refined.
What is a Firestore CMS?
A Firestore CMS is a content management layer that edits Cloud Firestore documents in place. Your collections stay where they are; the CMS supplies the thing Firestore deliberately leaves out — a structured, permissioned, human-friendly way to change the data.
The hard part is not rendering a table. It is mapping Firestore's document model — nested maps, arrays, references, subcollections, timestamps — onto controls a non-developer can use without corrupting anything.
Your Firestore model, mapped
Every Firestore type gets a control that makes sense for it — including the two that usually break admin tools, references and subcollections.
| Firestore | In the CMS |
|---|---|
| Collection | A table view with filtering, sorting and inline editing |
| Subcollection | Nested, editable from inside the parent document |
| DocumentReference | A searchable picker over the referenced collection |
| Map | A grouped set of typed subfields |
| Array | Reorderable repeatable entries of any field type |
| Timestamp | Date and time pickers |
| String (long) | Markdown or a Notion-style rich text editor |
| Storage path | An upload field writing to Firebase Storage |
Edit without leaving the list
Documents open in a side panel over the collection, so editors keep their place. Block content, file uploads and a live preview of the result all sit in the same view.
- Real-time
- Firestore listeners keep the views live, so two editors on one collection see each other's changes.
- Validation
- Required, min/max and regex rules are enforced in the form, before anything reaches Firestore.
More than a data browser
- Schema inference
- Existing documents are sampled to guess field types, so a legacy collection is usable immediately — then refined visually or in TypeScript.
- Import and export
- Bulk-load a collection or pull it back out, instead of writing another one-off migration script.
- Permissions
- Roles and per-collection create / edit / delete rules on top of Firebase Auth, resolvable per user or per document.
- Text search
- Firestore has no native full-text search — plug in an external index and search from the same table view.
Firestore CMS FAQ
- What is a Firestore CMS?
- A Firestore CMS is an editing interface built directly on Cloud Firestore. Instead of copying content into a separate database, it maps your existing collections and documents to typed forms, so your app keeps querying the same Firestore data while your team edits it through a proper UI.
- Do I have to restructure my Firestore data?
- No. FireCMS imposes no data structure restrictions. It reads the documents already in a collection, infers the field types, and generates the views from that. Collections that were designed long before you adopted a CMS still work.
- Does it handle subcollections?
- Yes. Subcollections are first-class: you can open a document and edit its subcollections inline, nested as deeply as your model goes.
- How are Firestore references handled?
- Reference fields render as searchable pickers over the target collection, so editors choose a related document instead of pasting a document path. Arrays of references work the same way.
- Can I filter, sort and search my Firestore collections?
- Yes — filtering and sorting map onto Firestore queries, and full-text search can be plugged in through an external index when Firestore's native querying is not enough.
- Can I import and export Firestore data?
- Yes. FireCMS supports importing data into a collection and exporting it back out, which covers bulk edits and migrations without one-off scripts.
- Is the data still mine?
- Entirely. The content never leaves your Firestore instance — FireCMS reads and writes it in place under your own security rules, so there is nothing to migrate if you stop using it.
