Firebase Setup: Firestore, Auth & Storage

Este conteúdo não está disponível em sua língua ainda.

FireCMS talks to your own Firebase project — it never proxies or copies your data. That means the CMS can only do what your Firebase project lets it do, so a few things need to be switched on before the admin panel becomes useful.

This page covers the four pieces FireCMS actually depends on, and what each one unlocks:

Firebase service	What FireCMS uses it for
Firestore	Every collection, document and form in the CMS
Web app config	The credentials object you pass to the CMS
Authentication	Who can open the panel, and their role
Storage	File, image and video fields

Firebase’s own docs cover each service in general; everything below is specific to running FireCMS against it.

1Firestore2Web app3Authentication4Storage

Enable Firestore. A default project denies every read and write until you change the rules — FireCMS will connect and show nothing.

// everything private by default
match /{document=**} {
  allow read, write: if false;
}
// then open up what an editor needs
match /products/{id=**} {
  allow read: true;
  allow write: if request.auth != null;
}

Firestore

Enable Firestore in your project. FireCMS reads your existing documents to infer collection schemas, so if you already have data, you already have a CMS — there is no import step.

A default Firestore project ships with rules that deny all reads and writes. Until you change them, FireCMS will connect but every collection will look empty.

The simplest rule set that lets an authenticated editor work is:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

That is fine for a private back-office, but rules should match your domain. A more realistic set — public product reads, authenticated writes, and users restricted to their own document — looks like this:

rules_version = '2';
service cloud.firestore {

    // everything is private by default
    match /{document=**} {
      allow read: if false;
      allow write: if false;
    }

    match /databases/{database}/documents {
        // anyone may read products; only signed-in users may write
        match /products/{id=**} {
          allow read: if true;
          allow write: if request.auth != null;
        }
    }

    // users may only touch their own user document
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
}

Rules are enforced per collection. If a collection shows up empty in FireCMS but has documents in the Firebase console, a rule is almost always the reason.

Web app

In your project settings, create a Web app. Firebase gives you a configuration object — that object is what you pass to FireCMS.

You can link the web app to Firebase Hosting at the same time, which makes deploying your CMS a one-command affair. You can also create the Hosting site later and link it to an existing web app.

Authentication

Enable Authentication so users can get past the login screen. FireCMS builds its roles and per-collection permissions on top of Firebase Auth, so this is also where access control starts.

Vite serves the dev server at http://127.0.0.1:5173 by default, and Firebase Auth rejects sign-ins from domains it does not know. Add that URL to the authorised domains in the Firebase console, or run the dev server on http://localhost:5173 and authorise that instead.

Storage

Enable Firebase Storage if you want to use the CMS file, image or video fields. FireCMS writes uploads to the project’s default bucket.

Downloads from Storage can fail with a CORS error depending on your bucket configuration. Create a cors.json:

[
  {
    "origin": ["*"],
    "method": ["GET"],
    "maxAgeSeconds": 3600
  }
]

and apply it with:

gsutil cors set cors.json gs://<your-cloud-storage-bucket>

Narrow origin to your own domains before going to production.

Next steps

With Firestore, Auth and Storage in place, your Firebase project is ready:

Self-hosted quickstart — scaffold and run the CMS locally
FireCMS Cloud quickstart — connect the project and skip the hosting
Firebase App Check — lock the panel down once it is live