Import an existing app into Softaculous management

Apps installed by hand — WordPress dropped in via SFTP, Magento set up by an agency, a Joomla site migrated from a different host — do not appear in the Softaculous Installations list, which means no one-click backups, no clones, and no upgrade button. The fix is Import: Softaculous parses the app's config file, registers it in its own database, and treats it as a native install from that point on.

This is for apps already living on the server. To pull a site from a different host over SSH, use Softaculous Remote Import for WordPress instead.

Run the import

In cPanel open Softaculous Apps Installer, pick the app (WordPress, Joomla, Magento, Drupal, PrestaShop — most of the catalogue supports import), and click the Installations tab. The button is Import at the top right; on some themes it is a small icon next to Install.

The form needs two fields:

• Install URL — the public URL, including protocol, e.g. https://shop.example.com.
• Install path — the absolute filesystem path containing the app's main config file, e.g. /home/cpuser/public_html/shop.

Click Import. Softaculous reads the config file (see per-app table below), extracts the database credentials, runs a connection test, and writes a row to its installation database keyed on the install path. The app appears in Installations within a few seconds.

What Softaculous reads, per app

If parsing fails Softaculous shows "Could not detect installation". The cause is almost always file permissions — the cPanel user must be able to read the config file. Check with sudo -u cpuser cat /home/cpuser/public_html/wp-config.php.

Per-app gotchas

Magento 2

The app/etc/env.php file is chmod 600 after a hardened install. Soft-relax it to 644 for the import (Softaculous reads as the cPanel user), then lock it back down:

chmod 644 app/etc/env.php
# run the import in cPanel
chmod 600 app/etc/env.php

Magento also needs var/cache writable by the cPanel user for Softaculous upgrade actions to work later. If you skip this, import succeeds but the next one-click upgrade fails mid-flight.

Joomla

configuration.php must be readable. Joomla's hardening guides often suggest 444, which works for import but breaks Joomla's own admin password reset. Leave it at 644.

WordPress

If wp-config.php defines DB_HOST as a Unix socket path (localhost:/var/lib/mysql/mysql.sock), Softaculous handles it. If it points to a remote DB host with a non-default port (db.example.com:3307), the connection test fails — Softaculous parses the host but ignores the port. Move the port into DB_HOST as db.example.com:3307 and re-test, or import against a DB_HOST=localhost config and rewrite afterwards.

What works after import

Once registered, Softaculous treats the install identically to one it deployed itself:

• Backups — file + DB backups to local or remote destinations on the schedule you configure.
• Clones — copy to another domain or subdomain in one click, useful for staging.
• Upgrades — one-click to the latest version, with optional pre-upgrade backup.
• Plugin and theme management — for WordPress only, where the plugin API exposes it.

What does not work

Heavily customised apps may not upgrade cleanly. Magento installs with modified core files, WordPress sites using a non-standard wp-content path, or Joomla installs with a renamed admin folder all import fine but break on the next one-click upgrade. For these, use Softaculous for backups and clones only, and run upgrades manually.

If the install uses a database engine Softaculous does not recognise (MariaDB Galera, PostgreSQL on a stock WordPress install via a plugin), import fails at the DB connection test. There is no workaround short of moving the data to standard MySQL/MariaDB.

Next steps

• Activate management features with a Softaculous license.
• Fresh server first? Run install Softaculous on cPanel.
• Pulling apps from another host? Use Softaculous Remote Import.