adminbolt 1.0.4 is now live. The release went out on June 8, 2026, and is available in the in-panel changelog as the current version. This post walks through what shipped, why it matters, and what to check before you upgrade.
The headline of 1.0.4 is automation. Where 1.0.2 was about product surface (the WordPress client UI and the AI Agent Hub), 1.0.4 is about the plumbing underneath: a proper Client REST API, a rebuilt update pipeline, and a structured upgrade framework that makes future releases safer to apply.
Headline change: the Client REST API
The biggest addition in 1.0.4 is a full Client REST API. It opens programmatic access to nearly all the hosting management capabilities that were previously only reachable through the control panel UI.
Covered resources include:
- Databases and database users
- Domains and subdomains
- Email accounts and forwarders
- FTP accounts
- DNS records
- SSL certificates
- Security tools
- Logs
- WordPress installations
A few design decisions are worth calling out, because they shape how you build on top of it:
- Automatic account scoping. Each API key is bound to a hosting account, so a client key can only ever see and touch that account's resources. There is no way to reach across accounts with a client credential.
- Standardized rate limiting. Every endpoint shares a consistent rate-limit contract, so you get predictable behavior under load instead of per-endpoint surprises.
- Cleaner responses and better docs. Response shapes were normalized and the reference documentation was rewritten to match.
Architecturally, this also tidied up the codebase: the old internal "Hub" API naming was renamed to "Client" throughout, while keeping the existing feature-flag behavior intact. The result is a clean separation between the administrative API and the client-facing API, with the client surface fully isolated and scoped per account.
If you have been automating provisioning, billing hooks, or customer self-service against the panel UI, this is the release that lets you move that integration onto a stable, documented API. It pairs naturally with the patterns described in Best Hosting Panel for API Automation and the API-first architecture write-up.
Redesigned system updates
The in-panel update experience was rebuilt from the ground up. The goal was to make applying an update feel like a single, observable action instead of a black box.
What changed:
- One-click install. Updates apply from a single button.
- Clearer status reporting. The UI now shows exactly what state the update is in rather than a generic spinner.
- Detailed error handling. When something fails, you see what failed and why.
- Live log viewing. You can watch the update log stream in real time as it runs.
- Automatic page refresh on completion, plus dashboard notifications when an update finishes.
Alongside the UI work, the release channels were simplified. The development and unstable channels were removed in favor of a stable-release-only strategy. Fewer channels means fewer ways to end up on an untested build in production.
Smarter update discovery
Under the hood, how adminbolt finds out about updates changed completely. The platform moved away from scraping-based discovery to package-manager-native mechanisms for both detecting new versions and retrieving changelogs.
The practical effects:
- More accurate version checks. Versions are read from the package manager, not inferred.
- Heavy caching for performance. Update information is cached aggressively, so the dashboard stays responsive instead of hitting external sources on every load.
- Unified reporting. Update status now covers both the panel itself and the installed modules in one place.
- Several modules moved to fully managed package upgrades, so they update through the same mechanism as the core panel.
New upgrade framework
1.0.4 introduces a structured upgrade framework for running version-specific migration and maintenance tasks during an upgrade. This is the piece that makes future releases safer.
The framework provides:
- Automatic discovery of the upgrade steps that apply to your current version.
- Version gating, so a step only runs for the versions it targets.
- Tracking, so each step's completion is recorded and not repeated.
- Retry capabilities, so a transient failure can be re-run without redoing the whole upgrade.
- Support for module-specific upgrade requirements, not just core panel steps.
In day-to-day terms: when you upgrade, adminbolt now figures out exactly which migration tasks your installation needs, runs them in order, records what succeeded, and lets you retry anything that did not. This is what the bolt-cli run-upgrade-steps command in the upgrade flow below drives.
Bug fixes and reliability
1.0.4 also folds in a round of reliability fixes:
- FTP account creation stability improvements.
- More efficient phpMyAdmin SSO synchronization.
- Multiple .htaccess issue resolutions.
- Enhanced hostname SSL management.
- Correct dashboard changelog navigation.
- Better handling of hidden API secrets in administrative forms, so sensitive values are not exposed in the UI.
Backwards compatibility
There are no breaking changes documented for 1.0.4. The internal "Hub" to "Client" API rename preserves existing feature-flag functionality, so panels upgrading from 1.0.3 keep working as before. The new Client REST API is additive: it sits alongside the existing administrative API rather than replacing it.
How to install
For a new server, install adminbolt from the official installer:
curl -sSL https://get.adminbolt.com/install.sh | bash
Or start from the guided page at get.adminbolt.com. If you are deploying on a cloud provider, the one-click Marketplace flows still apply, for example the Vultr deployment guide.
How to upgrade from 1.0.3
As always, back up before upgrading. The panel has built-in backup, and if you run JetBackup use that. Then apply the update from the admin panel's redesigned update screen, or run it from the command line:
dnf clean all
dnf upgrade bolt-panel
dnf upgrade bolt-agent
bolt-cli run-upgrade-steps --no-interaction
The final command runs the new upgrade framework: it discovers the version-specific migration steps your install needs, applies them, and tracks the results. Expect under five minutes of panel service interruption on a typical VPS. The detailed in-panel changelog lives at /admin/change-log, with the full version history available from the version selector.
What's next
With 1.0.4, the automation foundation is in place: a documented Client REST API, a rebuilt update pipeline, and an upgrade framework that future releases can hang migration logic on. The next cycle continues down the integrations track on the public roadmap.
Feedback on 1.0.4 is welcome on the Discord, the community forum, or via the contact form. Bug reports go to the same channels.