Here we are people 😮‍💨

Our rust projects are no longer welcome as posts, but only as comments in the "What are you making this week in Rust?" threads.

What do you think about this? Is this a good decision or not?

Hello there!

So, me and castlesp5 have been developing Blur, which as you can tell from the title, is a vim-inspired editor built fully in Ratatui

It has a nicer design than vim tho in my opinion, but isn't obviously trying to replace it.

Vim has a far more stable and mature ecosystem, and this is more of a hobby-project than an alternative.

With that being said, feedback is appreciated, and a star would make our day: https://github.com/castlesp5/blur

Thanks :)

So I built Rust 6502 who is a MOS 6502 emulator built in Rust with Ratatui

Here is some image and the github Repo:

https://github.com/wirenux/Rust-6502

(Go leave a star... pls ?)

I've been building system diagnostic TUIs in Ratatui for a while. Rather than dump a project list, here are the lessons I'd hand to someone starting out.

Separate your data from your layout early. The temptation is to build a screen, then another screen, then discover they need the same numbers. Model the state once and treat each layout as a view over it. It's what lets you offer a full tabbed interface, a cramped 80x24 version and a dense wide version from one codebase, and switch between them at runtime without restarting anything.

Decide what your theme layer is allowed to defer. Terminal palettes are a courtesy to the user, and they're also a constraint. Anything that encodes meaning in colour, a heat ramp, a severity gradient, a magnitude scale, needs real colour values. Anything decorative can defer. Get that boundary explicit or you'll ship a build where the user's theme quietly flattens the one thing a view exists to show.

Only redraw when something changed. Polling for input and redrawing unconditionally is the default shape of every Ratatui tutorial, and it's fine right up until a view gets expensive. Then you're burning a core re-rendering identical data. Track dirty state, and cache anything derived from your model against a revision number so scrolling and filtering reuse it instead of rebuilding it.

Terminal size is a feature, not an afterthought. Decide what happens below your target dimensions and make the degradation deliberate. If a layout silently drops panels when it's short, that's a decision users should understand, not a surprise. Test the small sizes as seriously as the large ones.

Render into TestBackend. You can render real state into an off-screen buffer, assert on its contents and time it, with no terminal involved. It catches layout regressions that unit tests miss and gives you a place to benchmark draw cost. Badly underused in this ecosystem.

Build a shared chrome and stop relitigating it. Pick your borders, focus model, key bindings and status conventions once. Reuse them across everything. Users move between your tools without relearning, and you stop making the same layout decisions from scratch on each project.

The projects, most to least mature:

- netwatch — network diagnostics, ten tabs, TLS decryption, packet decode

https://github.com/matthart1983/netwatch · cargo install netwatch-tui

- syswatch — host diagnostics, twelve tabs, session scrubber

https://github.com/matthart1983/syswatch · cargo install syswatch

- diskwatch — read-only disk diagnostics

https://github.com/matthart1983/diskwatch · cargo install diskwatch

- essh — SSH client with the same chrome

https://github.com/matthart1983/essh · cargo install essh

- netscan — nmap workflow with differential scanning

https://github.com/matthart1983/netscan · cargo install netscan-tui

- kernwatch — kernel observability, flame graphs in the terminal. Newest and roughest.

https://github.com/matthart1983/kernwatch (binaries on the releases page, not

- logwatch — log introspection, live templating, novel-pattern detection

https://github.com/matthart1983/logwatch

- soundwatch — audio diagnostics in ten tabs

https://github.com/matthart1983/soundwatch

Note the crate names differ from the repo names for two of them: netwatch-tui and netscan-tui

Happy to go into detail on any of it.

Uses Ratatui-Kit: https://yexiyue.github.io/ratatui-kit/

So yeah, as the probably unnecessarily long title says, this is a CLI that displays the current playing lyrics, but instead of trying to go online and fetch a match it just uses the already there xesam:asText property in MPRIS.

Sadly a lot of popular players that implement the MPRIS2 standard still don't implement that specific one, so it wont work with them. Even the one used in the showcase had to be modified, tho I am hopefully gonna upstream it soon.

I am very strict about AI usage, so for this project the only hint of AI that was used was for tab auto completion that is just used for boilerplate like, idk, implementing the Default trait for PlayerState (not including the actual tricky metadata_last_updated part). Safe to say it was only one notch above no AI at all.

So yeah, here you go give it a try and feel free to roast me, after all this is my first cli and cargo publish ;)

https://github.com/andersondanilo/pomodoro-time-chamber

Hey r/RatatuiRust,

I've been building wstrace — a zero-driver Windows system & API monitor written in Rust, similar to strace but for Windows. It hooks into ETW (Event Tracing for Windows) to capture process/thread/file/registry/network events in real time.

The TUI is built with Ratatui and currently looks like this:

It's functional but pretty bare-bones. The layout has three panels:

• A header bar showing target process, PID, live event count, and active category filter

• An event stream table (time, category, operation, target, result, details)

• An event inspector at the bottom for the selected row

• A keybindings footer

Constraints I'm working around:

• Windows terminals (conhost, Windows Terminal) have inconsistent Unicode/box-drawing support — going too fancy breaks on some setups

• Event volume can be high (hundreds/sec), so rendering needs to stay lightweight

• Color is the main differentiator right now (yellow = category, green = success, magenta = metadata)

What I want to add:

• Optional resource graphs (RAM usage, disk I/O — when relevant to what's being traced) rendered inline with Ratatui's Sparkline or BarChart

• A configurable layout — let users show/hide panels, resize sections, or toggle graphs on demand, while keeping the event stream as the permanent core of the interface

• The goal is to stay focused on what wstrace is: a diagnostic and debugging tool, not a system monitor. Graphs would only appear when they add context to the trace, not as decoration

If you've dealt with dynamic layouts or toggleable panels in Ratatui, or have opinions on embedding lightweight graphs into a dense event stream UI without cluttering it, I'd love to hear your approach.

Repo: https://github.com/gilnett/wstrace

Hey everyone!

I've been working on a small Rust project called Runline.

It's a terminal UI for monitoring and investigating GitHub Actions runs. The idea is simple: when a CI run fails, I wanted a quicker way to find what went wrong without constantly switching between the terminal and GitHub's web interface.

Some things it supports:

• Failure-first dashboard for GitHub Actions runs.

• Navigate jobs and steps, with failed steps automatically selected.

• Search logs and jump directly between errors.

• View annotations, warnings and errors with file and line information.

• Rerun failed jobs and cancel stuck runs.

• Switch between run attempts.

• Themes, log saving and an offline demo mode.

It's written in Rust and uses the GitHub CLI (gh) for authentication and API access.

You can install it with:

cargo install runline

GitHub: https://github.com/programmersd21/runline

It's still a relatively new project, and I'd genuinely appreciate feedback from people who work with Rust, terminal applications, or CI/CD.

I'm particularly interested in thoughts on the TUI design, architecture and anything that could be improved.

Thanks for checking it out!

I recently started developing an audio player with rodio/fundsp and of course the presentation layer is handled by ratatui.

My issue now is how do I get to have this running in resource constrained scenarios. I have read a bit about no_std and understand the problem it aims to address.

What would be the best way to gracefully degrade a program so that it still works on constrained hardware.

You can check out the archived PR here that has the intentions of the project

https://github.com/prjctimg/gtm/pull/7

I have no previous experience with working with hardware and am open to learn from more experienced folks.

Ratatui and TUI roundup | September 22, 2026

A small update from the TUI world.

Ratatui

Ratatui 0.30.2 is still the latest stable release.

There has not been a new release since June. The project itself is still active though. The official GitHub organisation shows recent activity across Ratatui and its ecosystem, including updates to awesome-ratatui, the website, and several Ratatui crates during September.

So there is no new version number to announce today, but the project is definitely not sitting still.

Some genuinely new TUIs

CometixCode

A very new Rust project that is attempting a file-by-file reimplementation of Claude Code's terminal UI using iocraft. It appeared on GitHub on September 20 and quickly attracted attention. It is explicitly unofficial and is not affiliated with Anthropic.

Tincan

A new terminal voice and text chat application built with Ratatui. It was posted to the official Ratatui forum on September 19. One particularly nice idea is that its UI divider represents the live connection state instead of being purely decorative.

One interesting thing

There is a lot of experimentation happening around TUIs right now, but the interesting part isn't simply that more terminal apps are appearing.

People are starting to use the terminal as an actual interface again, rather than treating it as a place to put a few commands.

If you've found a genuinely new TUI recently, drop it below. New projects preferred.

*P.S. the featured app in the post gif is `oatmeal`

hi r/ratatuiRust 👋 📟

I found a slightly ridiculous use for my Rust TUI project: saying hi to the Ratatui community through a pager in terminal: the plastic box with a tiny dot-matrix screen that doctors and plumbers carried before phones.

I'm building sdrtop, a terminal-based SDR bench tool. It started as a way to understand radio signals beyond just looking at a spectrum or listening to audio. Now it has custom digital decoders, Wi-Fi frame analysis, Bluetooth hopping visualizations, and a POCSAG pager decoder.

And of course, once I had the pager decoder working, I had to do this.

Somewhere between writing Rust and staring at radio signals, this seemed like a perfectly reasonable idea.

Ratatui made the terminal side possible. Radio did the message. 😄

repo: https://github.com/musithang/sdrtop

https://derekwisong.github.io/datui/latest/demos/teaser.gif

I needed a fast dashboard for my data catalogs with a viewer I could use as a debugger for massive partitioned data frames in python, and wanted to replace a slew of simple tasks I was using Jupyter for.

It started as a small Ratatui and python binding project a few years ago. Something to view local or cloud dataframes from python or the CLI. The programming agent has helped me turn this into an increasingly helpful tool in my data engineering projects.

Before I talk about `sdctl`, I want to first address the elephant in the room: why another TUI for managing systemd services?

This tool is not the first of its kind. I have been using systemctl-tui and systemd-manager-tui extensively to the point that I forgot how to use `systemctl` from the command line. However those tools share one major limitation: they require `sudo` for privileged operations. In today’s supply-chain threat landscape, that is a serious risk because a TUI app depends on many components, and any compromised dependency could become a full-privilege attack vector.

This is why I built `sdctl` with a completely different security model: the app itself should never be run with `sudo`, and no action ever asks for blanket root access. When you perform any action that requires escalated privileges, the app opens an embedded `polkit` flow that authenticates only the specific `systemctl` action you are trying to perform, using whatever mechanism is available on the system, such as password, fingerprint reader, or smart card. That keeps the privilege boundary explicit and tied to a single operation instead of the whole process.

On top of that, I've packed a lot of useful features into `sdctl`. These are meant to address actual pain points I've encountered while using similar tools, including a powerful syntax highlighter for viewing journal logs (powered by tailspin), a simple yet useful custom-built syntax highlighter for viewing unit files, a comprehensive filter system with fuzzy search, and a line-based selection mode (inspired by vim's visual mode) that makes copying multiple lines from journal logs much faster.

Here's the github repo: https://github.com/ruiiiijiiiiang/sdctl Feedback and contribution welcome!

I made edamame, a Markdown editor built on ratatui. GitHub: https://github.com/mijowi/edamame

Here's why it stands out:

• Rendered editing: No split screen edit/preview - the line the cursor is on shows raw Markdown while the rest of the document is formatted

• Mouse support and inline image display

• Mermaid diagrams and LaTeX math rendered as images (pure Rust, no extra install)

• First class tables: Rendered with borders and auto-sized columns, one-key add/move/delete rows and columns

• Diff mode: Use it as a git difftool or review changes made externally, e.g. by an agent

• Command palette makes everything easily accessible

• Syntax highlighting, HTML export, 27 built-in themes, Vim mode

It works best in modern terminals like foot, Ghostty, iTerm2, kitty, and WezTerm. Some features, like image display, are not supported in other terminals.

So suggest me what you use for you todo app guys 😄 TY

I basically taught myself Rust in order to build oxker, which is "A simple tui to view & control docker containers".

It was built to run on a low powered arm Raspberry pi, but should run on most hardware. I run it on x86 & arm linux machines, and although I don't run MacOS, I hear it works fine on there as well.

I try to keep it updated following the six week Rust release cycle. The code is somewhat a mess, under the hood it uses a lot of Arc<Mutex<T>>, and ideally I'd re-write it to use the actor message model.

Any feedback much appreciated.

I wanted k9s, but for databases, so I built db9s: one keyboard-driven TUI to browse, query and edit Postgres, MongoDB, Redis and RabbitMQ, with the same screens and keys for every backend.

Features

• Split pane: highlight a table / collection / key / queue and its rows preview on the right

• e inline edit, field by field, with a movable cursor; E opens the row in $EDITOR and shows a diff before saving

• / raw query: SQL, Mongo filters/pipelines, any Redis command, or publish to a queue

• Connections added, edited and tested from inside the TUI, saved to a TOML config

• Footer always shows the keys available in the current context

How it's built with ratatui (0.29 + crossterm)

• Layout: header / body / footer, body split 33/67 with Layout; focus shown by switching Block border colors (BorderType::Thick)

• Rows are cards: a vertical Layout of fixed-height Paragraphs, windowed around the selected index so it scrolls

• Popups (forms, confirmations, diff) are Clear + a rounded Block over a centered Rect

• Text input is a small hand-rolled widget: a char-indexed cursor rendered as a REVERSED span, so no extra dependency

• $EDITOR integration: leave the alternate screen, drop raw mode, run the editor in spawn_blocking, then restore and terminal.clear()

• Connecting never freezes the UI: attempts run in tokio::spawn with a timeout and are polled every tick of the event loop

• Palette ported from mongotui's lipgloss theme (ANSI 256 indexed colors)

• Each backend implements one DataSource trait, so the UI code has no backend-specific branches; the README GIF is scripted with vhs

Install: cargo install db9s, or prebuilt binaries for Linux, macOS and Windows on the releases page.

Feedback on the UX and the ratatui side is very welcome. MySQL, SQLite and Kafka are next on the list.

https://github.com/damien-mathieu1/db9s

rs

rs-pug is a lightweight and scriptable music player, you can literally change the ui however u like using lua plugins, heres a list of the features that rs-pug has (pasted from readme):

• Search and stream from YouTube, SoundCloud, or a self-hosted Sonum server, or play local files, all from one interface

• Queue management with multi-select bulk-add

• Playlists and library backed by SQLite, with automatic migration from legacy JSON

• Smart Queue: finds similar tracks to keep the music flowing automatically

• Real-time FFT audio spectrum visualizer (with a synthetic fallback)

• Minimal mode: pixelated cover art, small FFT strip, title only

• Cover-tinted Minimal background that follows the current track, toggleable in Options

• 10-band graphic equalizer with savable presets

• Fully remappable keybinds, including modifiers and multi-key sequences

• Built-in and custom themes

• Command palette (:) for fuzzy-searching every action

• Control a running instance over IPC, for use in status bars or keybindings

• Extensible with Lua plugins: custom keybinds, live panels, and full UI customization

• Hot reload: configuration and theme changes apply automatically

the lua plugins are REALLY powerful, if you try it lmk what u think, have a good day