Omnibaas, a provider-agnostic Infrastructure-as-Code compiler for BaaS services

Omnibaas, an open-source Infrastructure-as-Code compiler for BaaS services, launched as an early proof of concept to enable provider-agnostic backend deployment. The tool allows developers to define a universal schema in YAML and deploy it across platforms like Appwrite, Supabase, or PostgreSQL, aiming to solve vendor lock-in issues. Currently supporting Appwrite, Omnibaas plans to add Firebase, Supabase, and PostgreSQL adapters with community contributions.

Current status: Early Proof of Concept. APIs and configuration format may change. Omnibaas is a provider-agnostic Infrastructure-as-Code compiler for Baas services: backend.yaml │ ▼ Omnibaas Terraformer │ ▼ Provider adapter │ ┌───────────┴───────────┐ ▼ ▼ ▼ Appwrite Supabase PostgreSQL Nowadays Baas services are strongly growing in popularity, especially thanks to no-code and AI development tools that choose to use them, but there's a problem, once your application is built around a BaaS provider, migrating to another one becomes increasingly difficult, even if pricing, reliability, or available features change over time , despite most BaaS providers share the same core features. If you share my vision and want to contribute to the development of the projecty, please leave a star : Omnibaas wants to let the developer or the LLM write a universal schema for his backend and deploy it on whatever platform he prefers, whenever he wants to. At the moment Omnibaas is structured as follows: backend.yaml : this is the core of Omnibaas, it defines your backend structures- The terraformer: validates, compares, plans and deploys your backend infrastructure - Adapters: These are essentially connectors, written in a common format known by the terraformer This file defines the schema of your backend basically like .prisma file for prisma ORM ; , it is intended to be written in a YAML format. At the moment you can define: - Auth methods that you want to enable on your baas provider - dbs and if you want them to be enabled to user or not - tables and fields with four types of data string, number, boolean, datetime and required attribute "?" at the end of the field key I left a backend.yaml sample for you. Create a new Instance of the Terraformer Class to start using Omnibaas, at the moment it expose 4 methods: - validate: pass it a new configuration to validate it through zod and be sure to avoid annoying errors later - introspect : translate your current provider configuration in Omnibaas format - plan: pass your current and future configurations to get a summary of what the terraformer will do and the implementation plan summary example: Following auth methods will be disabled: magic-url, email-otp, anonymous, invites, jwt Following dbs will be created: db1, db2 Models restaurant, hotel of db1 DB will be created Models photo, video of db2 DB will be created - apply : pass it your implementation plan and let the terraformer do the rest for you You can find a clear example of terraformer usage in example.ts Terraformer class is basically provider agnostic , the adapters act like bridges between it and backend providers. With this structure it would be possible to call the introspect method for a provider and re-apply its configuration on another maybe cheaper or faster in seconds. At the moment I've written only the adapter for appwrite baas /adapters/appwrite.ts . Adapter class MUST expose methods described in adapter interface in /types/types.ts . You need to connect Omnibaas to your Baas ? Just go ahead and write your adapter. ✅ Appwrite adapter 🚧 Add support to more types 🚧 Firebase adapter 🚧 Supabase adapter ⬜ Add storage support ⬜ PostgreSQL adapter long-term Omnibaas structure is born to be community driven, so do not hesitate in opening issues or pull requests. Want to support a new provider? Implement the adapter interface and open a pull request. Every provider extends the ecosystem for everyone. : MIT TypeScript Status: PoC Contributions Welcome