Hugo: auto-connect ssh-keys and dot-cache-hugo


First, I recognize that auto-connect for ssh-keys is sensitive. In terms of trust, we were granted classic confinement privileges some time ago, but are trying to make strict confinement work as along as possible.

Please allow automatic connection for:

  interface: personal-files
    - $HOME/.cache/hugo_cache
  interface: ssh-keys



When building a static site, Hugo can pull in custom modules (themes, content, media, data, etc.) as configured by the site author. Hugo Modules are Go Modules, so Hugo calls Go (included in the Snap), and Go calls Git (also included in the snap).

Currently, the Hugo Snap package cannot pull in custom modules when a user has configured Git to use SSH. For example, in their $HOME/.gitconfig file:

[url ""]
  insteadOf =

The ssh-public-keys interface is insufficient; the ssh-keys interface is required.

Think of Hugo as a compiler that is used in two modes: attended (i.e., human types the command) and unattended (i.e., part of a build chain in CI/CD environments). Auto-connection is a convenience in attended mode, but required in unattended mode.


When building a static site, Hugo caches build artifacts (modules, images, data, etc.) to improve performance and reduce network load. Historically we stored some of these caches in /tmp/hugo_cache (which translates to /tmp/snap-private-tmp/snap.hugo/tmp/hugo_cache for the Hugo Snap package).

In the next minor version release we will move the caches to $HOME/.cache/hugo_cache. The primary reason for this change is to mitigate cache volatility.

Thanks in advance for your consideration.


It’s been a while since I used golang, but HOME the environment variable in the context of the snap should resolve to $REAL_HOME/snap/hugo/current making the full path available as $REAL_HOME/snap/hugo/current/.cache/hugo_cache which should support the spirit of the change and be fully managed by the snap (e.g.; the cache is removed on snap removal)

@sergiusens Thank you for the review—much appreciated.

Without getting into the details, another reason for this change is to make it easier to find the cache regardless of installation method (e.g., prebuilt binary, apt, Snap, Homebrew, etc.).

Although we provide a programmatic mechanism for invalidating some caches (max age) and clearing others, there are situations where users must manually clear the cache to resolve a problem.

While the /tmp/snap-private-tmp/snap.hugo/tmp/hugo_cache path is obvious to you and I, it is not obvious to the average Hugo user.

Thanks again.

Hi @jmooring,

+1 for the dot-cache-hugo, that is understandable as the write access will be limited to a directory clearly owned by hugo

for ssh-keys: would you expect that the majority of Hugo users would expect the snap to have access to their private ssh-keys? I understand that Hugo is a compiler and as such we have granted the right to use classic which is a superset of this access, but I’m just exercising caution and considering what users might expect when installing a strictly confined application.

To satisfy the case of unattended installs, would it be possible to do something like provide instructions to (optionally) add the step snap connect hugo:ssh-keys into CI/CD scripts?


I think your caution is justified, and access to SSH Keys is relatively uncommon. Let’s go with a manual connection for now, and we can revisit in the future if the need arises. I appreciate your thoughtful response.

1 Like

Agree with @dclane on the manual connection of ssh-keys interface.

+1 on auto connect of the personal-files interface named dot-cache-hugo, since the snap clearly requires it. +1 on the manual connection of ssh-keys interface


1 Like

+2 votes for, 0 against: granting auto-connect of dot-cache-hugo. This is now live.

Not granting auto-connect of ssh-keys.

1 Like