Docker for Goose: Use Cases

[ZhenLian]

Docker is arguably one of the most powerful technologies in the current cloud environment, and users can greatly benefit from running a container with the Goose application. One clear advantage is security. As outlined in SECURITY.md, running Goose in a dedicated container with limited privileged capabilities can significantly reduce the risk of local system attacks or unintended access to critical system resources.

While working on this issue to create a Docker container for Goose, I've come to realize that users might need to use Docker in slightly different ways. I'm starting a new discussion topic here to gather ideas on how users can utilize these containers and to share my progress on the development work.

If you have a use case that hasn't been covered in previous examples, please feel free to share it!

[ZhenLian]

Use Case 1: As a Goose user, I want to run the latest release version of Goose in a container. This approach benefits me by significantly reducing the risk of local system attacks or unintended access to critical system resources.

[mikegehard]

Will do.

I'd like to start with developing a Devcontainer feature as the first step: https://containers.dev/implementors/features/

This makes is easier for folks to integrate Goose into their existing devcontainers and not having to use a different base image.

I'm currently using devcontainers as a way to easily isolate my AI assistants: https://github.com/mikegehard/devcontainers-for-isolation

Anthropic also just released a devcontainer feature so there is adoption elsewhere in the AI assistant ecosystem: https://github.com/anthropics/devcontainer-features

Thoughts?

[mikegehard]

@ZhenLian an initial implementation of a Goose devcontainer feature: https://github.com/mikegehard/goose-devcontainer-feature

There's probably some cleanup around configuration and I'll do as I use the feature more.

Let me know what you think.

[ZhenLian]

This is looking fantastic! I'm not very familiar with the devcontainer feature, so I am going to set aside some time to learn more about it and possibly try it out this week. Overall, it looks really promising!
In the meantime, is there anything we can do on Goose's side for this, since it seems to be a "wrapper" of Goose itself? At the very least, we could reference your repository in our Docker instruction guide, but if we have something like a Goose ecosystem, this could be a great addition. I'd love to hear your thoughts on this!

[mikegehard]

Thsnks! Yeah it is just a way to quickly install goose into a docker image.

I made a comment on the unified configuration discussion. Right now if you have to rebuild the container, you have to reconfigure goose.

Also, you have to configure goose for each project you use it in because the container is project specific.

I'd love a way to easily drop a config into the image to standardize goose config across projects.

[capttrousers]

I've been using this Dockerfile that installs goose, nodejs, and uv:

FROM ubuntu:24.04

ARG NODE_VERSION=22

ENV DEBIAN_FRONTEND=noninteractive
SHELL ["/bin/bash", "-o", "pipefail", "-c"]

# Install runtime libraries 
RUN apt-get update && apt-get install -y \
  curl \
  jq \
  nano \
  vim \
  zip \
  unzip \
  bzip2 \
  tree \
  libxcb1 \
  && rm -rf /var/lib/apt/lists/*

# both uv and goose install into ~/.local/bin
ENV PATH=$PATH:/root/.local/bin

# Install UV (Python package installer)
RUN curl -fsSL https://astral.sh/uv/install.sh | sh

# https://github.com/nvm-sh/nvm?tab=readme-ov-file#installing-in-docker-for-cicd-jobs
RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.2/install.sh | bash
ENV NVM_DIR=/root/.nvm

# Add some helpful aliases
RUN echo 'alias l="ls -lh"' >> ~/.bashrc

RUN mkdir -p /agent

WORKDIR /agent
# CANARY=true   use if we want the latest canary version
RUN curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | CANARY=true CONFIGURE=false bash

CMD ["/bin/bash"]

It's 523MB so not exactly slim but is easy to build and run:

• build docker build -t goose:latest -f goose.Dockerfile .
• run docker run -it --rm goose:latest /bin/bash and then you can do goose configure once youre in the running container. (note that --rm will remove the container when you exit)

[ZhenLian]

Use Case 2: As a Goose user and developer, I want to be able to build Goose from source within a container. This approach not only provides the security benefits mentioned in Use Case 1 but also enhances consistency and portability. For instance, if I'm troubleshooting a specific error that occurs on a platform I don't primarily work with (such as Ubuntu), I can easily debug it using Docker.

[ZhenLian]

I'm currently working on this use case and am nearing the point where I can submit a pull request to run Goose in a container with basic capabilities as a developer tool :)

[ZhenLian]

Use case 2 completed in #1551

[ZhenLian]

Use Case 3: As a Goose user, I want a centralized, cloud-hosted version of Goose that can handle inputs from multiple users and generate responses. For example, it could function as a feedback consolidation assistant, allowing multiple users to ask questions and enabling Goose to perform analyses using a LLM on a shared data set. This use case was inspired by an internal discussion.

[ZhenLian]

Use Case 3 is an interesting idea. We could explore the following approaches to build Goose in a way that accommodates multiple user inputs:

1. Using named pipes within Docker, allowing multiple users to interact with a centralized Goose container. For example, users can interact with goose instance in this way:

In one terminal (to write to Goose):
cat > pipes/input
In another terminal (to read from Goose):
cat pipes/output

2. Developing a REST API wrapper for Goose, effectively transforming it into a web application that can accept user inputs and return responses.

Before diving into these implementation details, an important consideration is whether a single web container running Goose is scalable enough to manage multiple user requests. Goose seems to be designed primarily for single-machine use, so scaling it to handle increased loads may require additional design work. There are also other nuances to consider, such as handling user inputs or outputs that exceed the pipe buffer or a single API request, and managing scenarios where one user's query consumes too much of the token quota provided by the LLM provider. These questions are not difficult to address, but we might need a separate medium-level design document to clarify the objectives and limitations of what we aim to support here.

[laurentperez]

Hi. I wanted to do RAG using goose : not for the system prompt which I do understand is overridable in either router or PromptManager, but for the user prompt which does not appear to be overridable, unless I missed smth in the code.

Digging into the source code, I realized I should use my own code to RAG the prompt, then, send it to goose.

This led me to this issue where I believe a strong use case is indeed as per your comment a REST API wrapper.

All points of your comment above are valid, especially, what could happen if the augmented prompt exceeds a pipe buffer or a single API request. Docker pipe buffers are tricky, socat or using docker attach to goose container + STDIN piping may work but basically, it's hard and tedious.

I do believe the API wrapper is the best solution. Because it could weight the incoming request size, and if sum(input, output + tools tokens added by extension) > context window then return 413 Content too large.

Is a wrapper considered ? I understand it may be a difficult task.

[RepairYourTech]

All 3

[evangineer]

Use Case 4: As a Harbor user, I want to add Goose as a new Harbor service. I'm in the process of actually doing this.

It involves creating a custom Docker Compose file that works within the Harbor framework.

1. Being able to pull a prebuilt Docker image would ease the integration work.
2. Having better documentation of the various environment variables used in the existing Goose Docker Compose file.

[RepairYourTech]

Just move on. You can do everyhing goose does and so much more now with Google ai ADK and genkit. These tools are all going to be dinosaurs very soon

[RepairYourTech]

You literally tell augment code in vs code to build you a better tool using any framework you want, and then it gets custom tailored to your stack or environment and you dintbhave to worry about goose devs figuring out electron and docker

[blackgirlbytes]

Love this Harbor integration idea. It feels like a solid path for teams who want Goose capabilities baked into their infra from day one.

[taniashiba]

Thank you for sharing your experience, @evangineer ! +1 to what @blackgirlbytes said as well.

[axel7083]

Use case 5: after experimenting locally with Goose, and designing a headless recipe that suit my need. I would like to have it deployed and scheduled (similar to goose scheduled) in our Kubernetes cluster.

Therefore I would like a lightweight available container image to pull with the minimal dependencies (ideally alpine based).