Cloudlens puts the AWS and GCP consoles in a terminal

A console in the terminal, modelled on k9s

Cloudlens is described as a k9s like command line for AWS and GCP, and the readme puts it plainly, as the AWS and GCP console in your terminal, well, almost. The services it can show are listed per cloud. For AWS that is EC2 instances, S3 buckets, EBS volumes, VPCs, SQS queues, Lambda functions, subnets, security groups and IAM roles. For GCP it is VM instances, storage buckets, disks, snapshots and images. The acknowledgement section says plainly that k9s was an invaluable source of reference for the project, which tells you the interaction model is borrowed wholesale rather than reinvented, and that is the right call, because the whole value of the tool is that an existing k9s user needs no instructions. The Go dependency list supports that reading, with the terminal UI library that k9s itself uses for its widgets and the cell based terminal library underneath it, along with a progress bar package and a markdown renderer for help text. The project is Apache-2.0 licensed and is being built by a small team, with the repository listing a code of conduct and a contributing guide alongside the code.

The navigation model is k9s mnemonics

The key bindings table is short and it is the whole interaction model. Pressing the question mark shows the active keyboard mnemonics and help, which is the k9s convention for a single screen of help rather than a manual. You leave with a quit command or ctrl-c, and the escape key bails out of view, command or filter mode, which is the detail that makes the tool feel familiar after ten minutes, because a filter you can escape is a filter you will actually use. To move between services you type a colon and the service name, for example an S3, EC2 or VPC command on AWS, and a storage, vm or disk command on GCP. The lower case service names for GCP against the upper case for AWS is a small inconsistency, and it is the sort of thing you only notice because the documentation is explicit about it. The screenshots in the readme follow the same structure, a list view and a details view per resource type, for instance for EC2 and for S3 on AWS, and for virtual machines and storage on GCP.

Two ways in, and one of them needs credentials on the command line

For simple use you run the command with no options, and it opens a UI to select the cloud platform, with a note that when you pick GCP you must set the GOOGLE_APPLICATION_CREDENTIALS environment variable to the path of a credentials file. The alternative is to skip the picker and use subcommands, which is what you want in a script.

cloudlens aws

cloudlens gcp --cf="path/to/gcp-credentials.json"

And the help command lists everything else.

cloudlens help

There is also a self update command.

cloudlens update

The self update is implemented with the minio self update library in the dependency list, and the release configuration is in a goreleaser file, which is how the Homebrew tap and the install path exist at all. The interesting tension is that passing a credentials file path as a flag puts the path in your shell history and in the process list, where the environment variable approach does not, and a team with a policy about that will want to know which form their users default to.

Read only, and the project tells you how to keep it that way

The note at the end of the readme is short and is the part a security reviewer will look for first. Cloudlens reads your AWS config file in your home directory, it does not store or send your access and secret key anywhere, and the keys are used only to connect to the AWS API through the AWS SDK. The recommendation follows, which is that since the tool is in read only mode you should create an access and secret key that has only read permissions on the AWS services. That is good practice stated in the right place, and it is the reason the tool is safe to point at a production account. The dependency list is consistent with the claim, since there is no write path in the architecture, and the read only framing is repeated in the project description of the tool. The one thing to check for yourself is what the IAM role listing view does with the credentials it displays, since a screen that renders secrets is a screen that ends up in screenshots and terminal scrollback.

Localstack is how you develop against it without touching a real account

The prerequisites call for Docker on your machine, and then mention a separate repository, cloud-lens-populator, for populating dummy data when you want to use localstack. The localstack path is integrated into the CLI rather than left to configuration, with a localstack flag on the AWS subcommand and a port flag to override the default.

cloudlens aws --localstack --port 4000

The default port is 4566, and the compose file in the repository matches that. The compose service runs the localstack image, enables the S3 and EC2 services through the services environment variable, turns on debug output, persists the data directory to a local folder, and publishes the port. The makefile has a setup target that brings it up and a matching teardown target that finds the container by name, stops it and removes it with its volumes. The acknowledgements thank localstack for its assistance with the development, and the practical benefit is the obvious one: a developer can iterate on a new resource view against a local fake without spending a cent or touching a real account.

The dependency set, and a Go version story that does not add up

The module file is worth reading because it describes the implementation accurately. Both generations of the AWS SDK are present, the original at 1.55.8 and the second generation at 1.43.2 with its config package, which is the sort of thing that happens when a project is extended over years and the old path is not removed. On the Google side there is the compute and storage client libraries and the general API client, with the identity and monitoring packages pulled in transitively. The interface layer is the terminal UI library with the cell library, the command line parsing is cobra, the logging is zerolog, and there is a config directory library, an ini parser and a clipboard helper for copying values out of a details view. The version story, though, is inconsistent. The readme says Go 1.19 is needed to install and to build, while the module file declares a much newer Go version, and the makefile pins a release version string that matches the newest tag, v0.1.4, which was published in November 2023, even though the repository was pushed to as recently as 2026-08-06. The build itself is a single go build with version, commit and date injected into the binary through linker flags, which is a tidy release setup.

Editorial conclusion

Cloudlens earns its place for an engineer who lives in the terminal and wants to check what is running in a cloud account without opening a browser tab and a dozen consoles, since the k9s style navigation makes browsing a fleet of instances as quick as listing a Kubernetes namespace. It is a poor choice if you need to change anything, because the tool is read only and the keys it uses should be read only too, and it is a poor choice if you need depth, since the resource list covers the common services rather than the full API surface of either cloud. Verify three things before you use it on a real account: that your credentials are read only, as the project itself recommends, that the Go toolchain on your machine matches what the module file asks for, which is newer than the version the readme mentions, and that the service list is enough for what you actually need to inspect, since there is no generic resource browser. The licence is Apache-2.0, the newest release is v0.1.4 from 2023-11-29, and the last push was on 2026-08-06.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. one2nc/cloudlens on GitHub
3. Project website
4. README
5. Releases