lstk：LocalStack の日常操作を Go 製 TUI/CLI にまとめる
Cloud service を local で再現するとき、注意を削るのは LocalStack そのものだけではない。Docker や Colima は起動しているか、auth token はどこにあるか、config file はどの directory に作られたか、port は 4566 でよいか、logs はどの container から見るか、aws、terraform、cdk、sam を local endpoint に向けるには何を export すればよいか。Test のあと state を残すのか、CI では non-interactive output をどう判定するのか。こうした周辺作業が地味に積み上がる。
もちろん全部 shell script で組める。しかし script が増えるほど、team member ごとの local environment は違う形に育つ。ある人は Docker Desktop、ある人は OrbStack、ある人は Colima。Token を environment variable に置く人もいれば、system keyring に任せる人もいる。docker logs を直接見る人、AWS CLI を alias で包む人。結果として LocalStack は cloud service emulation を楽にしたのに、developer は別の local control plane を維持することになる。
今日見るのは localstack/lstk。LocalStack team が開発している Go 製 CLI で、modern terminal UI と native CLI experience によって LocalStack deployments を管理する。入口は分かりやすい。Install 後に lstk を実行すると、authentication、configuration、container setup を処理して LocalStack を起動する。Interactive terminal では Bubble Tea style の TUI を出し、script や CI では plain text output に寄せる。一部 command では structured JSON envelope も使える。
GitHub repository page、README、LICENSE、Releases、Tags、go.mod、recent commit を 2026-08-18 10:00 Asia/Shanghai 時点で確認すると、localstack/lstk は 36 stars、7 forks。主要言語は Go、license は Apache-2.0。Repository created time は 2026-01-27 13:04:48 UTC、latest public push は 2026-08-18 09:59:51 UTC、default branch は main。最新 GitHub Release は v0.22.0、published time は 2026-08-13 10:49:43 UTC。最新 tag も v0.22.0。Recent commit は 087c6ec、message は “Mandate TDD with observable-behavior e2e tests in agent guidance (#445)”、commit time は 2026-08-18 09:59:50 UTC。go.mod の module は github.com/localstack/lstk、declared Go version は 1.26.1 だ。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | localstack/lstk |
| 位置づけ | LocalStack emulator lifecycle を管理する Go CLI / TUI |
| Stars | 36 |
| Forks | 7 |
| 主要言語 | Go |
| ライセンス | Apache-2.0 |
| 作成日時 | 2026-01-27 13:04:48 UTC |
| Latest push | 2026-08-18 09:59:51 UTC |
| Default branch | main |
| 最新 GitHub Release | v0.22.0、2026-08-13 10:49:43 UTC |
| Recent commit | 087c6ec、Mandate TDD with observable-behavior e2e tests in agent guidance (#445) |
| キーワード | LocalStack、CLI、TUI、Docker、snapshots、cloud CLI proxy |
LocalStack の control plane を一つに寄せる
lstk の価値は、単に docker run localstack/localstack を包むことではない。README に並ぶ機能は local cloud development workflow の部品に近い。Start、stop、status、logs で emulator lifecycle を扱う。Browser login で認証し、credential は system keyring に保存する。CI では LOCALSTACK_AUTH_TOKEN を使える。Local files、cloud snapshots、自前 S3 bucket の snapshot を扱える。さらに aws、az、terraform、cdk、sam を LocalStack 向け endpoint、credentials、region 付きで実行できる proxy command もある。--endpoint-url や LSTK_ENDPOINT_URL で、lstk が管理していない external emulator に向けることもできる。
これは LocalStack user がよく知っている friction を減らす。Emulator を起動するだけなら簡単でも、毎日の体験は周辺 command が安定しているかで決まる。Terraform module を一つ検証したいだけなのに、endpoint を export し、dummy AWS credentials を用意し、container port を確認し、別 terminal で logs を追う必要があるなら、人間も agent も context を無駄にする。lstk はそれらを一つの tool surface に寄せ、project README、shell alias、CI snippet に分散しないようにする。
Container runtime の扱いも現実的だ。README は Docker-API-compatible container engine を前提にし、Docker、Rancher Desktop、Colima、OrbStack、Lima、Podman を auto-detect すると説明している。Mac developer では特に重要だ。全員が Docker Desktop を使う前提はもう弱くなっている。Tool が runtime 差をある程度吸収できれば、LocalStack を team に試してもらうコストはかなり下がる。
TUI は人間向け、plain output は script 向け
Local development tool でよくある問題は、interactive UI は人間に優しいが CI では扱いにくく、pure CLI は script に優しいが毎日使うには覚えることが多い、という分裂だ。lstk の README はこの点を分けている。Interactive terminal では Bubble Tea-powered TUI を使い、non-interactive environment では plain output を出す。必要なら --non-interactive で script mode を強制できる。
この設計は LocalStack に合っている。Developer は status、logs、running emulator、authentication state を視覚的に見たい。CI は exit code と error reason を明確に判定したい。lstk の structured output docs はさらにその方向を進めている。--json は terminal text を適当に JSON に入れるものではなく、schemaVersion、command、status、data、warnings、error という envelope、stable error code、coarse category を定義している。
ただし境界は確認したい。Docs によると JSON support は command ごとに rollout 中で、現時点で実装済みなのは stop、reset、update など。その他 command の schema は draft で、未対応なら NOT_JSON_CAPABLE になる。この状態はむしろ健全だ。Envelope、error code、exit code を先に安定させ、広い command surface は段階的に広げる。Automation を書く側にとっては、colored terminal output を parse するよりずっと扱いやすい。
Cloud CLI proxy はかなり実用的な interface
lstk で特に気になるのは cloud CLI proxies だ。README は aws、az、terraform、cdk、sam command を、LocalStack endpoint、credentials、region が pre-configured された状態で実行できると説明している。これは一見、引数を少し減らすだけの機能に見えるが、実際の project ではかなり効く。
Cloud local development の事故は低レベルなものが多い。Local emulator に向けるつもりが profile は real account のままだった。CI で IaC を検証したいだけなのに region、endpoint、credentials が揃っていない。Local と pipeline で wrapper が違い、同じ command のつもりで別の動きをする。Unified proxy layer は全ての安全問題を解くわけではないが、「この command はどこへ向かっているのか」を一時的な shell state ではなく tool configuration に寄せられる。
Agent workflow でもこれは役に立つ。AI coding agent が shell command を実行するとき、context に「aws command を走らせて」とだけ書かれていて、local emulator なのか real cloud なのか曖昧だと危ない。Project が lstk aws ... や lstk terraform ... を入口にしていれば、agent は local emulator path を辿りやすくなる。もちろん credential と permission boundary は team が管理すべきで、command prefix だけに頼るべきではない。
Snapshots で local cloud state を複製しやすくする
もう一つ実用的なのは snapshots だ。LocalStack が扱う cloud service は stateful なので、少し複雑になると「自分の machine では再現するが、他の人には再現しない」が起きやすい。lstk は save、load、manage emulator state を feature list に入れ、local files、cloud snapshots、自前 S3 bucket を対象にできる。
これにより local cloud environment は、その場で毎回組むものから、test fixture に近いものへ寄る。例えば S3 bucket、SQS queue、DynamoDB table、IAM-like config の組み合わせを、ある bug の調査中に snapshot として保存し、同僚や CI に渡す。Integration test でも、長い setup script を毎回組むより、observable state として扱いやすい場合がある。
もちろん snapshot には lifecycle が必要だ。いつ更新するのか、誰が保守するのか、sensitive data を含まないか、LocalStack image tag と互換性があるのか。lstk がそれらの policy を代わりに決めるわけではない。ただ、state management を CLI の一等機能として扱っているのは正しい場所だと思う。
Install は簡単だが、account と version 境界は見る
Install path は普通だ。macOS / Linux では Homebrew、npm では @localstack/lstk、または GitHub Releases の pre-built binaries を使える。
brew install localstack/tap/lstk
npm install -g @localstack/lstk
lstk実行には Docker-API-compatible container engine と LocalStack account が必要になる。README では CLI が browser authentication を案内し、credential を system keyring に保存すると説明している。CI や non-interactive environment では LOCALSTACK_AUTH_TOKEN を使える。この token と keyring の優先順位は team docs に書いておきたい。同じ machine で keyring token と environment variable が競合すると、原因調査に時間を使うからだ。
Version についても保守的に見たい。lstk の latest release は v0.22.0 で、まだ 1.0 ではない。Release cadence は活発でよいことだが、command、config、JSON schema はまだ変わる可能性がある。Local development と non-critical CI path で試し、team standard にするなら version pinning と upgrade flow を用意するのがよい。
Caveats
第一に、LocalStack ecosystem への依存が強い。すでに LocalStack を重く使っているなら利点だが、たまに AWS mock を起動するだけなら既存の docker compose で十分かもしれない。lstk の価値は local cloud workflow が複雑になるほど大きくなる。
第二に、account、license、container runtime、image pull、port、system keyring は避けられない現実の境界だ。Tool が入口を統一しても、environment issue が消えるわけではない。Enterprise network、offline development machine、company proxy、private registry、rootless Podman では、先に小さく検証したほうがよい。
第三に、JSON output はまだ段階的に広がっている途中だ。今日 script に入れるなら、対象 subcommand が本当に --json を support するか確認し、error code で分岐するべきだ。すべての command が stable machine output を持つと仮定すると早い。
まとめ
localstack/lstk が面白いのは、LocalStack を単なる container として扱わず、local cloud development で散らばりがちなものを一つの CLI に集めている点だ。Authentication、configuration、runtime detection、lifecycle、logs、snapshots、cloud CLI proxy、script output が同じ入口に並ぶ。
まだ若い project で、36 stars、7 forks、v0.22.0 という version number は community と interface が early stage であることを示している。それでも摩擦の位置は具体的だ。毎日 LocalStack を起動し、IaC を試し、queue/object storage/function integration を local で確認し、あるいは agent に local cloud environment で command を実行させる developer なら、lstk は control plane として試す価値がある。