What is In Falcone?
Not production-ready
In Falcone is in early, active development — APIs, schemas and behavior may change without notice, there are no stability/security/support guarantees, and it has not had a security audit. Use it for evaluation and development only, never for production workloads or sensitive data. See the Roadmap.
In Falcone (codename Falcone) is a multi-tenant Backend-as-a-Service (BaaS). It gives application teams the building blocks they would otherwise assemble by hand — databases, object storage, an event bus, serverless functions, authentication and realtime subscriptions — behind a single API gateway, with tenant isolation enforced at every layer.
A single platform instance hosts many tenants. Each tenant owns one or more workspaces (the unit a project's data lives in), and every read and write is scoped to the calling tenant. The cardinal rule of the platform is that no tenant can ever observe or mutate another tenant's data — this is enforced in the database (PostgreSQL Row-Level Security), in the data adapters (injected tenant predicates), and in the realtime pipeline (tenant-scoped change matching).
What you can do with it
| Capability | What it gives you | Backed by |
|---|---|---|
| Relational data API | REST CRUD + query + DDL over SQL tables, with keyset pagination and filtering | PostgreSQL |
| Document data API | REST CRUD + query over collections, with cursor pagination | MongoDB |
| Object storage | S3-compatible buckets and objects | MinIO |
| Events | Publish/subscribe to a tenant-scoped event stream | Kafka / Redpanda |
| Serverless functions | Deploy and invoke per-tenant functions | Knative / OpenWhisk runtime |
| Realtime | Subscribe to live data changes over Server-Sent Events | Mongo change streams + Postgres CDC |
| Identity & access | Users, roles, service accounts, JWTs and API keys per tenant | Keycloak (OIDC) |
| Tenant administration | Provision tenants/workspaces, members, plans, quotas | Control plane |
| Observability & quotas | Per-tenant usage, metrics, audit and hard limits | Prometheus + control plane |
These map to the platform's public HTTP surface, split into two privilege domains:
structural_admin— tenant/workspace lifecycle, schemas, functions deployment, API keys, service configuration and quotas.data_access— the day-to-day data plane: documents, queries, objects, function invocation, analytics, event publish/subscribe.
See the API Reference for the full route catalog.
Built for AI: a BaAIS
In Falcone starts from the same foundation as any backend platform — multi-tenant data, auth, storage, events and functions behind one API — and points it at how software is increasingly built and operated: by, and for, AI agents.
We call this category a BaAIS — a Backend-as-an-AI-Service, a play on "BaaS" for an AI-native world. (The expansion is deliberately loose; what matters is the direction, not the acronym.) Concretely, it means a tenant's backend is designed to be natively consumable by agents, not only by application code:
- MCP server hosting (Preview) — expose a tenant's backend (data, storage, functions) as a Model Context Protocol server, so any MCP-capable agent can discover and call it under that tenant's own isolation, auth and quotas. The management API is served live under
/v1/mcp; Instant MCP and the official server work end-to-end. See the MCP guide. - Agentic workflows (Preview) — the Temporal-based Flows engine runs durable, multi-step workflows with a first-party activity catalog whose credentials are tenant-scoped — the reliable substrate an agent needs to act across services.
Everything an agent touches stays inside the same tenant-isolation contract as the rest of the platform: scoped by tenant and workspace, gated by plan capabilities, and audited. See the Roadmap for what's in flight.
A guided tour of a real deployment
The following screenshots are taken from a live cluster running the full stack (gateway, control plane, executor, console, Keycloak, PostgreSQL, MongoDB, Kafka, MinIO).
Sign in
The console authenticates against Keycloak (OIDC). Operators and developers land on the platform with a tenant context.
Tenants & workspace context
Tenants are the top-level isolation boundary. Selecting a tenant sets the context that scopes everything you do next.
Identity, members & service accounts
Each tenant manages its own users, roles and machine identities. Service accounts mint credentials used by applications and CI.
Databases — PostgreSQL & MongoDB
The console exposes both data engines. You can browse schemas and tables in PostgreSQL and collections/documents in MongoDB — all scoped to the active tenant.
Object storage
S3-compatible buckets and objects, per tenant.
Events
A tenant-scoped event bus with topics.
Serverless functions
Deploy functions and invoke them from the console.
Plans, quotas & observability
Plans define entitlements; quotas enforce per-tenant limits; observability surfaces usage and operations.
How it fits together (in one paragraph)
A request enters through the APISIX gateway, which classifies it by credential (an apikey header for anon/service keys, or a Bearer JWT) and routes it to the right backend. Structural-admin calls reach the control plane; data-plane calls reach the executor, which runs adapter-built query plans against the real PostgreSQL / MongoDB / Kafka / MinIO backends. The executor resolves identity (API key is authoritative, then verified JWT, then gateway-injected headers) and stamps and filters by the tenant on every operation. Realtime rides the same identity model over SSE. The whole thing is packaged as one umbrella Helm chart you can target at Kubernetes, OpenShift or an air-gapped registry.
Continue to the Architecture overview for the detailed design, or jump to the Quickstart to build a TODO app.