Consolonia renders Avalonia UI inside a terminal, and it is in beta

Avalonia's rendering ideas, aimed at a terminal

The framing sentence in the README is that Consolonia injects the benefits of the Avalonia UI framework directly into TUI applications, which is a precise description of what the project is. Avalonia is a cross-platform UI framework for .NET, and its ideas are the ones a console UI cannot easily reproduce: a layout system with panels and alignment, a styling engine with reusable resources, templated controls, and data binding to properties, collections and commands. Consolonia does not invent a console widget kit. It reuses the Avalonia architecture and swaps the rendering target for a console-optimised pipeline, so the developer writes the same declarative UI definitions they would write for a desktop app. That reuse is the whole proposition, and it is also the boundary. If you do not already know Avalonia, the learning curve the comparison table promises to remove for Avalonia developers moves to a different place rather than disappearing.

The template path, from template install to running app

The quick start is three commands, and the first one installs a template package rather than a library:

dotnet new install Consolonia.Templates

You then create a project from that template:

dotnet new consolonia.app

and the generated project compiles and runs like any other .NET project:

cd MyConsoloniaApp
dotnet run

The template approach is worth pausing on, because it says something about the maturity of the project. A framework that is still being shaped is easier to consume as a starting point than as a set of packages you assemble, and a template carries the right project references and start-up wiring for you. The repository structure supports the same idea, with a Consolonia.Controls project at the top level alongside src/ and a set of shared build property files, Directory.Build.props, Directory.Core.Build.props and Directory.Tools.Build.Props, which is the standard layout for a repository that produces several packages from one build. The README also points to a QuickStart page in the wiki for anyone who wants more than the three commands.

What the comparison with traditional TUIs actually claims

The README sets out a feature comparison in a table, and reading it row by row is more useful than the summary. On layout and positioning, traditional TUIs use manual coordinates or a simple grid that breaks when the terminal is resized, while Consolonia claims Avalonia's flexible layout system with responsive panels and alignment. On styling and theming, the contrast is between limited palettes and hard-coded styles versus a styling engine with full colour schemes, gradients and reusable style resources. The control set claim is that a traditional TUI gives you basic text input, a list and a menu, while Consolonia provides a unified library modelled on Avalonia's elements, including buttons, sliders, tree views and tab controls. The data binding row is the largest difference, from rarely supported and requiring manual refresh logic to the full Avalonia binding system. Event handling is described as replacing ad-hoc input loops and blocking or OS-specific quirks with an async-friendly system using the same patterns as Avalonia GUI apps, and templating claims control templates that let visual structure change without touching logic. Cross-platform behaviour is where Avalonia's abstraction layer does the work, giving the same look on Windows, macOS and Linux.

The gallery is a global .NET tool

Before you commit to writing a screen, the project offers a way to look at what it can draw. The Consolonia.Gallery tool is installed from NuGet as a global tool, with a prerelease flag because the framework is in beta:

dotnet tool install -g Consolonia.Gallery --prerelease

The gallery then runs as a command:

Consolonia.Gallery

and is removed with the matching uninstall:

dotnet tool uninstall -g Consolonia.Gallery

This is the right first step for an evaluation, because the difference between a traditional TUI and an Avalonia-rendered console UI is almost entirely visual and is not something a feature list can convey. The README carries a gallery image showing the framework in action, and the framing of the beta invitation is explicit, with the project asking for developers to try it and help refine it. That is a genuine upside if you want influence, and a genuine risk if you want a stable API, since a beta framework in .NET commonly renames things between previews.

Where the documentation actually lives

The README is short, and it says where the rest is. Documentation lives in the wiki, and the link points to the Consolonia wiki hosted under the jinek account, which reflects the project's origin as a personal project that has since moved to the Consolonia organisation as the repository home. The QuickStart page is linked from the install section, and the wiki is linked again at the end of the readme. For a framework at beta stage this is a reasonable arrangement, since a wiki is faster to update than generated API documentation, but it also means the reference material sits outside version control and outside the package. The repository itself carries contributing.md, an .editorconfig, a LICENSE file, an Icon.ico and Icon.png, and a .github/ directory for workflows, and it includes a .env file at the root, which is an unusual artefact to find in a public repository and one worth a glance before you trust the build.

MIT terms and a fast patch release rhythm

The licence is MIT, with the LICENSE file at the top of the repository, so the code can be used, modified and redistributed in commercial products with only attribution required. That permissiveness matters more than usual for a UI framework, because teams often want to look at the source of a rendering layer they are embedding in a shipped tool. The release history shows a project moving quickly within one line. The tagged versions are v12.0.3.11 on 2026-08-11, v12.0.3.12 on 2026-08-25 and v12.0.3.14 on 2026-10-01, and the last push to the repository was on 2026-10-20, with the repository not archived. The version numbering is worth noting. It encodes the.NET major version, the Avalonia version it targets and a patch counter, so upgrading your.NET or Avalonia dependency is visible in the package version rather than hidden in a dependency graph. The package is published to NuGet, and the beta status means prerelease packages and prerelease flags are part of normal usage rather than an edge case.

Editorial conclusion

Consolonia suits a .NET team that already knows Avalonia and wants a terminal front end for a tool that also has a desktop version, or that needs a richer console UI than hand placed text can give. It is a poor fit for a team without Avalonia experience, since the value is precisely the reuse of Avalonia concepts, and for a production console tool that cannot tolerate beta API churn. Verify first which Avalonia version your build pulls, try the Consolonia.Gallery tool to see the control set before writing a screen, and read the wiki, since the README covers the quick start and the comparison table but leaves the details there.

Frequently asked questions

Official sources

1. Consolonia/Consolonia on GitHub
2. Issues
3. License: MIT
4. README
5. Releases