{"slug": "omnibaas-a-provider-agnostic-infrastructure-as-code-compiler-for-baas-services", "title": "Omnibaas, a provider-agnostic Infrastructure-as-Code compiler for BaaS services", "summary": "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.", "body_md": "**Current status:** Early Proof of Concept. APIs and configuration format may change.\n\nOmnibaas is a provider-agnostic Infrastructure-as-Code compiler for Baas services:\n\n```\n                                       backend.yaml\n                                            │\n                                            ▼\n                                    Omnibaas Terraformer\n                                            │\n                                            ▼\n                                     Provider adapter\n                                            │\n                                ┌───────────┴───────────┐\n                                ▼           ▼           ▼\n                            Appwrite    Supabase    PostgreSQL\n```\n\nNowadays 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.\n\n**If you share my vision and want to contribute to the development of the projecty, please leave a star :)**\n\nOmnibaas 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:\n\n`backend.yaml`\n\n: this is the core of Omnibaas, it defines your backend structures- The terraformer: validates, compares, plans and deploys your backend infrastructure\n- Adapters: These are essentially connectors, written in a common format known by the terraformer\n\nThis 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:\n\n- Auth methods that you want to enable on your baas provider\n- dbs (and if you want them to be enabled to user or not)\n- tables and fields with four types of data(string, number, boolean, datetime) and required attribute (\"?\" at the end of the field key)\n\nI left a `backend.yaml`\n\nsample for you.\n\nCreate a new Instance of the Terraformer Class to start using Omnibaas, at the moment it expose 4 methods:\n\n-\nvalidate: pass it a new configuration to validate it through zod and be sure to avoid annoying errors later\n\n-\n**introspect**: translate your current provider configuration in Omnibaas format -\nplan: pass your current and future configurations to get a summary of what the terraformer will do and the implementation plan summary example:\n\n`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`\n\n-\n**apply**: pass it your implementation plan and let the terraformer do the rest for you\n\nYou can find a clear example of terraformer usage in example.ts\nTerraformer 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.\n\nAt the moment I've written only the adapter for appwrite baas (`/adapters/appwrite.ts`\n\n). Adapter class MUST expose methods described in adapter interface in `/types/types.ts`\n\n. You need to connect Omnibaas to your Baas ? Just go ahead and write your adapter.\n\n✅ Appwrite adapter\n\n🚧 Add support to more types\n\n🚧 Firebase adapter\n\n🚧 Supabase adapter\n\n⬜ Add storage support\n\n⬜ PostgreSQL adapter(long-term)\n\nOmnibaas structure is born to be community driven, so do not hesitate in opening issues or pull requests.\nWant to support a new provider? Implement the `adapter`\n\ninterface and open a pull request. Every provider extends the ecosystem for everyone. :)\n\nMIT\n\nTypeScript\n\nStatus: PoC\n\nContributions Welcome", "url": "https://wpnews.pro/news/omnibaas-a-provider-agnostic-infrastructure-as-code-compiler-for-baas-services", "canonical_source": "https://github.com/davidecampora/Omnibaas", "published_at": "2026-07-07 21:24:21+00:00", "updated_at": "2026-07-07 21:29:13.441041+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Omnibaas", "Appwrite", "Supabase", "PostgreSQL", "Firebase"], "alternates": {"html": "https://wpnews.pro/news/omnibaas-a-provider-agnostic-infrastructure-as-code-compiler-for-baas-services", "markdown": "https://wpnews.pro/news/omnibaas-a-provider-agnostic-infrastructure-as-code-compiler-for-baas-services.md", "text": "https://wpnews.pro/news/omnibaas-a-provider-agnostic-infrastructure-as-code-compiler-for-baas-services.txt", "jsonld": "https://wpnews.pro/news/omnibaas-a-provider-agnostic-infrastructure-as-code-compiler-for-baas-services.jsonld"}}