* docs: retitle the Docker section to match what it does
The section was called "Build Docker Image" but was almost entirely
about running the published one, so anyone scanning for how to try
Buckit in a container skipped past it.
Retitle to "Run with Docker", lead with the run commands, and demote
image building to a closing note. Also name both registries and the
advice to pin a tag in production.
* docs: make Quickstart reach a running server in one command
Quickstart opened with `make build`, so the first runnable thing in the
README required installing Go and compiling. Lead with the published
container image instead.
Fold Distributed Server Mode in as a subsection so the single-node and
cluster commands sit together. The cluster one-liner is the more
striking of the two and was previously buried under prose, split across
continuation lines, and immediately followed by advice to use bm web
instead. It now stands on its own line with an explanation of what it
describes.
* docs: quickstart without requiring Docker
Leading with a container image assumed a runtime the reader may not
have. The binary installer shipped in the last release needs neither a
toolchain nor Docker, so use that instead and keep the container path as
one of the alternatives listed beneath it.
* docs: split quickstart into download and run steps
* docs: walk the quickstart through to an uploaded file
The quickstart stopped at a running process, which is not the thing a
reader is trying to confirm. Continue through signing in to the console
and uploading an object with bm, so the first session ends with data in
object storage rather than a server listening on a port.
* docs: tighten the quickstart and end it in the console
Cut the throat-clearing: the "no toolchain required" claim, the
description of what the installer does, and the pointers to other
install methods, which are one heading away.
Swap the last two steps. Creating a bucket and uploading a file, then
opening the console to find them there, gives the sequence a payoff. The
previous order treated the console and the CLI as interchangeable
alternatives, which ended the quickstart on a shrug.
* docs: give quickstart steps their own headings
Bold-inline step labels ran into the text that followed them, so the
four steps read as one block. Promote them to h3 so each gets real
separation and an anchor, and move the platform variants and the bm
install note into the code blocks as comments, where a reader can copy
the line that applies to them instead of reading a sentence about it.
The cluster one-liner becomes its own section rather than a fifth
sibling heading under Quickstart, where it read as step 5.
* docs: restore the learning-purposes note on the quickstart
* docs: reword the quickstart note
* docs: state what the quickstart walks through
* docs: put the quickstart note above the intro line
* docs: point the quickstart note at the guided deployment wizard
* docs: comment each command in the quickstart upload step
* docs: note the PATH line is conditional
* docs: name the data directory in the quickstart
* docs: name the CLI in the step 3 heading
* docs: say web browser rather than console in step 4
* docs: point at the Object Browser menu in step 4
* docs: give the Windows bm install its own line
* docs: comment out the Windows bm install so the block pastes cleanly
* docs: restore the Distributed Server Mode heading
* docs: restore the original Distributed Server Mode section
* docs: keep the rewritten distributed section under its original heading
* docs: restore Distributed Server Mode to its original form
* docs: point distributed deployments at the guided wizard
* docs: simplify what the wizard handles
* docs: simplify the install section blurbs
* docs: drop the Linux install subsections from Install Buckit
Installing and deploying for real takes more than a one-line curl, and
the Deployment Guide covers it properly. The quickstart already shows
the download command for anyone who just wants to try the server, so
these two sections offered a third telling of the same thing at a level
of detail that suits neither audience.
Leaves Install Buckit as a pointer to the guide, plus building from
source, which is the part only this repository can document.
* docs: contrast the deployment guide with building from source
* docs: promote Build From Source to a top-level section
* docs: drop the build commands that do not work
`go install github.com/buckit-io/buckit@latest` cannot succeed. Go
refuses `pkg@version` installs for any module carrying a replace
directive, and go.mod:7 has one for go-openapi/testify. The line was
inherited from MinIO's README, where it works because their go.mod has
none. Running it here fails outright.
The manual `go build -tags kqueue -trimpath --ldflags ...` line was the
Makefile's build target spelled out, so it only offered a way to get the
invocation subtly wrong.
Leaves the one path that works, verified from a clean clone.
* docs: restore go install now that it works
Removing it was correct at the time: the go.mod replace directive made
`go install pkg@version` fail outright. That directive is gone, and the
command has been verified against the published module.
Note the version caveat -- go install skips the Makefile's gen-ldflags
step, so the binary cannot report which release it came from.
* docs: use the Docker Hub image in the run commands
Docker Hub is Docker's default registry, so buckitio/buckit needs no
prefix at all, and it is where most people expect to find an image. This
also matches the compose example in the migration blog post.
Name both registries explicitly in the note beneath, since GHCR is not
subject to Docker Hub's anonymous pull limits and is the better choice
from CI.
* docs: drop the custom-image aside from Run with Docker
* docs: name the bm section as the CLI
* docs: add a Buckit Manager Web screenshot
The section described a web UI without showing it. Use the cluster view
from the website's media assets, which covers four of the five things the
section lists: cluster health, nodes, pools and drives, and host
operations.
Cropped off the decorative video-poster frame and the burned-in caption
so it reads as a screenshot rather than a video thumbnail. Placed
centred under the intro, matching the console GIF at the top of the file.
* docs: fold the bm install blocks into one
Two blocks with prose labels became one with per-command comments,
matching how the quickstart presents the same install. The Windows line
is commented out so the block still pastes cleanly on Linux and macOS,
where the trailing `bm --help` runs either way.
* docs: add the PATH line the bm install block was missing
`bm --help` fails with "bm: not found" straight after install: bm lands
in ~/.local/bin and its installer only prints a PATH hint rather than
applying one. The two blocks this replaced had the same gap.
Verified by pasting the block verbatim with nothing added.
install-linux-binary.sh and install-mac.sh were 443 lines that differed
in three places: the OS check and architecture allowlist, the platform
token in the pointer URL and asset name, and clearing the macOS
quarantine attribute. The other ~190 lines were identical.
That duplication already cost something. Hardening the installers meant
applying five fixes twice, by hand, in parallel -- pin-bypass path
traversal, pipeline masking, digest normalisation, directory
destination, and the cross-origin digest check. The next fix would have
had the same shape, and eventually one would land in only one file.
Merge them into install-binary.sh, which detects Linux or macOS and
validates the architecture against what is published for that platform:
Linux ships amd64 and arm64, macOS ships Apple Silicon only.
The release workflow publishes it under the old names as well, so URLs
already in the wild, in the docs, and in the blog post keep working and
pick up the merged behaviour on every release. Nothing needs to change
on the reader's side, and there is no window where a documented command
404s.
Two benign consequences: install-mac.sh now also works on Linux and
install-linux-binary.sh on macOS, and error messages self-identify as
install-binary.sh whichever URL was fetched.
install-linux.sh downloads a native package and registers a systemd
service, which is the wrong shape for deployments that run the server
binary directly -- a hand-run process, a non-systemd supervisor, or a
MinIO deployment being migrated in place.
Add a Linux counterpart to install-mac.sh that fetches only the binary:
resolve the current release from the gh-pages pointer, download the
matching asset, verify its SHA-256, chmod it, and leave ./buckit in the
working directory. It does not touch PATH and does not install a service.
The checksum is verified against both the release-host .sha256sum and the
digest published in the gh-pages pointer, and the two must agree. The
binary and its adjacent checksum share an origin, so that digest alone
only proves the transfer was not corrupted; the pointer is served from a
different origin and turns the check into something an attacker must
defeat in two places. A pinned BUCKIT_VERSION skips the cross-check,
since the pointer only ever describes the latest release.
Publish the script to gh-pages alongside the others, and advertise it in
the README and the generated release-notes install table.
Add install-mac.sh (downloads the Apple Silicon binary, verifies SHA-256,
clears the macOS quarantine attr, prints the move-to-PATH command) and
install-windows.ps1 (downloads the .exe, verifies SHA-256, prints the
move-to-PATH command). Both write to a predictable filename (buckit /
buckit.exe) and use the same atomic temp-then-move + checksum-gate flow as
install-linux.sh.
Publish both to gh-pages in the release workflow, and point install-linux.sh's
non-Linux error at the new scripts.
Add packaging/install-rpm.sh, a POSIX sh helper served from gh-pages that
detects the host package manager (dnf/yum/zypper, apt/apt-get/dpkg, or apk),
downloads the matching .rpm/.deb/.apk for the latest stable release, verifies
its published SHA-256 checksum, and prints the install command to run. It does
not invoke the package manager itself.
Wire the update-gh-pages release job to check out source and publish the
script to pages/install-rpm.sh so it ships at
https://buckit-io.github.io/buckit/install-rpm.sh during a normal release.
- update-gh-pages: remove zip_binary/publish_package/trim_archives; only write
4 buckit.sha256sum files for self-update; generate release/index.html with
per-platform download links and archives/index.html from GitHub API listing
all stable releases; add force_orphan to prevent git history bloat
- gh-pages-index.yml: skip server/buckit/release and server/buckit/archives
so the auto-indexer does not overwrite the custom HTML pages
Binaries exceed GitHub's 100MB git push limit so they cannot be stored
in the gh-pages branch. Two changes to fix this:
- release.yml: stop copying binaries/minisig to gh-pages; write
buckit.sha256sum files with the release tag embedded in the filename
field (e.g. 'buckit.RELEASE.xxx') so the Go code can construct the
versioned GitHub Releases URL.
- update.go / admin-handlers.go: getBinaryURL now constructs a
github.com/releases/download URL when the checksum source is github.io
and the sha256sum filename contains a release tag. Fixes two dead-code
bugs in both admin handlers where 'if updateURL == ""' was always
false after updateURL had already been set.
The previous packaging step used minio/pkger, which is hardcoded for
MinIO's portfolio: its nfpm template only attaches a systemd unit when
the binary name matches "minio", "aistor", or "sidekick". Invoking it
with --appName buckit silently dropped the unit (and the maintainer/
homepage fields stayed MinIO-branded) — the published .rpm/.deb shipped
only /usr/local/bin/buckit with no service definition.
Switch to nfpm directly, driven by a config in packaging/nfpm.yaml that
we own. The packages now contain:
/usr/local/bin/buckit
/lib/systemd/system/buckit.service (Type=notify, LimitNOFILE=1048576,
OOMScoreAdjust=-1000, etc.)
A postinstall script creates the buckit system user/group idempotently;
preremove stops the service; postremove reloads systemd but deliberately
leaves the user in place to avoid orphaning data on attached storage.
The unit is modeled on MinIO's production unit but reads
EnvironmentFile=-/etc/default/minio (leading - = optional), keeping
fresh buckit nodes byte-compatible with the env file MinIO already
ships, so the manager's in-place migration story works without any
config translation.
Verified locally by building rpm/deb/apk against the published
RELEASE.2026-05-11T17-20-40Z binary and inspecting the output.
- Rename all 'minio server' references to './buckit server'
- Update default credentials from minioadmin to buckitadmin
- Add 'pkill -9 buckit' to all test cleanup functions
- Pin workflow Go version to 1.25.10
- Update vulnerable Go modules
- Fix resiliency tests: restore docker compose --wait, add
MC_HOST_local env var, fix induce_bitrot_for_xlmeta typo
- Update mint docker-compose images to buckit
- Update IAM integration and root lockdown test scripts
This commit removes FIPS 140-2 related code for the following
reasons:
- FIPS 140-2 is a compliance, not a security requirement. Being
FIPS 140-2 compliant has no security implication on its own.
From a tech. perspetive, a FIPS 140-2 compliant implementation
is not necessarily secure and a non-FIPS 140-2 compliant implementation
is not necessarily insecure. It depends on the concret design and
crypto primitives/constructions used.
- The boringcrypto branch used to achieve FIPS 140-2 compliance was never
officially supported by the Go team and is now in maintainance mode.
It is replaced by a built-in FIPS 140-3 module. It will be removed
eventually. Ref: https://github.com/golang/go/issues/69536
- FIPS 140-2 modules are no longer re-certified after Sep. 2026.
Ref: https://csrc.nist.gov/projects/cryptographic-module-validation-program
Signed-off-by: Andreas Auernhammer <github@aead.dev>
Golang http.Server will call SetReadDeadline overwriting the previous
deadline configuration set after a new connection Accept in the custom
listener code. Therefore, --idle-timeout was not correctly respected.
Make http.Server read/write timeout similar to --idle-timeout.
This PR fixes a regression introduced in https://github.com/minio/minio/pull/19797
by restoring the healing ability of transitioned objects
Bonus: support for transitioned objects to carry original
The object name is for future reverse lookups if necessary.
Also fix parity calculation for tiered objects to n/2 for n/2 == (parity)
abuckit