Packaging

How release builds of Bitcoin Server (bs) are packaged for package managers, as a container image, and as apps for node platforms. Packages contain the signed builds of a release (Release builds).

1. Packages#

2. Variants#

The deb packages, the Windows installers and the Docker image each hold two variants of bs and the selector, which reports the processor's features. The first variant whose required features the processor has is used, at install for a deb or an installer, and at each start for the image; the install or start fails if neither is supported.

Every arm64 processor has NEON (Advanced SIMD is required by ARMv8-A), so the arm64 baseline is not checked.

The Homebrew formula holds one build per architecture, with no selector. Both builds require macOS 13.3, and every Mac that runs it has the features of its build: every Apple silicon processor, and every Intel processor of a Mac supported by macOS 13 (2017 and later).

3. Package Release#

package-release.yml, in libbitcoin-server, is run by hand with a release tag. Each job that takes builds from the release downloads them with their signatures, and fails unless every signature verifies. Its jobs:

4. Distribution#

The container image is pushed to the GitHub container registry by the docker job. Every other package is published as an asset of the release, and reaches its distribution repository from there:

The formula, manifests and Umbrel app refer to the release's download URLs, so each is submitted once the release is published.

5. Containers#

5.1 Docker#

The image runs bs as user and group 1000, with its data in the /data volume and its configuration in /data/bs.cfg. On first start, when /data/bs.cfg does not exist, the image copies its default configuration there:

[database]
path = bitcoin

[log]
path = log

[admin]
bind = 0.0.0.0:8080
connections = 10

[native]
bind = 0.0.0.0:8180
connections = 10

docker stop sends SIGTERM, which starts closing the store. A syncing node can take longer to close than the 10-second default timeout, after which Docker kills the node, so run the container with --stop-timeout 600.

5.2 Umbrel#

The app runs the image, pinned by digest, with its data under the app's data/bs directory.

Backups exclude the store (bitcoin/) and the logs (log/). The stop grace period is 5 minutes 30 seconds, for the store to close.

5.3 StartOS#

The package runs the image, pinned by digest, on x86_64 and aarch64.

StartOS serves the web interfaces over HTTPS, with its own certificate authority. Its health check is that the admin port is listening. The stop timeout is 5 minutes, and backups exclude bitcoin/ and log/.

The package requires 15 GiB of RAM as StartOS reports it, which admits a 16 GB machine (StartOS compares against the total the kernel reports, about 2.3% under the installed RAM). StartOS does not offer the package on a smaller machine.