Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

• I'd be willing to implement this feature (contributing guide)

Describe the user story

As a security focused SRE, I want as few dependencies installed on my OCI container images as possible, so that I may simplify and automate vulnerability management as much as possible, and remove as many attack vectors from the system as possible. I find that sometimes I am getting pinged on vuln scans for the atlantis image for versions of terraform or tofu which I am not using.

I also want the business maintaining artifact storage for these images to have as low overhead as possible, so they may throw money at me instead.

Finally, I want Atlantis system rotation events (e.g. swapping nodes because I am updating a node group in k8s), to be as fast as possible, so that business services which rely on this deployment mechanism have as low downtime as possible.

Describe the solution you'd like

I like the current alpine images as a base. I recommend providing 2 alternate images which are very similar:

• ghcr.io/runatlantis/atlantis:v0.33-alpine-slim-terraform - only would have /usr/local/bin/terraform which is version $DEFAULT_TERRAFORM_VERSION
• ghcr.io/runatlantis/atlantis:v0.33-alpine-slim-tofu - only would have /usr/local/bin/tofu which is version $DEFAULT_OPENTOFU_VERSION

Describe the drawbacks of your solution

• More ongoing engineer time cost for runatlantis maintainers to maintain more images.
• Duplication of code risk in Dockerfile runtime stages

Describe alternatives you've considered

The build is Apache 2, so I can fork it and change it to meet my purpose without much worry relatively easy. However it would be a bummer if many (potentially thousands given star count) engineers ended up doing this as opposed to having a single source of truth for the minimal build.

I recommend only to support alpine for this context, because users seeking very minimal builds are more likely to use this compared to debian. This should mitigate the code duplication risk described earlier, there will only be code dupe for alpine but not for the debian images.