taws: a terminal UI for browsing AWS without leaving the keyboard

No AWS SDK, and that is the interesting decision

The dependency list in Cargo.toml is the first thing worth reading, because it explains the project's character. There is no aws-sdk-rust. Instead there are three small crates, aws-sigv4, aws-credential-types and aws-smithy-runtime-api, with a comment describing them as lightweight, SigV4 only, no SDK. On top of that sit reqwest for HTTP, quick-xml for the EC2, IAM and RDS query protocol, serde for serialization, and clap for argument parsing.

That choice has consequences you can feel. Requests are signed locally and sent directly, so there is no SDK to keep in step with a new service launch and no generated client to bloat compile times. The cost is that every service taws displays is a service somebody wrote a request for by hand, and the two protocols named in the dependencies, JSON and Query, are the two the AWS API surface is actually built on.

The TUI itself is ratatui 0.30 with crossterm 0.29, which is the conventional pairing. reqwest uses the rustls TLS backend rather than the system OpenSSL, with a comment explaining that this avoids cross-compilation issues, and it enables the blocking feature alongside json. Logging goes through tracing with an env-filter subscriber and a file appender, and there is a fuzzy-matcher crate for the filtering, an async-trait for the service abstractions, and arboard for clipboard access.

The project is MIT licensed, authored by Huseyin Babal, edition 2021, and its keywords are aws, tui, terminal, cloud and infrastructure.

Installing from a tap, a bucket, Cargo or a container

There are four routes in, which is more than most TUI projects offer. Homebrew is the shortest for macOS and Linux:

brew install huseyinbabal/tap/taws

Scoop covers Windows through a bucket at the author's GitHub organisation. Pre-built binaries exist for macOS on Apple Silicon and Intel, Linux x86_64 and ARM64 as musl builds that work on Alpine and Void, and Windows x86_64, with a quick install path that pipes the tarball through tar and moves the binary into /usr/local/bin.

Cargo works if you would rather compile it, and needs Rust 1.70 or newer along with a C compiler and linker. The README tabulates the platform-specific build dependencies, from the Development Tools group on Amazon Linux and RHEL, through build-essential on Ubuntu and Debian, to xcode-select on macOS and the Visual Studio Build Tools on Windows.

cargo install taws

The Dockerfile is a two-stage build that compiles on rust:latest and ships a debian:trixie-slim runtime image with ca-certificates and libssl3t64, copies the release binary to /usr/local/bin/taws and sets TERM=xterm-256color. The published image is ghcr.io/huseyinbabal/taws, and the README is clear that interactive terminal support requires the -it flags.

# Run interactively
docker run --rm -it ghcr.io/huseyinbabal/taws

For a real session you mount your credentials read-only and pick a profile or a region:

# Launch with a specific profile (mount AWS credentials)
docker run --rm -it   -v ~/.aws:/root/.aws:ro   ghcr.io/huseyinbabal/taws --profile production

The README also documents passing AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_REGION as environment variables instead, and building the image locally with docker build.

A seven-step credential chain, SSO and console login included

The authentication section is the most detailed part of the documentation, and it reads as a priority-ordered table. Environment variables come first, using AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN. Then SSO, where a profile with SSO configured triggers a browser prompt if the token has expired. Then AWS Console Login, where a profile with login_session set asks you to run aws login in another terminal. Then role assumption through role_arn with either source_profile or credential_source. Then the credentials file at ~/.aws/credentials, then the config file at ~/.aws/config, and finally IMDSv2 instance metadata for when you are running on an EC2 instance itself.

That ordering mirrors what people actually have set up. Long-lived keys first because they still work, SSO next because most teams have moved to it, then the newer console login flow, then assume-role for cross-account work, and instance metadata last so a container on EC2 just works.

Both SSO config layouts are handled: the modern sso_session reference to an sso-session section, and the legacy sso_start_url written directly in the profile. If you have already run aws sso login, the cached token is reused rather than re-prompted. Console login works the same way, with a login_session in the profile pointing at a login-session block.

[profile console-profile]
login_session = my-login-session

[login-session my-login-session]
sso_start_url = https://my-portal.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

Role assumption is called out for four situations: cross-account access such as a dev account assuming a role in prod, least-privilege access patterns, chained role assumption, and container-based deployments. Console login support arrived in v1.3.0-rc.6 in January 2026, contributed externally, which is a decent signal that the credential chain is the part of this project people push on.

What the interface actually gives you to work with

The feature list describes a browsing tool with a few write operations attached. Multiple AWS profiles and multiple regions are both switchable, which is what makes it usable across accounts without reconfiguring anything. Coverage is claimed at more than 94 resource types across more than 60 AWS services, and the repository has an assets directory with screenshots of an EC2 instances view and a Lambda functions view.

Navigation is keyboard-driven with vim-like keys, and pagination through large lists uses the ] and [ keys. Because AWS list APIs page, this is not a detail: a thousand-instance EC2 account would be unusable without it. Filtering works in two ways, local fuzzy matching for anything already loaded and server-side filtering by AWS tag for the resources that support it.

Every resource has a detailed view rendered as JSON or YAML, which is the feature that makes this credible as an engineering tool rather than a browser. Reading the raw response is often how you find out what a console is hiding from you. There is also refresh on a single keystroke, and autocomplete on resource types with fuzzy matching.

Write actions exist and are narrower than the browse surface. The README lists starting, stopping and terminating EC2 instances directly. That asymmetry is worth keeping in mind: the same IAM policy that lets you list everything is not the policy you want attached to a tool with a terminate key.

Reading the release tags as a stability signal

The versioning here deserves a plain reading. The most recent published release is v1.3.0-rc.8, on 2026-04-28, and before it v1.3.0-rc.7 and v1.3.0-rc.6, both on 2026-01-29. A project whose tags are all release candidates for version 1.3.0 is telling you the interface is still settling, even though the Cargo.toml version field matches and the tool is usable.

What the release candidates contain is also informative. v1.3.0-rc.8 added Redshift cluster and snapshot support, fixed S3 object navigation, added pagination for EC2 instance listing, and added support for reading SSM parameter values, with that last one arriving as a first contribution from an outside contributor. v1.3.0-rc.7 was a single fix to use filter_type for sub-resource filtering. v1.3.0-rc.6 added AWS Console Login.

The pattern across those entries is service coverage growing one service at a time, with the occasional structural fix underneath. Route53 recordsets got their own sub-resource route in the same release. Pagination on EC2 listing landing in the newest release suggests lists that were previously truncated are now complete, which is the kind of fix that matters quietly for a long time.

The last push was on 2026-09-27 and the repository is not archived, so work is continuing between tags. There is no homepage set in the repository metadata beyond the Cargo manifest, and the README is the documentation, so anything the README does not cover, such as configuration files or keybinding customization, is not documented in the places this project publishes.

Compared with the AWS CLI, taws gives up the enormous surface of per-service flags and the ability to script anything, and gains a browsable, keyboard-driven view of many services at once. Compared with a cloud console, it gives up documentation links and graphs and gain speed for the questions you actually ask during an incident.

Editorial conclusion

taws suits an engineer who lives in a terminal and wants to page through EC2 instances, Lambda functions or S3 objects without opening a browser tab, and who would rather inspect a JSON view of a resource than read a console table. It is a poor fit if you depend on the AWS CLI's long tail of undocumented flags, since taws signs requests and calls service APIs itself, and its most recent published tag is v1.3.0-rc.8, which signals an interface still moving. Install with cargo or the Homebrew tap, give it credentials your profile already has, and start in a read-only account: the README says at minimum you need Describe and List permissions, which is exactly the floor for browsing without risking a terminate action.

Frequently asked questions

Official sources

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