Rowy

Rowy is an open-source low-code backend platform purpose-built for Firebase and Google Cloud Platform. It replaces the Firestore console with a full-featured spreadsheet interface that supports CRUD operations, multi-column filters, sorting, bulk CSV/JSON/TSV import and export, column locking and freezing, and multiple named views of the same collection—all in real time.

Beyond data management, Rowy embeds a Monaco-powered code editor that lets you write and deploy JavaScript or TypeScript Cloud Functions triggered by field-level data changes, without ever leaving your browser. You can use any NPM module or call any external API, and pre-built extension blocks connect to services like SendGrid, Algolia, Twilio, BigQuery, and Slack with minimal configuration.

All data and backend logic remain exclusively on your own GCP project. Rowy is deployed as a Cloud Run instance that operates only within your infrastructure, so nothing passes through Rowy’s servers. The result is a platform that gives non-technical team members an Airtable-like data interface while giving developers full programmatic control—without forcing either group to switch tools.

What You Get

• Spreadsheet UI for Firestore - Browse, create, edit, and delete Firestore documents in a familiar grid with column freezing, resizing, hiding, reordering, multi-field filters with AND/OR logic, and multiple named views per collection.
• In-Browser Cloud Functions Editor - Write and deploy JavaScript/TypeScript Cloud Functions with Monaco Editor, full NPM access, GCP Secret Manager integration, and real-time build logs—triggered on field-level data changes without any local toolchain.
• 30+ Typed Field Columns - Rich column types beyond plain text: Date/Time pickers, Single/Multi Select with color chips, Image and File uploaders to Cloud Storage, Rich Text (TinyMCE), Markdown, JSON viewer, Code editor, GeoPoint, Reference, Duration, Formula, and more.
• Action Field Buttons - Add clickable trigger buttons to any row that call a Cloud Function, enabling non-developers to run backend workflows (send email, update status, call an API) with a single click from the data table.
• Pre-Built Extension Blocks - Connect to SendGrid, Algolia, Twilio, BigQuery, Slack, and WhatsApp via pre-built code blocks, or define custom webhook endpoints to ingest data from Typeform, Webflow, or any HTTP source.
• Role-Based Access Controls - Table-level and field-level permissions tied to Firebase Authentication roles, with built-in user management, customizable views per role, and audit logging for data changes.

Common Use Cases

• Internal admin dashboard for SaaS products - A product team uses Rowy as their primary ops interface to manage user accounts, toggle feature flags, review support tickets stored in Firestore, and trigger email workflows via SendGrid—replacing a hand-built admin panel.
• Rapid content management for Firebase apps - A mobile app team connects Rowy to their Firestore content collections, enabling marketing and editorial staff to add and edit in-app content with image uploads and rich text without requiring developer involvement.
• Webhook-driven data collection pipeline - A growth team configures Rowy webhooks to receive Typeform survey responses and Webflow form submissions directly into structured Firestore collections, with Derivative field automation to compute scores and send Slack notifications.
• Low-code fintech backend - A startup builds transaction categorization and user KYC workflows by combining Connector fields (fetching external data), Action fields (triggering compliance checks via Cloud Functions), and Algolia search on their Firestore dataset—without a custom backend service.

Under The Hood

Architecture Rowy is structured around two scoped Jotai atom providers—projectScope for global project state and tableScope for per-table state—which act as dependency-injection boundaries that prevent state leakage between concurrent table views. Data enters the system through headless source components (TableSourceFirestore, ProjectSourceFirebase) that subscribe to Firestore snapshots and write into atoms when rendered, cleanly separating data concerns from the UI layer. Field types are defined as self-describing IFieldConfig objects registered in a central registry, each bundling its rendering, editing, filtering, export serialization, and form builder behavior into a single declarative unit; adding a new field type requires only implementing this interface without modifying core data flows. The TanStack Table v8 data grid consumes the ordered columns atom, while Firebase serves as the direct backend abstraction through typed hooks that bind real-time collection snapshots to atoms without an ORM. This architecture is well-organized but creates implicit coupling through atom dependency chains that could become brittle as the feature surface expands.

Tech Stack React 18 and TypeScript form the foundation, bundled via Vite with SWC for fast builds and hot reload. Firebase v9 provides the complete backend—Firestore for real-time structured data, Firebase Authentication for user management, and Cloud Storage for file uploads, with local Firebase Emulators supported for development. State management uses Jotai with scoped providers, while SWR handles server-fetched resources like function build logs. Material UI v5 with Emotion powers the design system, complemented by TanStack Table v8 for the virtualized data grid, Monaco Editor for in-browser Cloud Functions code editing, TinyMCE for rich text fields, and specialized libraries for date pickers, color pickers, and drag-and-drop column reordering. Deployment targets Firebase Hosting via Cloud Build, with Yarn as the package manager and Husky enforcing lint-staged checks on every commit.

Code Quality The project has meaningful test coverage for its core atom reducers—column and row action logic is unit-tested against the Jotai atom system—and integration tests use Firebase Emulators to validate authentication flows. Coverage is not comprehensive across field types and UI components, but the test infrastructure is well-configured with Vitest, Happy DOM, and custom Firebase environments. TypeScript adoption is thorough, with explicit interfaces for table configurations, column schemas, and field configurations. A custom ESLint rule enforces that every Jotai atom access includes an explicit scope argument, catching an entire class of state isolation bugs at lint time rather than runtime. The field config registry pattern and lodash-es tree-shaking demonstrate deliberate engineering discipline, while error handling at the Firebase SDK boundary provides user-facing feedback through snackbars, though granular error recovery paths are limited.

What Makes It Unique Rowy’s most distinctive feature is combining a live Firestore data grid with an in-browser Cloud Functions editor in a single interface, both operating directly against the developer’s own GCP project with zero data passing through Rowy’s servers. The scoped Jotai architecture is a sophisticated solution to multi-table isolation in a SPA, enabling independent table views without global state pollution. The self-describing IFieldConfig registry auto-generates UI, validation, export, and form behavior from a single typed schema per field type—an extensibility model that rivals commercial no-code platforms while remaining entirely code-first. The custom ESLint scope enforcement rule reflects engineering discipline rarely found in frontend-heavy open-source projects.

Self-Hosting

Rowy is released under the Apache License 2.0, a permissive open-source license with no copyleft requirements. You can use it commercially, modify the source code, distribute it, and build proprietary products on top of it without any obligation to open-source your changes. The license requires you to retain the original copyright notice and license text in any distribution, but imposes no usage restrictions on self-hosters.

Self-hosting Rowy requires an active Google Cloud Platform project with Firestore, Firebase Authentication, Cloud Storage, and a Cloud Run instance enabled. The quick-start path uses Rowy’s guided deploy button at rowy.app to provision and configure these GCP resources automatically, but the operational burden thereafter falls entirely on you: monitoring Cloud Run uptime, managing Firebase quotas and billing, handling Firestore index maintenance, and keeping the Rowy frontend deployment current with upstream releases. There is no background update mechanism—upgrades require redeploying the frontend to Firebase Hosting manually.

Rowy also offers a managed cloud version at rowy.app that handles provisioning, updates, and multi-workspace support for connecting multiple Firebase projects. The cloud version adds features like team invitations, table-level admin permission rules, an Airtable import wizard, and an onboarding tutorial that are not available or are more difficult to configure in self-hosted deployments. The self-hosted path is well-documented and suitable for teams comfortable managing GCP services, but the cloud version reduces operational overhead considerably for teams that want to focus on building rather than infrastructure.