De dónde venimos
No empezamos ayer. Antes de Rebase creamos FireCMS — un CMS open-source para Firebase usado en más de 10.000 proyectos en todo el mundo, con la confianza de equipos en Microsoft e IKEA. Pasamos años descubriendo qué necesita de verdad un desarrollador en su panel admin, qué frustra a los editores de contenido y en qué punto todo CMS acaba rompiéndose.
FireCMS nos enseñó mucho. Que los desarrolladores quieren flexibilidad, no ataduras. Que los usuarios finales quieren algo bonito y simple, no un muro de formularios. Y que las mejores herramientas son las que desaparecen y dejan que la gente haga su trabajo.
Pero FireCMS estaba atado a Firebase. Y mientras veíamos a la industria moverse hacia Postgres, hacia estándares abiertos, hacia la soberanía de los datos, supimos que era el momento de construir algo más grande. Algo que sirviera de base para cualquier proyecto digital — no solo los de un proveedor cloud concreto.
Un problema que se repite siempre
Cada proyecto arranca igual. Necesitas base de datos. Necesitas panel admin. Auth, API, archivos, permisos. Ya lo has montado antes — quizá docenas de veces. Y aun así, cada vez vuelves a empezar de cero o te encadenas a una plataforma que decide por ti qué puedes hacer con tus propios datos.
Las plataformas cloud lo pusieron fácil. Firebase, Supabase, los CMS gestionados… te ahorran toda la fontanería y te dejan ir directo a construir. Pagar a alguien para que opere tu infraestructura nunca fue el problema; casi nadie tiene tiempo de cuidar un clúster de Postgres. El problema es lo que suele venir atado: un esquema que solo puedes leer desde su consola, precios que no puedes prever y una salida que implica reescribirlo todo. La comodidad debería ser una factura que puedes dejar de pagar, no una decisión que no puedes revertir.
Al otro lado están las herramientas self-hosted, pero muchas parecen sacadas de otra época. Difíciles de instalar, dolorosas de personalizar, pensadas para un mundo sin IA, sin TypeScript en todas partes, sin desarrolladores que esperan que las cosas simplemente funcionen.
En qué creemos
La autorización pertenece a la base de datos
Es la convicción sobre la que hemos apostado toda la arquitectura, y la que más discusiones va a provocar. Las reglas de acceso que viven en el código de aplicación son reglas que un endpoint olvidado, un job en segundo plano, un script de migración o una consola SQL directa pueden esquivar sin más: protegen la puerta, no la habitación. En Rebase la autorización es row-level security de Postgres: la escribes en TypeScript, se compila a políticas reales y la aplica la propia base de datos en cada sentencia y para cada llamante. Una tabla sin política no se sirve. Fallamos en cerrado aunque resulte incómodo, aunque tu primera consulta vuelva vacía y tengas que ir a escribir una regla antes de poder seguir. Todos los demás modelos que hemos usado acabaron filtrando. Este no puede.
Tu base de datos es tu fuente de verdad
No creamos bases de datos sombra. No escondemos tu esquema detrás de capas propietarias y no te vamos a pedir que modeles tus datos dos veces. Rebase se conecta a tu Postgres, lee tus tablas y construye encima de lo que ya tienes: lo que ves en psql es lo que sirve la API. Y si mañana borras Rebase, tus datos siguen exactamente donde los dejaste, en un formato que puedes seguir usando. Un backend del que no puedes marcharte no es infraestructura: es un secuestro.
Los agentes son usuarios de tu backend, no un extra pegado encima
Una parte cada vez mayor del código que se escribe contra tu backend hoy la escribe un agente — y los agentes no leen dashboards. Leen esquemas, tipos y mensajes de error. Por eso Rebase incluye un servidor MCP, definiciones de colecciones legibles por máquina, un SDK tipado generado y API keys con permisos acotados; y tratamos un error confuso como un bug, lo lea una persona o un modelo. Las herramientas pensadas solo para un humano haciendo clic en una consola ya se esquivan más de lo que se usan.
El open source es un cimiento, no un feature
Rebase es MIT — cada paquete, cada línea. No es open-core con la mitad útil detrás de una licencia. No es source-available con una cláusula sobre quién puede competir con nosotros. Hemos visto a demasiados proyectos de infraestructura usar «open source» como embudo y relicenciar en cuanto la comunidad había hecho su parte, y sabemos exactamente cómo se siente eso desde fuera. La licencia es la promesa, y MIT es la única versión de esa promesa que no podríamos retirar en silencio más adelante. Y esto llega hasta el fondo: Postgres, Node, Hono, Drizzle — todas las capas bajo Rebase son también open source, y ninguna necesita nuestra infraestructura para funcionar. Eso es lo que convierte «despliégalo donde quieras» en un hecho de la arquitectura y no en una línea de la página de precios. Sí queremos ganar dinero: operando Rebase para equipos que prefieren no operarlo ellos mismos. Esa es una factura que puedes cancelar, y lo que te queda después es exactamente el mismo código que estaba corriendo.
Europa debería ser dueña de su infraestructura
Construimos desde Madrid, y creemos que el arreglo actual — donde la mayoría de las empresas europeas ejecutan sus datos sobre infraestructura de otros y bajo la ley de otros — es un error estratégico que merece la pena deshacer. La soberanía del dato y el GDPR no son una casilla de cumplimiento en nuestra hoja de ruta: son la razón por la que varias decisiones de diseño aquí fueron por el camino difícil. Puedes ejecutar Rebase en cualquier parte del mundo y nos alegraría que lo hicieras. Pero en esto no somos neutrales.
¿Para quién es Rebase?
Para cualquiera que esté harto de elegir entre facilidad de uso y propiedad:
- El dev que quiere la velocidad de Firebase sin el lock-in de Firebase
- La startup que necesita correr hoy y escalar mañana — sin cambiarse de plataforma
- La agencia que ya no aguanta reconstruir el mismo panel admin para cada cliente
- El equipo enterprise que exige que los datos se queden en su propia infra, con trazabilidad completa
Rebase es totalmente modular. Usa el panel admin, la capa de API, el SDK o la plataforma entera. Coge lo que necesites, ignora el resto. Tú decides cuánto stack adoptas — y dónde se ejecuta: tu portátil, tus propios servidores o alojado por nosotros. Es el mismo código MIT en los tres casos, así que cambiar de uno a otro es un redeploy, no una migración.
Hecho para tres mundos
La mayoría de herramientas se diseñan para un solo público. Nosotros las construimos para tres — porque la mejor plataforma es la que funciona para todos:
Usuarios finales
Interfaces bonitas e intuitivas que la gente sin perfil técnico disfruta de verdad.
Desarrolladores
TypeScript nativo, extensible con React, con APIs y SDKs que parecen hechos a tu medida.
Agentes de IA
Servidor MCP, APIs estructuradas y esquemas legibles por máquinas — para que los agentes también construyan con Rebase.
Nuestra promesa
No creamos Rebase para venderlo ni para atraparte. Lo creamos porque llevamos toda nuestra carrera haciendo herramientas para devs, y sabemos lo que falta: una plataforma abierta, bonita, nativa de Postgres, que respete tus datos, tu tiempo y tu inteligencia.
Lanzamos rápido y lo hacemos en abierto: el changelog y el issue tracker son el registro. Rebase es joven. Lo bastante joven como para que las convicciones de arriba sigan siendo el producto entero, y lo bastante como para que un argumento tuyo pueda cambiar alguna. Es el mejor momento para aparecer.
Si algo de esto te resuena — si has sentido la misma frustración, si compartes estas ideas — ven a construir con nosotros.
El equipo de Rebase
Madrid · Construyendo herramientas open-source desde 2020
