Home

Birko Framework

A modular .NET framework for building applications that need to store data, talk to things, and run work in the background — without rewriting that plumbing for every project and every backend.

It is 178 shared projects in one repository. You pick the pieces you need, and the same code works whether your data lives in SQLite, PostgreSQL, MongoDB, ElasticSearch or a JSON file.

New here? Go to Getting Started. It has you running CRUD against a real database in about ten minutes.

---

What it gives you

You want to…	Birko gives you	Page
Save and query objects	One store API over 13 storage backends	Data and Stores
Use a real SQL database	Attribute-mapped models, 5 providers, migrations	SQL Databases
Call or serve APIs	REST, gRPC, GraphQL, SOAP, WebSocket, SSE, MQTT	Communication
Talk to an LLM	One interface over Claude, OpenAI, Gemini, Ollama, Azure	AI and LLM
Run jobs / state machines	Background job queues and a workflow engine	Workflow and Background Jobs
Log people in	JWT, OAuth, BCrypt, Vault, Key Vault	Security
Build a web UI	Web Components, no framework, no build magic	Web UI · live gallery
Build a desktop app	Avalonia-based XAML shell	Desktop XAML

Nothing to install to look around: the component gallery runs the whole b-* library in your browser, with a live design-token editor and a theme export.

The one idea worth understanding first

Birko is built on shared projects (.projitems), not NuGet packages. That means your project compiles Birko's source together with your own — there are no binary dependencies, and you can step into framework code in the debugger.

The practical consequence, which trips everyone up once:

⚠️ A project pulls in more than you asked for. The graph is dense — asking for SQLite stores also needs models, view-models, patterns, rules and helpers, because they reference each other's types directly. You do not import 178 projects to get one, but you rarely import just one either.

Two working references are in the repo, and they bracket the range:

	Imports	What it is
Birko.Sandbox	38 of 178	A console app touching stores, SQL, migrations, caching, workflow, jobs, health, REST, GraphQL and security
Birko.Sandbox/Birko.Framework	163 of 178	The compile gate — imports nearly everything, on purpose, to prove the whole framework builds

Copy the Sandbox's list and delete what you do not use, adding back whatever the compiler then asks for. Building the list up from nothing means discovering the graph one error at a time.

Getting Started shows exactly how, with a file you can copy.

How the pieces relate

Birko.Contracts            zero dependencies — the interfaces everything else agrees on
  └─ Birko.Configuration   settings: where a thing lives, how to connect to it
      └─ Birko.Data.Core   models, filters, exceptions
          └─ Birko.Data.Stores       the store contracts (CRUD)
              └─ Birko.Data.SQL      + one project per provider
              └─ Birko.Data.MongoDB
              └─ Birko.Data.JSON     … and ten more

Everything else — communication, AI, workflow, security — sits beside this, not on top of it. You can use Birko's REST client without using its stores, and vice versa.

Where things are

• Code: Birko-Framework/Birko.Framework — projects at the repo root, tests under tests/
• Frontend libraries: Birko-Framework/Birko.Web
• Runnable example: Birko-Framework/Birko.Sandbox — a smoke harness that wires up one slice of each layer and prints OK/FAIL. Small, real, and it runs.

A note on this wiki

Every code sample here was compiled and executed against the current framework while the page was written, not copied from older documentation. Where something differs from a README.md or a project's CLAUDE.md in the repository, trust this — several of those are demonstrably out of date, and the Getting Started page says which.