Update eniz1806/vaults3 Docker tag to v4.4.55 #355

2026-08-22T22:02:12+02:00

renovate-bot commented

2026-08-22 22:02:12 +02:00

This PR contains the following updates:

Package	Update	Change
eniz1806/vaults3	patch	`4.4.53` → `4.4.55`

Release Notes

Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)

`v4.4.55`

Compare Source

Fixed

A freshly downloaded binary would not start. The release archive ships the
two binaries, README.md and LICENSE, and the release notes say to extract
it and run ./vaults3. The server read configs/vaults3.yaml unconditionally
and exited when it was absent, so the documented install failed on the first
command, on every release. A config file at the DEFAULT path is now optional:
its absence is an ordinary first run, and the built-in defaults are already a
working single node. A config path given explicitly with -config must still
exist, because there a missing file means a typo rather than a first run
(issue #51, reported by tsundara).
The first thing a new user saw was a URL they could not open. The startup
line printed the bind address, so a default install advertised its dashboard
at http://0.0.0.0:9000/dashboard/. A wildcard bind is where the server
listens, not somewhere a browser can go; it now prints 127.0.0.1 for a
wildcard.
Relative paths did not work inside the container. The image set no working
directory, so ./data and friends resolved at /, which the unprivileged
runtime user cannot write to. The image now has a writable working directory.
The server itself was never affected: the image points it at absolute paths.

Security

A server told no admin secret now generates its own instead of falling
back to vaults3-secret-change-me, which is printed in this repository.
Anyone who downloaded VaultS3, started it and exposed port 9000 was running a
server whose password is public, and a warning in the log is not a control:
the people most likely to miss it are exactly the people who never set a
secret. The generated secret is stored with the metadata and printed once, so
later starts reuse it.
- Nothing is taken away from an existing installation. Credentials already
  persisted, which includes any password set from the dashboard and anything a
  previous start saved, still win over everything else, and an explicitly
  configured secret is still honoured. Only an installation that has never had
  a secret gets a generated one.
- The sample config, the Helm chart and the Kubernetes manifest no longer
  carry the example secret in the places that are overridden at runtime, and
  the chart's auth.secretKey now defaults to empty, which makes
  helm install generate one and preserve it across upgrades.
A server still running the published example secret says so on every start,
rather than only when it also uses the default access key.

Added

vaults3 setup, an interactive first-run command (issue #51). It asks for
the data, metadata and log locations, the listen address and port, the admin
credentials and any buckets to create at startup; creates the directories;
and writes a config file. It writes only what you chose, so clustering,
encryption, replication and the rest stay out of the file rather than
appearing as a wall of disabled blocks. The file is written 0600 because it
holds the admin secret, an existing config is never overwritten without
--force, and the run ends by printing the start command, the dashboard URL
and the credentials.
- --non-interactive takes every answer from flags for scripted installs, and
  is also what a piped stdin selects, so setup never blocks in a pipeline.
vaults3 help and a usage message that names the subcommands.

Internal

Fixed a data race in the transport mux test helper, which set the handshake
timeout after the accept loop that reads it had already started. The shipped
binary never wrote that field after construction, so no released build was
affected, but go test -race failed. It is now a constructor parameter.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Update | Change | |---|---|---| | [eniz1806/vaults3](https://github.com/Kodiqa-Solutions/VaultS3) | patch | `4.4.53` → `4.4.55` | --- ### Release Notes <details> <summary>Kodiqa-Solutions/VaultS3 (eniz1806/vaults3)</summary> ### [`v4.4.55`](https://github.com/Kodiqa-Solutions/VaultS3/blob/HEAD/CHANGELOG.md#4455---2026-08-22) [Compare Source](https://github.com/Kodiqa-Solutions/VaultS3/compare/v4.4.53...v4.4.55) ##### Fixed - **A freshly downloaded binary would not start.** The release archive ships the two binaries, `README.md` and `LICENSE`, and the release notes say to extract it and run `./vaults3`. The server read `configs/vaults3.yaml` unconditionally and exited when it was absent, so the documented install failed on the first command, on every release. A config file at the DEFAULT path is now optional: its absence is an ordinary first run, and the built-in defaults are already a working single node. A config path given explicitly with `-config` must still exist, because there a missing file means a typo rather than a first run (issue [#51](https://github.com/Kodiqa-Solutions/VaultS3/issues/51), reported by tsundara). - **The first thing a new user saw was a URL they could not open.** The startup line printed the bind address, so a default install advertised its dashboard at `http://0.0.0.0:9000/dashboard/`. A wildcard bind is where the server listens, not somewhere a browser can go; it now prints `127.0.0.1` for a wildcard. - **Relative paths did not work inside the container.** The image set no working directory, so `./data` and friends resolved at `/`, which the unprivileged runtime user cannot write to. The image now has a writable working directory. The server itself was never affected: the image points it at absolute paths. ##### Security - **A server told no admin secret now generates its own** instead of falling back to `vaults3-secret-change-me`, which is printed in this repository. Anyone who downloaded VaultS3, started it and exposed port 9000 was running a server whose password is public, and a warning in the log is not a control: the people most likely to miss it are exactly the people who never set a secret. The generated secret is stored with the metadata and printed once, so later starts reuse it. - **Nothing is taken away from an existing installation.** Credentials already persisted, which includes any password set from the dashboard and anything a previous start saved, still win over everything else, and an explicitly configured secret is still honoured. Only an installation that has never had a secret gets a generated one. - The sample config, the Helm chart and the Kubernetes manifest no longer carry the example secret in the places that are overridden at runtime, and the chart's `auth.secretKey` now defaults to empty, which makes `helm install` generate one and preserve it across upgrades. - A server still running the published example secret says so on every start, rather than only when it also uses the default access key. ##### Added - **`vaults3 setup`**, an interactive first-run command (issue [#51](https://github.com/Kodiqa-Solutions/VaultS3/issues/51)). It asks for the data, metadata and log locations, the listen address and port, the admin credentials and any buckets to create at startup; creates the directories; and writes a config file. It writes only what you chose, so clustering, encryption, replication and the rest stay out of the file rather than appearing as a wall of disabled blocks. The file is written `0600` because it holds the admin secret, an existing config is never overwritten without `--force`, and the run ends by printing the start command, the dashboard URL and the credentials. - `--non-interactive` takes every answer from flags for scripted installs, and is also what a piped stdin selects, so `setup` never blocks in a pipeline. - `vaults3 help` and a usage message that names the subcommands. ##### Internal - Fixed a data race in the transport mux test helper, which set the handshake timeout after the accept loop that reads it had already started. The shipped binary never wrote that field after construction, so no released build was affected, but `go test -race` failed. It is now a constructor parameter. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).

renovate-bot added 1 commit 2026-08-22 22:02:13 +02:00

Update eniz1806/vaults3 Docker tag to v4.4.55 f7145e4516

renovate-bot scheduled this pull request to auto merge when all checks succeed 2026-08-22 22:02:13 +02:00

renovate-bot merged commit edc4372149 into main

2026-08-22 22:02:15 +02:00

renovate-bot deleted branch renovate/eniz1806-vaults3-4.x

2026-08-22 22:02:15 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: arnoutvw/compose-files#355