Skip to main content
Enterprise Annual License: pay for 10 months, get 12.Claim the free months
HiTechCloudPanelDocumentation
Version: 4.1

Move off the container stack

The container stack is retired

Since 30 September 2026 HiTechCloud runs only on the host-services stack: every service (web servers, PHP, MariaDB, mail, DNS, FTP) is a systemd service on the host. The older container stack, where each account ran its own podman or docker containers, is retired:

  • it receives no updates (hitechcloudcli update stops at the image pull, because its panel image is not published);
  • there is no installer for it any more (PODMAN_INSTALL.sh is gone);
  • current releases of HiTechAdmin and of hitechcloudcli notice a container server and say so (a banner on every HiTechAdmin page, and a notification from the hourly update check). A container server cannot update itself to those releases, though, so this page is the notice most will see.

Nothing on a container server is switched off by this. Its accounts keep working until you move them.

The move is server to server: you install a new server with the host services, and it copies every account from the container server. The container server is only read. Nothing on it changes until you run cutover for an account.

What moves​

For each hosting account:

ItemHow it arrives on the new server
The accountSame username. It keeps its panel password, e-mail address and two-factor secret, and its SSH/system password hash.
PlanThis server's plan with the same name, or a copy of the old one.
Website filesCopied into /home/<account>/public_html.
Web serverEach site keeps the web server it had: nginx, Apache, OpenLiteSpeed or OpenResty.
DatabasesOnly the account's own databases. They are renamed to the host's <account>_<name> form, so shop becomes alice_shop.
Database usersRenamed the same way, e.g. alice_wpuser, with the same grants. MariaDB users keep their password. See below for MySQL.
Site configurationwp-config.php and .env files that named the old database, user or the container host (mysql, mariadb) are rewritten. The original is kept as <file>.pre-migration.
Domains and certificatesEach domain is added through domains-add. A valid certificate from the old server is imported; otherwise AutoSSL issues one.
DNS zonesCopied with the old server's IP replaced by this server's.
MailMailboxes with their stored mail and passwords, aliases and forwarders, quotas, and DKIM keys, so the published DKIM record stays valid.
FTPFTP logins, each keeping its password.
Cron jobsCopied, with container paths rewritten to host paths, and scheduled in the account's crontab.

The migration never touches the new server's own root or panel database logins. It creates and grants only <account>_… logins on <account>_… databases.

Not moved (listed in the plan): PostgreSQL, MongoDB, Redis/Valkey, Memcached and Elasticsearch/OpenSearch containers. Move their data by hand.

A database that came from a MySQL container (not MariaDB) is imported into MariaDB. Its users' passwords used MySQL's caching_sha2_password, which MariaDB cannot read, so each such user gets a new password. The site's wp-config.php or .env is rewritten with that new password. Configuration files of other kinds are not rewritten: the result lists every user whose password was reset.

Steps​

  1. Install a new server with the host services. Use a new machine, not the container server:

    bash <(curl -sSL https://hitechcloud.org)

  2. Let it reach the container server as root, with a key. Run this on the new server:

    ssh-keygen -t ed25519            # if root has no key yet
    ssh-copy-id root@<old server>

  3. See what would move. This changes nothing on either server:

    hitechcloudcli migrate accounts plan --from <old server>

    The plan lists every account, with its domains, databases (old and new names), database users, and anything that will not be moved. Add --account <name> to look at one account.

  4. Migrate. Each account runs as its own background job, the systemd unit hitechcloud-migrate-<account>:

    hitechcloudcli migrate accounts run --from <old server>
    hitechcloudcli migrate accounts status --from <old server>

    Each account keeps three files in /var/lib/hitechcloud/migration/<old server>/<account>/:

    • progress.json: the step it is on and the steps done;
    • result.json: what moved, and every id that changed (old and new);
    • log: what happened, including the reason when a step fails.

    Running run again resumes each account where it stopped. A step that finished is not repeated.

  5. Check each account on the new server. Before changing DNS, point the domain at the new server in your own /etc/hosts. Then open the site, log in to the panel and to webmail, and read result.json.

  6. Cut over, one account at a time.

    hitechcloudcli migrate accounts cutover --from <old server> --account <name> --yes

    This stops the account's containers on the old server. It is the only step that changes the old server. Then point the account's domains at the new server, or its nameservers if the new server hosts its DNS.

When every account has been cut over, the old server can be retired.

Other ways to move accounts​

hitechcloudcli user-transfer moves one account, and hitechcloudcli server-migrate every account and the panel's settings, between two servers that both run the host services. They do not convert a container account. From a container server they copy /home but not the databases, the site records or the mail, so do not use them for this.

Previous
Transfers
Next
Import cPanel backup
Was this helpful?