AdminBolt 1.8.0: Applications, PostgreSQL and Backups That Rebuild the Whole Server

1.7.0 was about the days when something goes wrong on a server you still have. 1.8.0 covers the day you do not have it any more, the day a customer wants to move a hundred accounts in from cPanel and the day someone asks whether you can host a Node.js app. It also reorganises the admin panel, so the first thing you will notice is that the menu got shorter.

Here is what changes day to day.

The admin panel got smaller

The admin menu is reorganised around subject areas. Fewer top-level entries, related screens gathered behind one destination with tabs and every old link redirected to its new home in one hop, so a bookmark or a link in your own runbook still lands where it should. Web Server and Email get dashboards of their own instead of being a pile of settings pages.

The other half of that work is what happens when something fails. A failed action anywhere in the panel now says why it failed and what to do next, under one correlation id you can quote in a support ticket. An action that half succeeded is reported as half succeeded rather than as a flat success, which is the failure mode that used to cost you an afternoon of guessing. A module operation you started re-attaches after a page reload. A stuck one no longer holds the page for other admins.

There is a new Logs Center: every log this server writes on one page, a tab per source, from web server access and error logs through mail delivery, spam filtering, webmail, request filtering, intrusion prevention, FTP and Linux security to the panel's own error log, the agents and the execution log. No more remembering which of six screens holds the log you want.

Installation also hands you a usable panel sooner. The installer sets up one PHP version and gets out of the way. The remaining PHP versions, SecureBox and SymLock install in the background afterwards, one at a time, with progress on the dashboard and every step in the execution log. A panel restart in the middle loses nothing.

Account and domain lists gain bulk actions: suspend, unsuspend, change plan and delete on accounts, delete and SSL issuance on domains. A bulk delete asks you to type a confirmation first. The result separates completed, completed with warnings, failed and skipped. Each row carries its next step.

Applications on CloudLinux

On a CloudLinux server, clients can now create Node.js, Python and Ruby applications from a wizard. The application ships with a starter page that serves immediately, so the first thing your customer sees is their app answering rather than a blank error. The application root is taken relative to the domain folder, each application gets its own log and a restart button in the panel. The whole thing is covered by the client REST API. Applications run on Apache and on OpenLiteSpeed. The panel decides which by what is serving the domain.

On the admin side there is a new Runtime Manager. It lists the runtime versions the repositories offer next to the ones this server already has, installs one version or all of them, reports what is running and says so plainly when the application server is missing rather than leaving you to work it out. It carries an admin REST API of its own.

One thing to be clear about: this is a CloudLinux feature. On AlmaLinux servers applications are not available.

CloudLinux servers also get their own settings section, with Resource Usage, PHP Selector, X-Ray, AccelerateWP and LVE Manager handed to the account through the hosting plan feature list.

PostgreSQL next to MariaDB

Install PostgreSQL from the Module Manager and hand it to accounts through a hosting plan feature, the same way every other capability is granted. Clients create databases and roles, manage remote access and open Adminer on a PostgreSQL database as one of the account's own roles. The client REST API covers all of it. PHP drivers are installed for every PHP family on the server, so the application your customer is deploying finds what it expects.

The parts that usually get forgotten are covered too. PostgreSQL data counts towards the account's disk usage, its databases ride along in account backups and are replayed on a full restore. A database or role renamed in the panel is reconciled on the server. Existing feature lists pick up the new feature on upgrade, so you are not editing thirty hosting plans by hand.

CloudLinux servers additionally get a MySQL Governor page that installs the Governor with the installer output shown as it runs and offers removal on its own page.

Moving accounts in

There is a new Migration > External Migrations wizard that moves accounts off a cPanel server without leaving the panel. You name the source host and approve its identity, then start the run either from the source or from this server.

The run outlives your browser. You can close the page, go home and open it the next morning: live status, the preflight, per-account state, the event log and the cleanup state of every credential the run held are all still there. You pick the accounts before the run starts and map each source hosting plan onto an existing plan, or let one be created from the package.

The DNS cutover is deliberately a separate approval and the panel states in plain words that AdminBolt does not touch your registrar or your external DNS, then names the accounts it left out. Every decision is recorded with the administrator, the IP and the timestamp. Notifications cover started, action required, stalled, failed and completed, so a run that needs you does not sit waiting silently. If you want the whole thing switched off, bolt-cli external-migration-disable ends every active run and releases what it holds, leaving already-imported accounts working.

When the whole box is gone

Per-account backups landed in 1.7.0. What was missing was the server itself: the configuration, the plans, the modules, the shape of the machine. The new Backups > Server Config surface takes all of that off-site to a backup destination, on a schedule you set, with its own retention and an optional passphrase you keep yourself.

Export DR keys hands you the bootstrap secrets. It asks the acting admin to confirm with a second factor first and records every export in the audit log. From those secrets alone, on a bare machine:

• bolt-cli disaster-restore rebuilds the box from the newest off-site snapshot
• bolt-cli disaster-reprovision re-materialises modules, PHP versions and hosting accounts
• bolt-cli restore-all-accounts restores the account files
• bolt-cli restore-all-databases imports their dumps

Every destructive restore asks you to name the machine being overwritten before it does anything and records the attempt either way.

Two smaller pieces round it out. Local snapshots of the mail and DNS databases are listed on the Server Backup page, with Restore showing the snapshot age and record counts before you commit. One is taken automatically before every panel-driven system update. And a backup policy with no target is now the server-wide default, covering every account nothing more specific claims, so a hosting plan added next month is never left without backups because someone forgot to attach a policy.

Clients get a smaller version of the same idea: Restore into the database next to the dump download, with the current contents snapshotted first so an accidental import can be undone.

Mail

MailChannels joins SpamExperts as an inbound filter. There is a MailChannels tab in Email Settings for the API key and subscription, then clients whose plan includes the feature get a per-domain toggle and one-click sign-in. Enabling registers the domain and swaps the MX records only once the filter confirms the delivery route. Disabling restores them first, so mail keeps flowing either way. A domain is filtered by at most one of the two. The apex MX of a filtered domain holds against zone edits, imports and DNS templates, which is the drift that used to break filtering quietly.

Mailboxes gain individual restrictions. Incoming mail, outgoing mail and login can each be set to allow or suspend and the server enforces each direction on its own, so you can stop a compromised mailbox from sending without cutting the customer off from reading what is already there. The Restrictions column names what is suspended. The webmail button explains itself when login is off.

Hosting plan mailbox quotas are now enforced on every path: the client panel, the admin panel and both REST APIs. A create without a quota takes the plan's default. A quota above the cap is refused with the cap named. Mail addresses are stored in lowercase everywhere, with an upgrade that sweeps mixed-case rows already on the server and reports what it repaired.

The panel's own mail is exempt from the outbound sending limits, so a busy server cannot silence the channel your mail problems are reported through. The Sending Limits page states the exemption and raises a banner if panel mail is ever throttled.

Two accounts cannot claim the same domain

A domain being added is now checked against the whole platform's namespace rather than an exact name match, so two accounts cannot end up serving overlapping names. An account's own subdomains are unaffected. A rejected add lands on a new Domain Security page where an admin approves or dismisses it and manages the approved overlaps, with the pending count on the navigation badge.

There is an optional ownership policy on top: a domain new to the platform is asked to prove ownership with a DNS record before it is provisioned and the panel shows the exact record to add then verifies automatically on retry. Overlaps that already exist, including ones arriving with a migration, are carried over on upgrade, so nothing in the field stops resolving the day you upgrade.

Impersonation is tidier too. An administrator stays signed in to their own panel across an impersonation and leaving it, logging out, signing in elsewhere or letting the session expire all end it and close its entry in the activity log.

An API worth building on

The client REST API grew a lot. Cron job management that adopts hand-added lines before every write. Address and domain forwarders with loop and duplicate rejection. Per-domain PHP directives to read and set. Database user grants in the read payload, opt-in database size and mailbox usage, the account's IP address and home directory.

There is a scoped file manager over the account home: list, stat, download, upload, write, move, copy, chmod, symlink, archive, extract and delete, paginated and size-capped. WP-CLI can run against a domain document root behind a per-key switch that is off by default, with commands that escape WordPress refused and every call audited. Single-use, short-lived sign-in URLs can be issued for phpMyAdmin and webmail, so an integration creates one server-side and hands it to a browser. Clients can create their own restricted keys.

The admin API got a review pass in the same release: hosting plan create and update persist the full field set, php_version_id is accepted on domain create and update and rebuilds the PHP configuration behind it. A write naming a field the panel does not apply is refused with the reason instead of answering with a success it did not deliver.

Smaller things you will notice

• FTP that cannot be saved into a broken state: the directives the panel's FTP stack depends on are applied on every write and are no longer editable fields and an upgrade repairs a server whose configuration already disagreed with them.
• Services that come back: web stack services restart on their own after a failure such as an out-of-memory kill, on new servers and on every server already in the field.
• Apache writes that get checked: a vhost write is validated before the reload and rolled back when it fails, with the offending file and Apache's own message reported.
• Domain rename: renaming a domain carries its document root, PHP-FPM pool, log directories, parked domains and page cache with it and rolls the whole rename back when a step fails.
• Real bandwidth figures again: an upgrade repairs web log ownership and permissions and installs per-account log rotation. bolt-cli repair-web-log-permissions runs the same sweep on demand.
• JetBackup restores: a restore replays the account's captured DNS zone, so custom records come back with it. The replay refuses before applying anything when the capture holds records it cannot represent.
• Certificate digests: when a scan pushes more certificates past a warning threshold than the number you set, the whole cohort arrives as one digest naming every domain instead of a notification per certificate.

Upgrading

Upgrades run from the panel. Open the Updates screen in the admin UI, apply 1.8.0 and watch the live progress. Take a backup first out of habit and expect only a brief interruption on a typical VPS. Expect the menu to look different afterwards and expect old bookmarks to keep working.

New to AdminBolt? Installation is a single command:

curl -sSL https://get.adminbolt.com/install.sh | bash

Tell us how it goes

That is 1.8.0: applications on CloudLinux, PostgreSQL, a migration that runs from the panel and a backup that can rebuild the whole machine. Tell us how it lands on Discord, the community forum or through the contact form.