e1s: browsing and driving AWS ECS from a terminal, k9s style

A terminal browser for ECS, not a wrapper around the console

e1s is a terminal application for browsing and managing AWS ECS resources, written in Go and published under the MIT licence by keidarcy. It supports both Fargate and EC2 launch types, which is the distinction that decides whether it is useful to you, since a lot of ECS tooling assumes one capacity model. The interface is a text user interface in the style of k9s, the Kubernetes terminal tool it says it is inspired by, and the repository ships a screenshot and a short demo animation rather than a wall of documentation. The underlying libraries in go.mod explain the shape of the thing: rivo/tview and gdamore/tcell provide the terminal widgets, cobra parses the command line, viper reads the configuration, and the AWS SDK for Go v2 with the ecs, ssm, cloudwatch, cloudwatchlogs, applicationautoscaling and account service clients does the talking to AWS. The result is a tool for an engineer who already lives in the terminal and wants ECS state on one screen.

Credentials come from the AWS CLI, and e1s keeps none

The credential story is deliberately uninteresting, which is the right design for a tool that can execute commands inside your tasks. e1s uses the default aws-cli configuration and states plainly that it does not store or send your access key or secret key anywhere, with credentials used only to reach the AWS APIs through the SDK. There are three ways to pick a profile and a region. You can use your default AWS CLI profile and region. You can override them at startup with AWS_PROFILE, AWS_REGION, --profile or --region. Or you can switch them while the program is running, with Ctrl+P for profiles and Ctrl+R for regions. Because it reads the local shared config and credentials files, it works with static credentials, assume-role profiles, credential_process and AWS IAM Identity Center or SSO based setups. That last point matters for most teams today, since a hardcoded key pair is rarely what anyone uses in production.

Five ways to install e1s, including go install and Docker

e1s is available for Linux, macOS and Windows, with binaries on the release page, and the project lists several install paths. Homebrew is the smoothest for macOS and Linux:

brew install keidarcy/tap/e1s

If you write Go, you can build it from source into your GOPATH:

go install github.com/keidarcy/e1s/cmd/e1s@latest

A container image is published, which is also the path that brings the session manager plugin along, since the image installs the plugin and the AWS CLI before it starts the binary:

docker pull ghcr.io/keidarcy/e1s:latest

For a quick trial without touching your laptop, the CloudShell install script does the work in one line:

curl -sL https://raw.githubusercontent.com/keidarcy/e1s-install/master/cloudshell-install.sh | bash

There is also an asdf plugin and a mise recipe, and the release page carries prebuilt binaries for people who prefer to download an artefact and put it on PATH themselves.

Flags that decide how much you are allowed to change

The command line surface is documented in the help output, and several flags exist purely to control blast radius. --read-only puts the interface into read only mode, which is the flag to reach for when a colleague or a shared screen is involved. --exec-mode chooses between ecs and ssm execution of commands in a container, and --shell sets the interactive shell, defaulting to /bin/sh. --refresh takes an integer number of seconds, where -1 stops auto refresh entirely, and the default is 30. Other flags pick a starting cluster and service, set a theme, write logs to a file, emit JSON logs, show or hide the startup splash, and select a config file. Because the cluster and service flags depend on each other, --service requires --cluster, which is a small sign that the tool is careful about state you did not intend to change.

Running the tool with a profile, a region and a config file

The examples in the documentation show the combinations people actually use. The simplest is running it with no arguments at all:

# use all default config
$ e1s

Selecting a profile and a region can be done through the environment or through flags:

# use custom-profile profile, us-east-2 region
$ AWS_PROFILE=custom-profile AWS_REGION=us-east-2 e1s
# use custom-profile profile, us-east-2 region
$ e1s --profile custom-profile --region us-east-2

And the read only, no refresh combination is one flag away from a live session:

# use command line to set read only, debug, stop auto refresh with a custom log path, json output, and dracula theme
$ e1s --read-only --debug --refresh -1 --log-file /tmp/e1s.log --json --theme dracula

The container image runs the same binary, so the profile is mounted from your home directory:

# docker run with specified profile and region
$ docker run -it --rm -v $HOME/.aws:/root/.aws ghcr.io/keidarcy/e1s:latest e1s --profile YOUR_PROFILE --region YOUR_REGION

Mounting the credentials directory is the one step to get right in the container, and the documentation spells out that path explicitly.

Config file, viper formats and custom colours

The configuration file lives at $HOME/.config/e1s/config.yml by default, and --config-file points elsewhere. Because e1s uses viper, the standard config file formats viper supports are available, not only YAML. The settings worth keeping in the file are the theme, the refresh interval, the read only mode, the log file path, a default cluster and service, the splash screen toggle, and colour overrides. A colour override block looks like this:

colors:
  BgColor: "#272822"
  FgColor: "#f8f8f2"
  BorderColor: "#a1efe4"
  Black: "#272822"
  Red: "#f92672"
  Green: "#a6e22e"
  Yellow: "#f4bf75"
  Blue: "#66d9ef"
  Magenta: "#ae81ff"
  Cyan: "#a1efe4"
  Gray: "#808080"

Named colour keywords are accepted in the same keys, so a scheme can be written with words such as black, orangered and lightskyblue instead of hex values. Named themes are also selectable with --theme, for example --theme dracula, and the full list of available themes lives in the author's alacritty-theme repository, so a terminal theme can be matched to the TUI.

Where e1s stops and the AWS CLI keeps going

The limits are clear enough to state. First, e1s is an interactive program, so it is the wrong tool for a script, a pipeline or a scheduled job; the AWS CLI remains the tool for anything unattended, and e1s does not replace it. Second, the scope is ECS. The service clients in go.mod cover ECS plus the supporting services, so a task that needs to inspect a load balancer, a route 53 record or an IAM policy is still an AWS CLI or console job. Third, exec and port forwarding depend on local tooling. The session manager plugin has to be installed if you want the interactive exec or port forwarding features, and in ssm mode there is a --ssm-custom-command template for the custom command, while the ecs mode uses the exec API directly. The Docker image works around that by installing the plugin itself, but a locally installed binary does not. Finally, the documentation is uneven. The README covers installation, flags, configuration and themes in detail, and the key binding section is where it stops, so the deeper key map lives outside what the README shows.

Releases, licence and the shape of the project

The repository is not archived and the last push was on 2026-10-05. The release history shows a clear break at a major version: v2.0.0-rc.4 on 2026-06-07, v2.0.0-rc.5 on 2026-06-22 and v2.0.0 on 2026-09-07. A run of release candidates before a 2.0 tag is what a maintainer does when a large interface change lands, and if you are pinning a version for a team, pick the 2.0.0 tag rather than an rc. The licence is MIT, so the code can be used and modified in a commercial setting as long as the copyright notice and the licence text travel with copies of it, and the repository keeps a LICENSE file for that purpose. The project is built with goreleaser, judging by the .goreleaser.yml at the root, which is what produces the multi platform release binaries. The Makefile also carries a Terraform based test harness, with a plan target that takes cluster_count, service_count and task_count variables against a directory called tests, which is how the maintainer provisions a throwaway ECS environment to develop against.

Editorial conclusion

Adopt e1s when you spend your day inside AWS ECS and want a single keyboard driven view of clusters, services and tasks, especially when you need exec or port forwarding without leaving the terminal, and when you are willing to keep the session manager plugin installed locally. Do not adopt it for automation, since the interface is interactive, and do not expect it to cover AWS services outside ECS. Verify first that the IAM permissions of your profile cover the ECS, CloudWatch, CloudWatch Logs, application autoscaling and Systems Manager calls it makes, and that the session manager plugin is present if you plan to use the ssm exec mode, since the README lists it as a prerequisite. The last push was on 2026-10-05 and the current release is v2.0.0 from 2026-09-07, under the MIT licence.

Frequently asked questions

Official sources

1. keidarcy/e1s on GitHub
2. License: MIT
3. Project website
4. README
5. Releases