Updates
Batoi Press checks a public stable manifest to determine whether a newer stable version is available. The admin update screen separates routine version checks from higher-risk actions such as package staging, applying updates, and restoring backups.
Stable Manifest
The stable manifest is published at:
https://www.batoi.com/pub/press/latest.jsonThe manifest includes version, release date, package URL, checksum, minimum PHP version, GitHub tag, version notes URL, and Ed25519 trust metadata for signed release enforcement.
Update Safety
- Create a ZIP backup of config, content, theme, and app customizations.
- Verify package checksum when a SHA-256 value is provided.
- Require Ed25519-signed release indexes and signed package manifests for Batoi Press 2.0 and later.
- Verify the release public key identified by the manifest
key_id. - Use PHP cURL for remote update checks when
allow_url_fopenis disabled. If cURL is unavailable andallow_url_fopenis enabled, fall back to verified HTTPS streams with TLS peer and host verification enabled. - Validate uploaded ZIP packages before moving them into update staging.
- Diagnose HTML release pages, non-ZIP uploads, empty or incomplete archives, corrupt ZIPs, and missing ZipArchive support separately.
- Reject ZIP packages with unsafe entry paths before extraction.
- Extract a package into a staging directory.
- Require a release manifest inside the staged package.
- Apply only manifest-listed files to allowed runtime paths.
- Enable maintenance mode while applying staged files.
- Clear cache and run post-update health checks after replacement.
- Automatically restore from the pre-update backup when guarded apply or health checks fail.
- Restore files from a selected backup ZIP when needed.
The admin update screen displays version status, manifest URL, package staging, staged packages, backup creation, and rollback backups as separate operational sections. Restore actions should be treated as danger-zone operations because they replace live files.
Package Manifest
Release packages must include release.json, batoi-press-release.json, or manifest.json at the package root.
The package manifest must list installable files:
{
"version": "2.1.1",
"files": [
{
"path": "radpress/core/App.php",
"sha256": "..."
}
]
}Use source and target when the package path differs from the live install path. Batoi Press 2.0 and later packages must include a signed manifest in addition to ZIP and per-file SHA-256 verification. Standard root archives and one-folder desktop ZIP wrappers are supported; ambiguous package layouts and unsafe target collisions should be rejected.
Release Signing
Batoi Press 2.0 and later require signed release metadata:
https://www.batoi.com/pub/press/latest.json.sig
https://www.batoi.com/pub/press/release-public-keys.jsonCurrent public key id:
batoi-press-release-2026-01Allowed update targets are intentionally constrained to runtime files such as public entrypoints, assets, admin code, core code, docs, helpers, security, theme files, update code, UIF/AIF scaffolding, and radpress/config/update.json.
Batoi Press 2.1.1 keeps the Batoi UIF 3.0.0 bundle from the 2.1 line and adds a cURL-first update-check compatibility fix for installations where allow_url_fopen is disabled. Release verification must confirm the UIF compatibility aliases are present and match the bundled assets before publication.
Before publishing a release artifact, verify the generated package and manifests from the Batoi Press repo:
php tools/verify-release-artifacts.phpPublic Package Location
Release packages are published under:
https://www.batoi.com/pub/press/releases/