AdminBolt 1.1.0: From a Single Panel to a Whole Fleet

Every hosting business hits the same wall. The first server is easy. The fifth is a habit. Somewhere around the tenth, "managing your infrastructure" has quietly become "logging into ten panels," and the work that used to take minutes now means remembering which box does what.

AdminBolt 1.1.0 is the release that takes down that wall. Up to now, AdminBolt has been an excellent single-server panel. With 1.1.0 it becomes a platform for running a fleet, many servers managed as one system, with the tooling to move customers between them and keep DNS coherent across the whole estate. If 1.0.x was about making one server great, 1.1.0 is about making twenty servers feel like one.

Here's what that actually looks like in day-to-day operations.

Your whole fleet behind one login

The centerpiece is hub mode. You promote one panel to act as a hub, and from there you bring other AdminBolt servers in as nodes, either deployed fresh or connected from an existing install. Each node stays a complete, independent panel; the hub just gives you a layer above them.

What that buys you is simple to describe and surprisingly hard to live without once you have it: one dashboard that lists every server, continuous health across the fleet so problems surface before your customers report them, and one-click access straight into any node. The hub also tracks which version each node runs, so you can see drift at a glance and avoid risky cross-version operations. The hub/node split is enforced by design: a server is either a hub or a node, never accidentally both.

It's the difference between operating a fleet and babysitting a pile of servers.

Moving customers without the dread

Account moves used to be the job nobody volunteered for. 1.1.0 makes migration a first-class, hub-driven operation: pick an account, pick a destination node, and AdminBolt rebuilds the account on the target (the system user, web and PHP setup, databases, mail, FTP, cron, SSL and the rest), then cuts DNS over automatically. You can keep existing passwords so services don't break, run pre-flight checks before anything moves, and watch each stage report live status. The source copy is always kept until you say otherwise.

One honest boundary worth stating plainly: this moves the account's configuration, not the bytes on disk. Site files, database contents and mailboxes are out of scope for this release, so plan the data copy as its own step.

DNS that keeps up with the fleet

Run more than one server and DNS turns into the quiet source of half your incidents. 1.1.0 introduces clustered DNS: a single view that pulls together zones from your AdminBolt nodes and from external panels you already run, cPanel, DirectAdmin and Plesk, without ever writing back to those external systems. Add standalone secondary nameservers to spread resolution, and when the same domain briefly lives in two places during a migration, pin the authoritative source so nothing misroutes. It's white-label, consistent DNS across a mixed estate, managed from one place.

The details that make multi-server quietly work

A handful of smaller changes exist purely so a fleet behaves like one system. Automatic mail autodiscovery means clients configure themselves once a domain is set up. Central webmail routing points each mailbox at the right node automatically. And opt-in Slack or Discord notifications tell you about the things that actually matter (a node going offline, a migration finishing, a DNS conflict), on state changes only, without drowning you in noise.

Fixes worth calling out

A release this large also clears a stack of bugs, and a few are worth naming because you'd have felt them. Email forwarders with several destinations now deliver to every recipient instead of just the first. Your branding logo shows up everywhere it should again, including the client, reseller and installation panels, which matters the moment you run white-label. Imported accounts report their real disk usage instead of a flat zero. DNS SRV records are now created correctly on new domains, which is also what makes the mail autodiscovery above just work. And multi-server health is steadier across the board: nodes no longer flap on and off, and the panel stops hammering node APIs under load. The in-panel changelog has the complete list, down to the smaller cron and DNS housekeeping.

Upgrading is one click

If you're on a recent 1.0.x, upgrading is done entirely from the panel. Open the Updates screen in the admin UI and apply 1.1.0, the one-click updater shows live progress, runs the version-specific upgrade steps for you, and reports when it's done. No terminal, no manual package commands. As always, take a backup first (the built-in backup or JetBackup both work), and expect only a brief interruption on a typical VPS.

Single-server users lose nothing: hub mode and node mode are entirely opt-in, and a standalone panel keeps working exactly as it did.

Where this goes next

1.1.0 lays the foundation for fleet operations, central management, migration and clustered DNS. The natural next steps build on top of it, and the public roadmap is the place to follow along.

Running more than one server, or about to? This is the upgrade that changes how that feels. Tell us how it goes on Discord, the community forum, or via the contact form.