top | item 46491749

Show HN: Terminal UI for AWS

390 points| huseyinbabal | 1 month ago |github.com

210 comments

order

kristiandupont|1 month ago

Only tangentially related, but: what is the appeal of TUI's? I don't really understand.

The advantages of CLI's are (IMO) that they compose well and can be used in scripts. With TUI's, it seems that you just get a very low fidelity version of a browser UI?

chazhaz|1 month ago

The advantage of TUIs is that you get a low-fidelity browser UI that doesn’t need to be exposed to the internet, that can be run remotely via SSH, which doesn’t ship you megabytes of JavaScript, and which works equally well on everyone’s machine

MrGilbert|1 month ago

They are usually faster to create and pretty much cross-platform. They should also work great with screen readers, though that is only an assumption.

TUI also means that I do not have to memorize an infinite amount of command line parameters.

I really like well-made TUIs.

rgoulter|1 month ago

Practically? The best keyboard-driven programs are (incidentally) TUIs.

For some reason, expressive keyboard-driven interfaces aren't as popular in GUI interfaces.

lucideer|1 month ago

Apart from the apparent comparative ease of creation relative to GUIs (I suspect Electron apps may be easier than TUIs), I think the main benefits from a user perspective seems to be down to cultural factors & convention:

- TUIs tend to be faster & easier to use for cli users than GUI apps: you get the discoverability of GUI without the bloated extras you don't need, the mouse-heavy interaction patterns & the latency.

- keybindings are consistent & predictable across apps: once you know one you're comfortable everywhere. GUI apps are highly inconsistent here if they even have keybindings

- the more limited widget options brings more consistency - GUI widgets can be all sorts of unpredictable exotic

- anecdotally they just seem higher quality

Cthulhu_|1 month ago

Before Windows / GUIs, everything was a TUI. Some of those applications were kept around for a long time even when Windows was mainstream, because they were faster. If you've ever seen an employee (or co-worker) work in one of those applications you'll see it. They can zip through screens much quicker than someone doing point and click work.

victorbjorklund|1 month ago

Faster and easier to use. I love for example Lazygit. It’s the fastest way to use git (other than directly as a cli of course but if you want some graphical info lazygit is great)

oneeyedpigeon|1 month ago

You get a low-fidelity version of a browser UI with guaranteed keyboard support. If web apps had the same level of keyboard support, TUIs would be less appealing.

mystifyingpoi|1 month ago

Look up k9s, it's a great example. But as sibling comments say, it's all keyboard driven and most actions are single keypresses.

ashu1461|1 month ago

I had the same doubt. With CLIs you can make your own custom shortcuts, LLMs can use it to get things done for you as well. With TUIs I think either these are hobby projects or meant for people who are obsessed with speed.

Though speed impacts are also something which I am uncertain about. Comparing Vim with IDEs, for sure there will be few things which are faster in vim but decent no of things which can be done faster in an IDE as well, so can't comment on your overall speed gains.

wtetzner|1 month ago

For one thing, you don't need to run them in a browser.

thiht|1 month ago

I recently started using k9s after using kubectl for a while. It's just faster and more convenient. A well made TUI also offers a bit more discoverability than a CLI. If you know exactly what you're looking for the CLI is fine, but if you need to explore a little bit, a TUI is better.

freeplay|1 month ago

Memorizing CLI commands and typing/editing them over and over can be very time consuming.

Use k9s for example. Let's say you want to determine where the value of an environment variable is coming from.

1. 'kubectl get deploy -n example' (find the name of the deployment in question)

2. 'kubectl describe deploy example-app -n example' (determine where the value for the env var is coming from)

3. 'kubectl get cm example-app-config -n example -o yaml' (check the value of the referenced key in the config map)

This is a very basic example but you can see where it lead to slow debugging that is made even slower by its propensity to typos and the need to look up command syntax. Once you get comfy in a well designed TUI, you can fly through this process in 10 seconds.

jama211|1 month ago

The appeal is I can use it with just a terminal connection to the server

d4rkp4ttern|1 month ago

TUIs can be self explanatory if designed well. Ideally the same tool would have a CLI mode with JSON(L) formatted output, launched with a flag like —json so that it can be composed (unix-like) with other CLI commands, and also usable by LLM-agents, with jq etc. This is what I do in a TUI/CLI tool I’ve been building

whatever1|1 month ago

The only real advantage is that you have access to a UI—ish everywhere, because the ssh server is running everywhere by default (at least at machines you would want to connect to).

Http servers are not installed by default, and they are a pita to configure / secure.

rockwotj|1 month ago

you also get a very slimmed down interface that is usually way faster to load. one of the reasons I love HN is that it is super snappy to load and isn’t riddled with dependencies that take forever to load and display. Snappy UIs are always a breath of fresh air.

chilli_axe|1 month ago

In addition to what other commenters said - TUIs can be installed on a server and used over SSH

benterix|1 month ago

Many tools offer both CLI and TUI interface. TUI is especially useful at scale, when you need to deal with a large amount of resources efficiently or have a good overview of the whole environmtnt faster - e.g. *top, k9s, Midningt Commander etc.

perrygeo|1 month ago

> low fidelity version of a browser UI?

That's the point. For me, with very few exceptions, modern web UI is steaming pile of dogshit - no consideration for user's attention, speed, or usability. TUI are extremely low fidelity; there's nowhere to hide all that enshitified cruft! Stripping the functionality down to its bare essence vs navigating a bespoke web UI with the design aesthetic of clown vomit. I can tell you which one is more productive for me.

nobleach|1 month ago

I can give an anecdote if that's helpful. Imagine you're wanting to download an object from S3. You start to type out the command in your CLI. You hit enter, only to realize, see that the object is not found. You have a typo somewhere... but where? The bucket is huge so, you resort to listing the contents and passing the results through grep. Then you copy the object to the clipboard so that you can edit your original command.

I see one of the other comments mentions K9s. The exact same use cases manifest with that tool. YES, if it's just a one-shot, nothing beats the CLI. Many things where you need to investigate the resources a bit more, lend themselves to a TUI (or GUI if that's your thing).

I come from an era where folks could fly through tasks on dumb terminals. (AS/400 apps). The moment we gave them "better" gui tools, they slowed way down. No matter how many times we told them, "you can still use your TAB and ENTER keys!" TUIs were just a sweet spot.

korse|1 month ago

Sometimes a gui is helpful for things (such as monitoring) but you don't want to leave your terminal because it screws with your workflow.

israrkhan|1 month ago

I was skeptical too, but after trying lazygit, lazydocker, k9s and a few more TUI programs, I can see the value.

tianqi|1 month ago

I couldn't get this to run successfully.

More broadly, I have concerns about introducing a middleware layer over AWS infrastructure. A misinterpreted command or bug could lead to serious consequences. The risk feels different from something like k9s, since AWS resources frequently include stateful databases, production workloads, and infrastructure that's far more difficult to restore.

I appreciate the effort that went into this project and can see the appeal of a better CLI experience. But personally, I'd be hesitant to use this even for read-only operations. The direct AWS cli/console at least eliminates a potential failure point.

Curious if others have thoughts on the risk/benefit tradeoff here.

falkensmaize|1 month ago

This was my first thought too. We already have terraform for repeatable, source controlled service provisioning and we have the relatively straightforward aws cli for ad hoc management. I don’t know that I really need another layer, and it feels quite risky.

3uler|1 month ago

The read-only hesitation seems overcautious. If you’re genuinely using it read-only, what’s the failure mode? The tool crashes or returns bad data - same risks as the AWS CLI or console.

The “middleware layer” concern doesn’t hold up. This is just a better interface for exploring AWS resources, same as k9s is for Kubernetes. If you trust k9s (which clearly works, given how widely it’s used), the same logic applies here.

If you’re enforcing infrastructure changes through IaC, having a visual way to explore your AWS resources makes sense. The AWS console is clunky for this.

zmmmmm|1 month ago

I guess it's the kind of thing where you want an almost Terraform like "plan" that it prints out before it does anything, and then a very literal execution engine that is incapable of doing anything that isn't in the plan.

pgroves|1 month ago

All the use cases that popped into my head when I saw this were around how nice it would be to be able to quickly see what was really happening without trying to flop between logs and the AWS console. That's really how I use k9s and wouldn't be able to stand k8s without it. I almost never make any changes from inside k9s. But yeah... I could see using this with a role that only has Read permissions on everything.

zeroimpl|1 month ago

The AWS APIs are quite stable and usually do exactly one thing. It’s hard to really see much risk. The worst case seems to be that the API returns a new enum value and the code misinterprets it rather than showing an error message.

nfRfqX5n|1 month ago

With properly scoped roles I would not be concerned

kylehotchkiss|1 month ago

Should have a Price Of Current Changes menu bar item! So you can see if your changes cost $.01 or $10,001.

bdbz|1 month ago

If only Amazon made it so simple

lherron|1 month ago

Somehow every 15 line shell script I write now turns into a 50kloc bun cli or tui app. Apparently there are many such cases.

viraptor|1 month ago

Different use cases. I want aws-cli for scripting, repeated cases, and embedding those executions for very specific results. I want this for exploration and ad-hoc reviews.

Nobody is taking away the cli tool and you don't have to use this. There's no "turns into" here.

latchkey|1 month ago

I run a neocloud and our entire UX is TUI-based, somewhat like this but obviously simpler. The customer feedback has been extremely positive, and it's great to see projects like this.

ssh admin.hotaisle.app

Imustaskforhelp|1 month ago

Oh this looks really interesting as well.

Can you tell me more about what do you mean by Neocloud and where are you exactly hosting the servers (do you colocate or do you resell dedicated servers or do you use the major cloud providers)

this is my first time hearing the term neocloud, seems like its focused on AI but I am gonna be honest that is a con in my book and not a pro (I like hetzner and compute oriented compute cloud providers)

Share to me more about neoclouds please and tell me more about it and if perhaps it could be expanded beyond the AI use case which is what I am seeing when I searched the term neocloud

alberth|1 month ago

Embarrassingly dumb question: if you’re one of the few users who don’t run a dark background terminal … how well do these TUI render (in a light background)?

deepspace|1 month ago

Not a dumb question at all. I grew up using actual green screen terminals, and the advent of high-resolution colour monitors and applications with dark text on a white background felt like a blessing. I truly do not understand the regression to dark mode. It's eyestrain hell for me.

Unfortunately, I was unable to test in my light-background terminal, since the application crashes on startup.

oneeyedpigeon|1 month ago

My personal experience is mixed. Half the time, I get something usable, the other half I get something that prints light yellow on slightly-darker yellow or highlights an item with a dark blue background and dark green text. I'm sure there's something I can tweak in my terminal app to fix this, but it's easier to just avoid those apps.

sylens|1 month ago

Looks great! If you have multiple AWS accounts in your org, you probably want to use something like aws-sso-util to populate your profiles so you can quickly swap between them

ronbenton|1 month ago

I thought the title meant the AWS UI was “terminal”, which I would be on board with

mrichman|1 month ago

Crashes on first use. Not a good way to go viral.

huseyinbabal|1 month ago

There was a resource handling problem, but it is fixed in 1.0.1 that you can try

bcb_1000|1 month ago

[deleted]

shushpanchik|1 month ago

> // TODO: Handle credential_source, role_arn, source_profile, sso_*, etc.

So it does not support any meaningful multi-account login (SSO, org role assumption, etc), and requires AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY. That's a no-no from security POV for anything in production, so not sure what's the meaningful way to use that.

huseyinbabal|1 month ago

I also care security part, but this is just beginning :) New features will be added iteratively based on community requests, and it seems there are plenty of good requirements in HN thread, thanks

zeroimpl|1 month ago

You or the developer could piggy back on “aws configure export-credentials --profile profile-name —-format process” to support any authentication that the CLI supports.

fosron|1 month ago

Yeah, without SSO support this is a no-go for me too.

brendank310|1 month ago

Nice! A while back I had started something similar for Azure but it never really got traction (or nearly as polished as this!). It's a rough proof of concept but maybe it'll be useful to Azure users:

https://github.com/brendank310/aztui

NSPG911|1 month ago

Seems like everyone is interested in Rust, but yours was written in Go.

themafia|1 month ago

I wish more TUI designers would spend some time playing with Hercules and experiencing the old "mainframe" way of arranging interfaces. Those guys really knew what they were doing.

jxdxbx|1 month ago

I would like to know more about this. I love the resurgence of TUI apps but there is a samey-ness to them.

wilkystyle|1 month ago

Anything in particular you liked about them?

jbreckmckye|1 month ago

Interesting, looks like k9s... but for AWS

jedimastert|1 month ago

That was my first thought too, it looks like it was directly inspired by k9s according to the bottom of the readme.

politelemon|1 month ago

Please don't use or suggest using homebrew as a Linux installation solution. It's better to simply point at the binaries directly.

OptionOfT|1 month ago

Why?

Is it the best out there? No. But it does work, and it provides me with updates for my tools.

Random curl scripts don't auto-update.

Me downloading executables and dropping them in /bin, /sbin, /usr/bin or wherever I'm supposed to drop them [0] also isn't secure.

[0] https://news.ycombinator.com/item?id=46487921

Also, I find it is usually better to follow up with something like:

'It's better to use Y instead of X BECAUSE of reasons O, P, Q, R & S' vs making a blanket statement like 'Don't use X, use this other insecure solution instead', as that way I get to learn something too.

colesantiago|1 month ago

What's the problem with Homebrew?

> It's better to simply point at the binaries directly.

Binaries aren't at all signed and can be malicious and do dangerous things.

Especially if it's using curl | bash to install binaries.

rswail|1 month ago

Also don't use Homebrew on MacOS because it screws around in /usr/local and still hasn't worked out how root is supposed to work.

Use Macports, it's tidy, installs into /opt/macports, works with Apple's frameworks and language configuration (for python, java etc), builds from upstream sources + patches, has variants to add/remove features, supports "port select" to have multiple versions installed in parallel.

Just a better solution all around.

yarekt|1 month ago

Nice, download a random binary off the internet and give it your AWS credentials.

Please people, inspect the source to your tools, or don't use them on production accounts.

dangus|1 month ago

As a user of immutable Linux (bazzite), I suggest speaking for yourself and not for others.

On my platform, Homebrew is a preferred method for installing CLI tools. I also personally happen to like it better on Linux than Mac (it seems faster/better).

https://docs.bazzite.gg/Installing_and_Managing_Software/

frenzcan|1 month ago

What’s the issue with homebrew?

jbreckmckye|1 month ago

What's wrong with Brew?

purerandomness|1 month ago

brew is for users of non-Arch distros who want to experience what using Arch feels like.

stephc_int13|1 month ago

How much of this was made with LLM?

otterley|1 month ago

Why does it matter?

rbanffy|1 month ago

Is there a Rust port or binding for ncurses?

utkayd|1 month ago

Great TUI app. Kudos & Ellerinize saglik

dent9|1 month ago

yea let me just give access to my company AWS account credentials to this program made by some random dude on the internet

serpix|1 month ago

If you have permanent credentials then you are already in great danger. You should be using temporary credentials with something like Granted.

tvbusy|1 month ago

Nice idea but I won't trust a tool that first the commit is 11 hours ago.

bcb_1000|1 month ago

The crazier part is a reddit post on AWS was made for someone releasing a $3 a month closed source version of this, that received a lot of traction, but a bit of flack for being closed source was made 3 hours before the first commit. This guy 100% took the idea and the open source parts and recreated it to post here. Look at the readme and compare them. It is almost a 1:1 copy of the other. This dude is hella sketch. And if this is getting traction we are cooked as developers.

jedimastert|1 month ago

It looks like the first commit was just a squash and merge, I probably would never trust a public commit history as some kind of source of truth anyways. I'm curious what your issue is?

acedTrex|1 month ago

[deleted]

blutoot|1 month ago

So what if this was vibe-coded? How do you know this was a "slop" if you did not try it?

nirushiv|1 month ago

[deleted]

bcb_1000|1 month ago

[deleted]

Yanael|1 month ago

[deleted]

bcb_1000|1 month ago

This guy stole this idea and basically the whole code base from another developer and ran it through an LLM to recreate it.

songodongo|1 month ago

I think you’re vastly overestimating how difficult this type of application would be to an LLM. There’s no need to steal another code base…isn’t yours closed source, anyways?

You could probably get 90% of the way there with a prompt that literally just says:

> Create a TUI application for exploring deployed AWS resources. Write it in Rust using the most popular TUI library.

catlifeonmars|1 month ago

Making those accusations while hiding the fact that the “other developer” was you is extremely disingenuous.

mikert89|1 month ago

claude code can do this, natively without a custom implementation

saintfire|1 month ago

Just need to pay monthly for Claude and run software that's propped up by a VC funded bubble. Due for enshittification if not shuttering.

Hardly the same.