Firebase

Go to console.firebase.google.com → click 'Add project'. Give it a name (e.g. 'my-bubble-app'). You can disable Google Analytics for the project if you don't need it — it doesn't affect Firestore or Auth functionality. Click through to create the project. Once the project is created, click the web icon `</>` on the project overview page to register a web app. Give it a nickname (e.g. 'Bubble Frontend') and click 'Register app'. Firebase will display your project's configuration object: ```javascript const firebaseConfig = { apiKey: "AIzaSyXXXXXXXXXXXXXXXXXXXXXXXXXXXX", authDomain: "your-project.firebaseapp.com", projectId: "your-project-id", storageBucket: "your-project.appspot.com", messagingSenderId: "123456789", appId: "1:123456789:web:abcdef123456" }; ``` Copy all six values. These are client-safe keys — they are designed to be used in browser code and are published in Firebase's public documentation as safe to embed in frontend apps. The security boundary is your Firestore Security Rules and Firebase Auth state, not these config keys. Next, go to the project's Build section → Firestore Database → Create database. Choose your preferred Cloud Firestore location (pick the region closest to your users). Start in test mode for initial setup — you'll tighten Security Rules in Step 4. If you're using Realtime Database instead of Firestore, go to Build → Realtime Database → Create database.

1{
2  "apiKey": "AIzaSyXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
3  "authDomain": "your-project.firebaseapp.com",
4  "projectId": "your-project-id",
5  "storageBucket": "your-project.appspot.com",
6  "messagingSenderId": "123456789",
7  "appId": "1:123456789:web:abcdef123456"
8}

Still in the Firebase Console, go to Build → Authentication → Get started. On the Sign-in method tab, enable the providers your Bubble app will use. At minimum, enable 'Email/Password' — this is what you'll use to bridge Bubble's native auth to Firebase Auth in Step 5. Click 'Email/Password' → Enable the first toggle (Email/Password sign-in) → Save. If you want Google Sign-In, click Google → Enable → add your project's support email → Save. For Google Sign-In to work from your Bubble domain, you also need to add your domain to the authorized domains list: Authentication → Settings tab → Authorized domains → Add domain → enter `yourapp.bubbleapps.io` and any custom domain you've connected. For test mode, you can also manually create a test user in Authentication → Users tab → Add user. This is helpful for testing Security Rules before connecting Bubble — you can verify that reads/writes work when authenticated before introducing the Bubble workflow layer.

In your Bubble app, go to the Plugins tab in the left sidebar → click 'Add plugins'. In the search bar, type 'Firebase'. You'll see the Zeroqode Firebase plugin in the results. Click it to view the details — check the current price on zeroqode.com before purchasing, as pricing and licensing terms change. Install the plugin. After installation, click on the Zeroqode Firebase plugin in your Plugins list. You'll see configuration fields for your Firebase project. Fill in the six values from Step 1: - **API Key**: your `apiKey` value - **Auth Domain**: your `authDomain` value - **Project ID**: your `projectId` value - **Storage Bucket**: your `storageBucket` value (required if using Firebase Storage) - **Messaging Sender ID**: your `messagingSenderId` value - **App ID**: your `appId` value Do NOT mark these as private — they are intentionally client-visible keys. The Zeroqode plugin handles Firebase SDK initialization on page load once these values are configured. After saving the plugin settings, add a workflow on your main page (or a shared Header reusable element): Page is loaded → Plugin → Zeroqode Firebase → Initialize Firebase. This action must run before any other Firebase actions on the page. If you have multiple pages that use Firebase, add this initialization action to each page's 'Page is loaded' event, or use a Header reusable element that appears on all pages.

In the Firebase Console → Firestore Database → Rules tab, you'll see the current rules. Test mode rules allow all reads and writes for 30 days — never use these in production. Replace them with rules appropriate for your app. For a basic app where logged-in Bubble users can only read and write their own documents: ``` rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { // Users can only read/write their own profile match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; } // Authenticated users can read shared content match /content/{docId} { allow read: if request.auth != null; allow write: if false; // Only admins via Backend Workflow } } } ``` Click Publish. These rules are now live — any Firestore operation from the Bubble plugin will be evaluated against them. Important: these rules check `request.auth.uid` — the Firebase Authentication UID of the currently signed-in Firebase user. Bubble's native auth session has no connection to `request.auth`. Until you bridge Bubble's login to Firebase Auth in the next step, all reads/writes from the plugin will fail with 'Missing or insufficient permissions' if your rules require authentication.

1rules_version = '2';
2service cloud.firestore {
3  match /databases/{database}/documents {
4    match /users/{userId} {
5      allow read, write: if request.auth != null && request.auth.uid == userId;
6    }
7    match /content/{docId} {
8      allow read: if request.auth != null;
9      allow write: if false;
10    }
11  }
12}

This step solves the #1 Bubble-Firebase integration problem. After a user signs in or signs up in Bubble using Bubble's native auth, you must also sign them into Firebase Auth so the Firebase SDK has an authenticated session for Security Rules. In your Bubble Sign Up workflow (or Log In workflow), after the Bubble sign-up/sign-in action completes, add the following plugin action: Plugins → Zeroqode Firebase → Firebase Auth: Sign In with Email and Password. Map the parameters: - **Email**: Current User's email - **Password**: the password input element's value (this is available right after sign-up but NOT after subsequent page loads) For subsequent page loads (when a user returns to your app), you need a different approach. The Firebase SDK persists auth state in local storage — if the user previously signed in during the same browser session (or enabled 'Remember me' in Firebase Auth), the SDK automatically restores the session on page load. Add a workflow: Page is loaded → Plugins → Firebase: Check Auth State → if user is not signed in AND Bubble user is logged in → redirect to login or trigger re-authentication. For production apps where you cannot pass passwords around after sign-up, the cleaner solution is Firebase Custom Auth Tokens: a server-side Backend Workflow calls the Firebase Admin REST API to generate a custom token for the current Bubble user's UID, then the plugin signs in using that custom token. This approach doesn't require storing or re-sending passwords — it uses cryptographic token exchange instead. RapidDev's team has built this custom token bridge pattern multiple times — book a free scoping call at rapidevelopers.com/contact if you'd like guidance on the right auth architecture for your use case.

Now that Firebase is initialized and auth is bridged, you can use the plugin's Firestore actions in any Bubble workflow. Here are the most common patterns: **Reading a Firestore collection into a Repeating Group**: In the Bubble workflow editor, add action: Plugins → Firebase → Get Firestore Collection. Set the collection path (e.g. `/tasks`), and optionally a where clause (e.g. `userId == Current Firebase User's UID`). The plugin stores the results in a plugin-specific state variable. Add a condition on your Repeating Group's data source: use the plugin's state for the collection data, with the field names matching your Firestore document structure. **Creating a Firestore document**: Add action: Plugins → Firebase → Create Firestore Document. Set the collection path (e.g. `/tasks`), and the document data as a JSON object with your field values. The plugin auto-generates a document ID, or you can specify one. **Real-time Realtime Database listener**: For live-updating data, use Plugins → Firebase → Listen to Realtime Database. Set the path (e.g. `/presence/{userId}`). The plugin updates its state whenever the data at that path changes, which triggers Bubble's reactive data bindings to update the UI without a page refresh. **Cleanup**: Call the plugin's 'Remove Realtime Database Listener' action when the page is no longer visible (use Bubble's 'Page will be destroyed' event on single-page apps) to prevent memory leaks from orphaned listeners. Always test Firestore operations in Bubble's preview (Test mode) before deploying — the Bubble preview runs on HTTPS, which Firebase Auth requires. Check the Firebase Console → Firestore Database → Data tab to confirm documents are being created and updated as expected.