Skip to content
Goose CLI Agent AI Agents · Goose v1.54.0 Launch on AWS

Operations

This page covers running Goose CLI Agent day to day: how it is secured, how it is updated, what to back up, and how to get help.

Security model

  • No listening ports. Goose is a command-line agent you start yourself. The image adds no web UI, background service or network listener, and no messaging gateway is enabled.
  • No baked secrets. The image contains no provider key, password or private key. You add your key after launch.
  • Private user files. Goose's config, data and log directories under /home/ubuntu are mode 0700.
  • Restricted secrets directory. /etc/goose/secrets is root:goose, mode 0750. The ubuntu user is not in the goose group and cannot read it.
  • SSH. Password authentication and root login are turned off.
  • No AWS access by default. Goose does not call AWS APIs on its own. Attach only AmazonSSMManagedInstanceCore until a task needs more, and remember that Goose can use any permission the instance role has.
  • Your data goes to your provider. Goose sends your prompts and the files and command output it works with to the model provider you chose. Check that provider's data policy before you use it with private code.

First-boot service

sushi-goose-firstboot.service runs once at boot. It creates /etc/goose/config.yaml.example, /etc/goose/secrets, the workspace and the ubuntu user's Goose directories. It leaves existing files unchanged. There is no Goose service to start or stop.

systemctl status sushi-goose-firstboot --no-pager
sudo journalctl -u sushi-goose-firstboot --no-pager

Logs

Goose writes its own logs as the ubuntu user:

ls -lt ~/.local/state/goose/logs

Updates

  • Ubuntu packages get security updates automatically through unattended upgrades.
  • Goose is pinned at v1.54.0. A new Goose release comes as a new version of the AMI: launch it, copy your workspace and ~/.config/goose over, and retire the old instance. A new AMI version does not update running instances or migrate sessions and credentials.

Do not replace the Goose binary in place

Installing a different Goose build over /opt/goose/bin/goose replaces the tested, pinned version. Launch a new version of the AMI instead.

Backups

Workspace and session data stay on the root volume. Before you replace an instance, back up:

  • /var/lib/goose/workspace and any repositories you cloned.
  • ~/.config/goose/config.yaml.
  • ~/.local/share/goose, if you want to keep Goose's session history.

Push code to your git host often. Do not copy secrets.yaml into backups you share; set your key again on the new instance instead.

The root volume is the only disk. There is no separate data volume.

Check the installation

The image includes a self-test that runs as root. It checks the installed Goose binary, the secrets permissions, goose --version and goose --help, and has Goose write a file through a test model on 127.0.0.1. It uses a private temporary Goose directory, so your own configuration is not read or changed:

sudo /opt/sushi/bin/smoke.sh

Support

Software Sushi provides installation and configuration guidance for this image. Email info@softwaresushi.com with your product version and the steps you took. Never send credentials or private code. Guaranteed response times require a separate agreement. This offer does not include AAIF / Block support.

Last updated October 13, 2026 · Suggest an improvement