Manage Firestore Rules and Indexes

The Rules & Indexes tab exists because the underlying Firestore database is shared across the platform.

That means project data is isolated by namespace, but configuration still needs a platform-managed workflow.

What the tab stores

Each project can save:

• a rules template
• template settings
• an optional advanced raw rules fragment
• managed composite index definitions in JSON
• validation status
• the last deployed shared publish revision

Validation rules

Before publish, Flash Launch validates the draft.

Examples of rejected input:

• top-level service cloud.firestore declarations
• top-level match /databases/... declarations
• index entries with missing fieldPath
• index definitions with fewer than two fields
• index fields that try to use incompatible options together

The goal is to keep project-specific drafts inside the correct namespace boundary and reject definitions the current deploy pipeline cannot safely manage.

Publish behavior

Publishing now does four things:

1. validates all active project drafts
2. freezes one shared release artifact so later draft edits do not change the in-flight release
3. queues an async job that deploys rules through the Firebase Rules API
4. reconciles managed composite indexes through the Firestore Admin API

The deploy target is the named Firestore database configured by the platform runtime. The dashboard shows publishing while the job is still running, and index creation can take time to finish propagating.

This is still a Flash Launch platform workflow. It does not try to impersonate the full Firebase Console or a repo-tracked firebase deploy setup.

Recommended approach

• start with a template
• keep advanced fragments small and namespace-safe
• treat index JSON as project-owned managed composite-index metadata
• publish only after the draft is valid
• expect a short delay before newly created composite indexes finish building