# Falco: a functional-first ASP.NET Core toolkit written in F#

> Falco is a .NET library for building web applications in F# on top of ASP.NET Core, offering a routing API, a native F# view engine, uniform request access and security utilities. It suits F# teams who want typed request handling without giving up the standard .NET middleware stack, and its published releases stopped in 2021 even though the tree keeps moving.

**falcoframework/Falco** — A functional-first toolkit for building brilliant ASP.NET Core applications using F#.

- Repository: https://github.com/falcoframework/Falco
- Website: https://www.falcoframework.com
- Stars: 639 · Forks: 44
- Language: F#
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/falcoframework-falco

## What Falco is, and what it is not

Falco is described as a toolkit for building functional-first, full-stack web applications using F#, and the README is careful about the category. It is not a web framework that replaces ASP.NET Core. It is built on the high-performance components of ASP.NET Core and is described as integrating with existing .NET Core middleware and libraries.

That distinction matters for anyone evaluating it. You get the .NET pipeline, Kestrel, the middleware ecosystem and the NuGet universe, and Falco adds a functional layer on top: a routing API, uniform access to request data, a native F# view engine, asynchronous request handling, authentication and cross-site request forgery utilities, plus built-in support for large multipart uploads and binary responses with content disposition.

The design goals are stated as three things: provide a toolset to build a full-stack web application in F#, be simple, extensible and integrate with existing .NET libraries, and be easy to learn. That last one is a design constraint rather than a marketing line, and it explains why the public surface is small.

The name is explained at the end of the README: Kestrel was a game changer for the .NET web stack, and in the animal kingdom the kestrel is a member of the falcon genus, also known as Falco.

## The smallest possible Falco application

The README opens with the entire program, and it is worth looking at closely because it sets the expectation for everything else. A WebApplication is created, and one handler is registered:

```fsharp
open Falco
open Microsoft.AspNetCore.Builder

let wapp = WebApplication.Create()

wapp.Run(Response.ofPlainText "Hello world")
```

There is no configuration object, no dependency injection container to set up, and no host builder abstraction to learn. The handler is a value, and Response.ofPlainText turns a string into a response the framework can serve.

That shape is the point of the library. In a language where functions are values and discriminated unions are the default way to model a closed set of cases, a request handler can be a function from request to response, and a route can be a pattern match. The examples directory in the repository shows how the same idea scales: BasicRestApi, DependencyInjection, ExternalViewEngine, HelloWorld, HelloWorldMvc, Htmx, OpenApi, and a separate examples solution for them.

Two of those example names carry a lot of information. ExternalViewEngine and HelloWorldMvc exist because Falco does not force its own view engine, and htmx has a dedicated example, which tells you that the HTML-over-the-wire style of UI is a supported path rather than an afterthought.

## Routing, request data and the F# view engine

The routing API is the first of the key features and is documented separately. The important thing about Falco's routing is that handlers are ordinary functions, so a route is a function that takes a request and returns a response, and the framework composes them. There is a community extension for expressing routes as a discriminated union, inspired by Haskell's Servant, which tells you the intended shape: a route description is data that can be interpreted in more than one way.

The second feature is a uniform API for accessing any request data, which is a phrase that hides a lot of convenience. Query strings, route parameters, form posts, headers and JSON bodies are all consumed in the same style rather than through a different API per source. The documentation also points at multipart form data binding for large uploads, which is a real operational concern rather than a styling detail.

The native F# view engine is the third piece and the one with the most design opinions attached. Falco.Markup is described as an XML markup module used as the syntax for authoring HTML with Falco. Writing HTML as XML in F# gives you a typed representation of the document, and the type errors come from the compiler rather than from a template engine at render time.

The counterweight is that Falco does not insist on its own view engine, since an ExternalViewEngine example exists, and Falco.Markup is a separate package from the core. You can adopt the routing and request layer alone, which is the lower-risk way to introduce the library into an existing service.

## Response handling, binary output and security utilities

Request handling is asynchronous, and the response module is where a lot of the practical value sits. The README calls out built-in support for binary responses with content disposition, which is a small feature that saves a surprising amount of work when you are serving a file download and want the browser to save it under a particular name rather than open it.

The authentication and security utilities are the other half of the production surface. The cross-site request forgery documentation is listed as a separate topic in the key features, which is a good sign: CSRF protection is the sort of thing that gets bolted on badly, and having a documented, tested implementation in the framework reduces the chance that each endpoint invents its own approach.

There is also a pattern in the surrounding library list that describes how people actually use this. Falco.OpenApi generates OpenAPI documentation from Falco applications, which means the contract description is derived from the same routing definitions the server runs, rather than maintained separately and drifting. Falco.Htmx is a third party integration with the htmx JavaScript package. Falco.Template is a .NET SDK project template for spinning up a Falco project, and Falco.UnionRoutes is the Servant-inspired discriminated union routing. CloudSeed is offered as a scalable project boilerplate for F# and .NET.

Put together, that list describes a toolkit with a real community around it rather than a single library, and it also describes the shape of the surface area you are opting into.

## The release history is the concern in this review

The repository is not archived, and the last push was on 2026-07-27. That tells you the code is still being worked on. The published releases tell a different story: v3.1.0 on 2021-07-27, v3.0.0 on 2020-11-28 and v2.0.0 on 2020-07-12.

So there is work in the tree that has never been packaged, or the packaging moved elsewhere, and the README does not explain which. The documentation points at the CHANGELOG as the best place to find chronological updates, which is the right place to look before you pin a version, and the NuGet badge shows the published package version.

The repository layout gives a hint about how the project is built. There is a global.json pinning the SDK, which is the file to check against your target runtime, a Build.ps1 for the build script, Falco.sln for the solution, and separate src, test, docs, documentation, site, examples and assets directories. The duplication of docs and documentation is worth a look when you are hunting for the routing, request, markup, response, authentication and CSRF guides, since the README links them under the documentation/ path.

The licence is Apache License 2.0, which is the permissive choice with an explicit patent grant, and no legal interpretation is needed beyond noting that it can be embedded in a commercial product.

Contributing has stated expectations: open an issue or a discussion before a pull request, update the relevant documentation when the API changes, add or update unit tests, and pass the build checks. A project that insists on documentation and tests alongside code changes is one where the code is meant to be read.

## Where Falco is the wrong tool

The first case is a team that does not want F# in the stack at all. Falco is an F# library, and its documentation, examples and design all assume you are working in F#, so adopting it means adopting F# for at least the web layer, including its build tooling and its runtime story. For an organisation that has decided against F# for good reasons, the whole discussion is moot.

The second case is a project that needs the ASP.NET Core ecosystem rather than a layer on top of it. A large application that leans on minimal APIs, source generated OpenAPI, or the latest host abstractions will find that Falco wraps a subset of that surface, and the wrapper is where you will fight. The Falco OpenApi package shows what happens when you want a feature the base platform now has natively: you add a package and a step.

The third is the release cadence question, which is the real one. A library whose last tagged release is from 2021 is a dependency you will either pin forever, or fork, or replace. The last push date shows the code is not dead, but a published package that has not moved in five years is a real operational risk for something you depend on in production.

The alternative worth comparing is not another F# web library, it is writing the same thing directly against ASP.NET Core with F# discriminated unions for your request and response types, using minimal APIs and your own small set of helpers. You lose the F# view engine and the CSRF utilities, and you gain a dependency you can read in full and a stack that tracks the platform. For a small service, that trade is often the better one, and Falco is the better choice when the view engine and the request ergonomics are exactly what you are missing.

## Conclusion

Falco is a reasonable choice for an F# team that wants typed request handling and a native F# view engine while keeping the standard ASP.NET Core middleware and library ecosystem, and it is small enough to read in an afternoon since the public surface is a handful of modules. It is the wrong choice for a team that needs a maintained release cadence, since the last published version is v3.1.0 from 2021-07-27 even though the repository is not archived and the last push was on 2026-07-27. Before adopting it, read the CHANGELOG for what changed after v3.1, check the target framework in global.json against your runtime, and confirm the NuGet package you install is the version whose behaviour you have read in the documentation.

## FAQ

### What is Falco and what language does it target?

Falco is a toolkit for building functional-first full-stack web applications using F#. It is built on the high-performance components of ASP.NET Core and integrates with existing .NET Core middleware and libraries.

### Does Falco replace ASP.NET Core?

No. Falco is described as built on the high-performance components of ASP.NET Core and as integrating with existing .NET Core middleware and libraries, so you keep the standard .NET pipeline and add a functional layer on top.

### What are the related libraries in the Falco ecosystem?

Falco.Markup for authoring HTML with Falco, Falco.Htmx for the htmx JavaScript package, Falco.OpenApi for generating OpenAPI documentation, Falco.Template as a .NET SDK project template, and Falco.UnionRoutes for discriminated union routing inspired by Haskell's Servant.

### How recently has Falco been released?

The most recent published version is v3.1.0 from 2021-07-27, preceded by v3.0.0 in 2020 and v2.0.0 in 2020. The repository is not archived and the last push was on 2026-07-27, so the CHANGELOG is the place to see what changed after v3.1.

### What licence is Falco released under?

Falco is licensed under the Apache License 2.0, with the licence in the LICENSE file at the repository root.

## Sources

- [falcoframework/Falco on GitHub](https://github.com/falcoframework/Falco)
- [License: Apache-2.0](https://github.com/falcoframework/Falco/blob/master/LICENSE)
- [Project website](https://www.falcoframework.com)
- [README](https://github.com/falcoframework/Falco/blob/master/README.md)
- [Releases](https://github.com/falcoframework/Falco/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/falcoframework-falco