Binaries, PHAR, Docker

Installation

Install the latest stable binary on 64-bit x86 Linux or Apple silicon macOS with:

SHELL
curl -fsSL https://raw.githubusercontent.com/yiipress/engine/master/install.sh | sh

On 64-bit x86 Windows, run in PowerShell:

POWERSHELL
irm https://raw.githubusercontent.com/yiipress/engine/master/install.ps1 | iex

The installers download the latest release archive and SHA256SUMS, verify the archive, and atomically install the executable.
The shell installer prints the exact resolved release version before downloading its archive.
The installed binary reports that same release tag with yiipress --version.
Development and nightly artifacts report the full commit SHA from which they were built, even when cached Composer metadata contains an older stable version.
The shell installer uses /usr/local/bin/yiipress; the PowerShell installer uses the current user's local application directory
and adds it to the user PATH. Re-run the same command to update an existing installation. To use another directory or a fixed
release, set environment variables before invoking the installer. For example, with the shell installer:

SHELL
curl -fsSL https://raw.githubusercontent.com/yiipress/engine/master/install.sh | YIIPRESS_INSTALL_DIR="$HOME/.local/bin" sh
curl -fsSL https://raw.githubusercontent.com/yiipress/engine/master/install.sh | YIIPRESS_VERSION=X.Y.Z sh
curl -fsSL https://raw.githubusercontent.com/yiipress/engine/master/install.sh | YIIPRESS_VERSION=nightly sh

Or, with the PowerShell installer:

POWERSHELL
$env:YIIPRESS_VERSION = "nightly"
irm https://raw.githubusercontent.com/yiipress/engine/master/install.ps1 | iex

YIIPRESS_VERSION=nightly resolves the newest immutable nightly prerelease through the GitHub releases API. It does not require
jq or GitHub CLI. Both installers inspect up to ten release pages and use the first prerelease whose tag matches the immutable
nightly-<run>-<attempt>-<sha> format. Nightly builds contain unreleased changes and are intended for preview and testing.

YiiPress can be packaged as reproducible artifacts:

BASH
make package

The command builds the Linux static executable and writes it to dist/linux-amd64/:

  • yiipress — static Linux executable built with static-php-cli micro SAPI and the YiiPress PHAR embedded.

Additional package targets are available:

BASH
make package-phar
make package-linux
make package-macos
make package-windows
make package-distroless
make package-distroless-push
  • make package-linux is the explicit Linux static executable target. Set PACKAGE_PLATFORM=linux/amd64 and PACKAGE_LINUX_DIST=... to override the defaults.
  • make package-macos builds the native macOS static executable into dist/macos-<arch>/yiipress with the shell packaging script. It is intended for macOS hosts with PHP, Composer, Rust, and the Xcode command-line build toolchain available. PACKAGE_MACOS_ARCH must match the host architecture (arm64 or amd64); set PACKAGE_MACOS_DIST=... to override the output directory. The intermediate PHAR used by static-php-cli is kept under runtime/package-macos/ and is not part of the macOS artifact.
  • make package-windows builds only dist/windows-amd64/yiipress.exe with the PowerShell packaging script. It is intended for Windows hosts with PowerShell 7 (pwsh), PHP, Composer, Rust, and the Visual Studio C++ toolchain available. The intermediate PHAR used by static-php-cli is kept under runtime/package-windows/ and is not part of the Windows artifact.
  • make package-phar builds dist/phar/yiipress.phar separately for environments that already have PHP 8.5 and required extensions. Set PACKAGE_PHAR_DIST=... to override the output directory.
  • make package-distroless builds a local ${IMAGE}-static:${IMAGE_TAG} image from the distroless Docker target. The image copies only the static yiipress binary into a distroless base and runs it as the entrypoint.
  • make package-distroless-push builds and pushes the same image.

Dockerfiles

docker/Dockerfile is the source build Dockerfile. It contains development and production image targets, PHAR packaging targets, and the expensive static-php-cli Linux binary build targets used by make package* and CI packaging jobs.

docker/Dockerfile.distroless-binary is the final image assembly Dockerfile for GitHub Actions. It does not build PHP, Composer dependencies, the PHAR, or static-php-cli. It copies an already-built dist/linux-amd64/yiipress binary into the distroless base image, so nightly and release container images reuse the Linux binary artifact instead of rebuilding it.

The PHAR builder copies only runtime inputs into the build stage: config/, src/, themes/, yii, Composer metadata, and the PHAR build scripts. Dependencies are installed with --no-dev inside that stage before the PHAR is assembled. YiiPress has no public PHP front controller: yiipress serve creates the preview HTTP application internally, while production output consists only of generated static files.

Comments and redundant whitespace are stripped from packaged PHP files while preserving line numbers, strings, executable code, and dependency PHPDoc that is read through reflection at runtime. This keeps the standalone PHAR and embedded static-binary PHAR smaller without changing stack-trace line numbers. Benchmark fixtures, IDE metadata, standalone dependency commands, Composer-only configuration builders, unavailable Yii Debug integrations, Composer's installed.json, VCS placeholders, and non-runtime type stubs are omitted because packaged commands do not need them. Runtime configuration metadata, preview web configuration, supported environment configuration, framework command definitions inherited by Yii Console, error templates, interactive-input helpers, and shell-completion resources remain packaged.
With the current dependency lock, pruning these non-runtime files removes 19,806 bytes from the gzip-compressed PHAR. The static executable embeds that same PHAR, so it receives the same byte reduction; the exact saving may change when dependencies are updated.
Packaged PHAR entries are gzip-compressed before the archive is finalized. The static binary appends that same PHAR to the micro SAPI executable, so PHAR compression reduces both the standalone PHAR and the Linux, macOS, and Windows static executables.
The static executable includes ext-highlighter, so syntax highlighting does not need FFI or an external shared library. It intentionally omits ext-openssl; self-update uses an available host downloader instead. serve uses ReactPHP stream sockets, serves built files and live reload SSE in the server loop, keeps one shared live reload watcher per server process, and does not require PHP's native sockets extension. On POSIX platforms with PCNTL and signal support, serve can prefork worker processes; Windows static binaries run a single server process.
Relative content-dir, output-dir, new, clean, serve, and import paths are resolved from the directory where you run yiipress, not from the packaged executable location.
PHAR and static binary runs keep build cache and incremental manifests under the OS temp directory, keyed by the current project directory, instead of writing to runtime/ in the site checkout. yiipress clean removes that packaged cache as well as the configured output directory.

Packaged installations update themselves from release metadata and verify downloads with SHA-256 checksums:

SHELL
yiipress self-update
yiipress self-update --nightly

The updater prefers curl, then uses the PHP HTTPS wrapper when the host PHP provides it,
PowerShell on Windows, or wget on Linux and macOS. If none is available, install curl
and retry. Distroless containers should be updated by pulling a newer image rather than by
running self-update inside the container.

The first command installs the latest stable release. The second installs the newest nightly prerelease containing a compatible package. Static binaries identify their outer executable through the micro SAPI runtime. The verified replacement is staged beside the installed package and activated only after normal command shutdown, avoiding stale PHAR metadata while the old package is still running. If a nightly package is unavailable for the current installation type or platform, the command reports that clearly instead of selecting an incompatible asset. Composer/source checkouts must be updated with Composer instead.

GitHub Actions builds the same outputs in the Package Static Builds workflow. Commits to master publish separate nightly PHAR, Linux, macOS, and Windows workflow artifacts, create immutable GitHub prereleases tagged as nightly-<run>-<attempt>-<sha> with the PHAR and all three platform packages plus checksums, and push the distroless image as ghcr.io/<owner>/<repo>-static:nightly plus a commit-specific nightly-<sha> tag. The reusable build action resolves version: nightly to the newest matching nightly prerelease.

The Run Tests workflow runs PHPUnit in the Linux Docker test image and builds the native Windows and macOS binaries. Both platform jobs exercise a complete site lifecycle with the packaged executable: initialize a project, create content, build it, check generated links, verify output, and clean the build.

Version tags run the Release workflow. It builds the PHAR, Linux, macOS, and Windows binaries, pushes only the binary-based distroless image as ghcr.io/<owner>/<repo>-static:<tag> plus semver aliases, then creates a draft GitHub release, attaches all binaries and SHA256SUMS, writes release notes from commits with their authors, and publishes the release. The Linux binary and PHAR come from the same static-package build, and the release image is assembled from the Linux binary artifact, so the expensive packaging build is not repeated for those outputs.