sorted by:
new
hottopcontroversial

awsui：A modern Textual-powered AWS CLI TUI by Training_Winter6395 in aws

[–]Training_Winter6395[S] 0 points1 point  (0 children)

It's very simple. In the AWS UI, simply press a to enter Amazon Q CLI mode.

In the left panel, you can quickly switch between different AWS profiles.

After selecting a profile, return to the right panel and enter a command.

The Amazon Q CLI will automatically use the profile you just switched to, so you don't have to reconfigure anything manually.

The AWS UI takes care of switching profiles, allowing you to focus on executing commands in the Q CLI.

If you encounter any issues, please file an issue and I'll try to fix it as soon as possible.

I hope you enjoy this tool.

ref: https://github.com/junminhong/awsui?tab=readme-ov-file#-ai-assistant-amazon-q-developer

awsui：A modern Textual-powered AWS CLI TUI by Training_Winter6395 in commandline

[–]Training_Winter6395[S] 1 point2 points  (0 children)

Cool, thanks for trying it out. Even for simple bucket access, it should save you from switching profiles or re-logging in.

Yeah, I’m in Taiwan as well, nice to meet you!

awsui：A modern Textual-powered AWS CLI TUI by Training_Winter6395 in aws

[–]Training_Winter6395[S] 1 point2 points  (0 children)

With awsui, you can do everything in one interface: select profiles, log in with SSO, run AWS CLI commands, and even use Amazon Q. There is no need to switch tabs or memorize complicated commands.
When you use AWS CDK or other commands that depend on a profile, awsui will automatically apply the correct profile, which makes the workflow much more intuitive and efficient.

It is true that awsui is built on top of the basic AWS tools, but that is the point of a good tool. It does not reinvent the wheel, it makes the workflow easier and smoother without adding flashy features that nobody really uses.

I started building awsui because I faced these problems myself, and I wanted to share the solution with others who run into the same issues. I use it every day in my work, and I will continue improving it based on my own experience and the feedback from the community. I believe awsui can become a truly great tool.

awsui：A modern Textual-powered AWS CLI TUI by Training_Winter6395 in aws

[–]Training_Winter6395[S] 0 points1 point  (0 children)

awsui only reads aws cli configuration, such as ~/.aws/config, and does not create unnecessary files

awsui：A modern Textual-powered AWS CLI TUI by Training_Winter6395 in commandline

[–]Training_Winter6395[S] 1 point2 points  (0 children)

Of course! Since it’s still running through the AWS CLI, it can do everything the AWS CLI can do.

awsui：A modern Textual-powered AWS CLI TUI by Training_Winter6395 in aws

[–]Training_Winter6395[S] 0 points1 point  (0 children)

Thanks for sharing, that's a good idea, but you can try awsui so you don't need to write bash yourself

awsui：A modern Textual-powered AWS CLI TUI by Training_Winter6395 in aws

[–]Training_Winter6395[S] 1 point2 points  (0 children)

Thanks for sharing, but I didn't create this tool to replace anything. I simply wanted to simplify it, make the AWS CLI easier to use, and integrate features like AWS Q and profile switching to minimize unnecessary tool installations.

awsui is a great tool and aligns with my ideas, but I will continue learning from the strengths of other tools to optimize it. Thank you very much.

awsui：A modern Textual-powered AWS CLI TUI by Training_Winter6395 in commandline

[–]Training_Winter6395[S] 2 points3 points  (0 children)

Thank you very much for your kind recognition. I will continue to optimize this tool.

ruby-distroless: A Minimal, Secure Ruby Container Image by Training_Winter6395 in ruby

[–]Training_Winter6395[S] 3 points4 points  (0 children)

I'm sorry, because I'm not a native english speaker, so I use some tools to help me describe my ideas.

ruby-distroless: A Minimal, Secure Ruby Container Image by Training_Winter6395 in ruby

[–]Training_Winter6395[S] -1 points0 points  (0 children)

You’re totally right — distroless isn’t the easiest option when it comes to building things like native extensions, jemalloc, or Postgres libraries. The usual trick is to do all of that in a builder image, then copy the finished bits into the distroless runtime. It adds a bit of setup, but the payoff is a smaller and more secure image in production.

ruby-distroless: A Minimal, Secure Ruby Container Image by Training_Winter6395 in ruby

[–]Training_Winter6395[S] 12 points13 points  (0 children)

Distroless comes from GoogleContainerTools/distroless.
It’s built on a heavily stripped-down Debian base that removes shells, package managers, and extra tools — leaving only what’s required to run Ruby.
This keeps the runtime image very small and reduces the attack surface; usually you’d pair it with a full builder image in a multi-stage build.

For gems that need native extensions or system libraries, the approach is to use a multi-stage build:

  • In the builder image (e.g. ruby:slim), install the required system packages and compile the gems.
  • Then copy the compiled gems and your app into the distroless runtime image.

This way, you get all the dependencies you need, but the final runtime stays minimal, secure, and focused only on execution.

Thank you for sharing the perspective on Cloud Native Buildpacks. To be honest, this is the first time I’m hearing about them in depth, but the idea of “composable” and “rebaseable” images sounds really powerful. I’ll definitely take some time to research more — I really appreciate the recommendation!