Object cache (Redis and Valkey)

hitechcloudcli objectcache manages per-account logins for the shared Redis and Valkey instances: the cache that WordPress and other applications use, and that the panel itself keeps its sessions in. Its legacy name is hitechcloudcli native-cache.

hitechcloudcli objectcache status

What each cache engine does on this server: whether it is running, whether it listens on loopback only or beyond, and whether accounts are isolated from one another.

From 4.1.2 status also has a panel line saying whether the panel's own login to its cache works.

The panel keeps its sessions in the cache. If the cache refuses the panel's login, nobody can sign in to 2083, the customer portals or a one-time login link: the browser goes back to the login page.

hitechcloudcli objectcache panel-login [--no-restart]
hitechcloudcli objectcache reset-admin <redis|valkey> --yes

panel-login keeps a login that works. Otherwise it writes, in one step, the first login on file that the panel's cache accepts, and restarts the panel once (--no-restart leaves the restart to you). The installer and every update run it with --no-restart.
reset-admin is for when no login on file opens the instance at all. It sets a new administrator password in the instance's ACL file, keeps every account's login, and restarts the instance once. The panel's login follows when it is the panel's cache.

NOTE

These two commands come with 4.1.2. They were checked in the code and its unit tests, not on a live server, for this page.

Per-account isolation

With isolation on, every hosting account has its own cache login and its own key space, written to ~/cache.cnf, and the instance refuses clients that do not authenticate.

hitechcloudcli objectcache secure [redis|valkey|all] [--yes]
hitechcloudcli objectcache adduser <username> [--engine <name>]
hitechcloudcli objectcache deluser <username>
hitechcloudcli objectcache password <username>
hitechcloudcli objectcache show <username>

secure provisions every existing account first, then closes the instance to unauthenticated clients.
secure ... --if-fresh only acts on a server that has no hosting accounts yet. The installer runs it, so a new server is isolated from the start and an existing one is never cut off behind the administrator's back.
adduser gives one account its cache login and ~/cache.cnf; deluser removes the account's logins and its cached keys; password resets the password and rewrites ~/cache.cnf; show prints the connection details.

Servers that already have accounts

In 4.1.x isolation is switched on automatically only on a server with no accounts. Turning it on later stops every client that connects without a password. The panel's own WordPress Redis setup writes none, and rspamd's greylisting configuration carries none, so check those before running secure on a server in use. Until then objectcache status reports the instance as shared: it listens on loopback only, so it is the accounts on the machine, not the network, that can read each other's cached data.

hitechcloudcli objectcache unsecure <engine> --yes

Reopens the instance to unauthenticated clients. It is the escape hatch, not a setting to leave on.

Loopback only

hitechcloudcli objectcache loopback

An instance that listens beyond this machine and accepts clients without a password is bound to 127.0.0.1 and ::1, in its configuration and in the running server, without a restart. One that asks for a password is reported and left alone. Every update runs this.

Image cache

hitechcloudcli objectcache image help

The converting image cache: WebP and AVIF copies served to browsers that accept them, the original to everyone else.

Customers turn it on per website in 2083 under Websites > Image Cache. The copies live under /var/cache/hitechcloud/native/images/<domain>, outside the account's files; the originals are never changed, and objectcache image purge <domain> (Remove generated files in 2083) deletes the copies.

Images are never decoded as root. Each run starts the converter as the website's own user in a systemd unit inside the account's user-<uid>.slice, limited to half a CPU core at the lowest CPU and disk priority, with no network and a read-only system. It writes only to ~/.cache/hitechcloud-images/ in the account's home, never follows a symbolic link in the document root, and makes at most 2000 conversions per run. Root then copies a result into the cache only if it matches a real image in the document root, is a plain file owned by the account, is no larger than the original, and is really a WebP or AVIF file.

The encoders are cwebp and avifenc from the distribution (objectcache image encoders --install):

OS	WebP	AVIF
Ubuntu 22.04, 24.04, 26.04; Debian 12, 13	`webp`	`libavif-bin`
AlmaLinux 9, 10	`libwebp-tools` (CRB repository)	`libavif-tools` (EPEL only)

Without avifenc only WebP is offered. ImageMagick is not used.

Where the logins are kept

The administrator login of each engine is in /etc/hitechcloud/hitechcloud/cache.cnf (ADMIN_REDIS_*, ADMIN_VALKEY_*). The panel's own cache login is REDIS_PASSWORD in the panel's environment. When the panel cannot use its login, nobody can sign in to 2083: see Troubleshooting.