AdminBolt 1.3.0: IMAP Mailbox Import, Reseller Resource Limits and 18 New Languages
The 1.2 line was about the platform under your sites: CloudLinux, LiteSpeed and PHP engines that stay out of each other's way. AdminBolt 1.3.0 turns back to the panel itself and removes friction in four places at once. Mail now moves in from any IMAP server. Resellers get the resource controls they used to ask you for. The interface speaks 18 more languages. SSL for hosting domains renews itself. And underneath all of that sits a long security hardening pass that touches the panel, bolt-agent and the bundled modules.
Here is what actually changes day to day.
Bring your mail with you
Moving a website between hosts is a solved problem. Moving ten years of email is where migrations stall. 1.3.0 takes that on directly: every mailbox in the client panel gains an Import email (IMAP) action that pulls messages from an external IMAP server into the existing mailbox.
It is built like a migration tool, not a checkbox. You enter the source server details, test the connection before anything runs and then watch live progress as messages come across. Because it works per mailbox and lands in an existing mailbox, you can move one user at a time, or hand it to clients and let them bring their own mail with them.
For anyone switching a customer over from another host, this closes the last gap: the site, the databases and now the inbox.
Resellers get real resource limits
1.2.0 gave hosting plans a Resource Limits tab. 1.2.2 added per-account bandwidth overrides. 1.3.0 hands the same kind of lever to resellers: the accounts a reseller manages now carry Resource Limits the reseller can set themselves.
If you sell through resellers, this is one less reason for them to open tickets with you. The reseller shapes limits on their own accounts and the panel enforces them, the way it already does for admins.
The panel speaks your language
Two changes land together here. First, a sweep across the entire panel wrapped the remaining hardcoded interface strings for translation, so switching language now actually covers what users see. Second, 18 new languages ship with the panel, including Brazilian Portuguese and Japanese.
If you host customers who do not work in English, the panel stops being the one tool in their day that refuses to meet them halfway.
SSL that takes care of itself
Certificates for hosting domains are now issued and renewed automatically: bolt-cli setup-cron-jobs schedules a recurring bolt-cli run-auto-ssl, so a domain that needs a certificate gets one and a certificate close to expiry is renewed, without anyone remembering to check.
Mail certificates got attention too. Mail hostnames (mail, autoconfig, autodiscover) are issued as their own certificate group, mail SNI now serves the certificate the agent actually issued and issuing a certificate no longer re-runs the full mail auto-discovery configuration every time. Subdomain certificates also stop demanding mail hostnames they never needed. The net effect is fewer surprise validation failures and less repeated work on busy servers.
A long, quiet security pass
A good part of the 1.3.0 changelog is security hardening, and most of it is invisible by design. The short version of what changed: FTP passwords are now stored as one-way hashes and FTP credential files sit behind restricted permissions. Roundcube data, mail database files and hosting account export backups are locked down to restricted ownership and permissions, on new installs and on upgrade. Softaculous now opens only for users signed in to the panel. SSH keys and mailing list names are validated on input, agent logs mask sensitive values and changing a password through the local API requires the current password first.
One hardening item doubles as a feature: a new bolt-cli set-admin-password command lets unattended installations set the admin password safely, which makes scripted provisioning cleaner.
None of this asks anything of you. It is the kind of work you only notice if you go looking, which is the point.
Reliability and PHP details
A few changes exist purely to make servers calmer. The agent's /health endpoint now returns just status and install state, with detailed CPU and RAM metrics moved to /health/details, so the Services page polling every ten seconds stops costing measurable load. Server metrics are read through bolt-agent REST endpoints instead of root shell commands. Fully used plan allocations no longer raise critical alerts for what is arguably a success state, and the ModSecurity audit log viewer now works end to end.
On the PHP side, saving disable_functions or disable_classes now restarts PHP-FPM instead of reloading it, so system-level settings take effect the moment you save them. And domain imports on LiteSpeed servers no longer pick the wrong PHP engine, because the version resolver is now aware of which web server it is resolving for.
Fixes worth naming
Three more you would have felt: MySQL user creation now accepts a much wider range of complex passwords, the update modal no longer stays open forever after an update completes and uninstalling mod_passenger now cleanly removes passenger_module from the Apache configuration.
Upgrading is one click
Upgrading is done entirely from the panel. Open the Updates screen in the admin UI and apply 1.3.0. The one-click updater shows live progress, runs the version-specific steps for you and reports when it is done. Take a backup first out of habit and expect only a brief interruption on a typical VPS. Single-server and multi-server panels pick the release up the same way.
Tell us how it goes
That is 1.3.0: mail that moves in, resellers who can help themselves, a panel that speaks your customers' language and a security posture that got quietly stricter. Tell us how it lands on Discord, the community forum or through the contact form.