Third-party modules

Server > Third-party modules (/server/third-party-modules) is where the Super Administrator installs and manages modules other vendors build for the panel. A module can add pages and dashboard tiles to the customer panel, pages to this panel, be told about account, domain, certificate, backup and login events, read the accounts it is allowed to see, and offer commands - each only with the permissions you approve when you install it.

The panel's own services (mail, DNS, databases, ...) are not modules in this sense; they are under Modules & Services and the App Store.

How a module is kept apart​

• It runs as its own unprivileged system user, in a systemd sandbox, with memory, CPU and process limits. It never runs as root.
• It can read and write only its own data directory. Customers' home directories, the panel's configuration, databases and logs are invisible to it.
• It reaches the panel only through the module API, with a token bound to its own user, limited to the permissions you approved and to the accounts in its scope: by default only accounts whose plan includes it.
• Its pages run in a sandboxed frame inside the panel's layout, with no access to the viewer's session.
• Panel actions never wait for a module: events are queued and delivered in the background, signed, with retries.

Installing a module​

1. The vendor gives you a signed package (.hcm) and their public key. Add the key once under Trusted signing keys.
2. Upload the package. Nothing is installed yet: the review page shows who signed it, the panel versions it supports, the events it wants, the pages it adds and every permission it asks for, in a sentence - sensitive ones in red. Tick each to approve it.
3. Approve and install. The install runs in the background; the module appears in the list when it is done.

An upgrade is the same, and must be signed by the same key as the installed version. A new permission needs your approval again.

Unsigned packages are refused unless you switch on Allow unsigned modules - and even then each needs a second confirmation. Use it only for a module you built yourself.

Giving a module to customers​

A module with customer pages is a feature, ext.<module id>, in the feature set editor (Plans > Feature Manager). Tick it in a plan's feature set and that plan's accounts see the module's pages - and only then can the module see those accounts.

Managing a module​

Each module's page shows its state and health, the permissions it holds, the events it receives and any deliveries that failed, its settings form (declared by the module, checked before saving; secrets are never shown again), the last 200 lines of its log, and: Restart, Disable/Enable, New API token, Uninstall keeping its data, Uninstall and delete its data. Uninstalling removes its service, user, code, secrets, settings, queued events and its feature from every plan.

From the command line​

hitechcloudcli modules list|info <id>
hitechcloudcli modules inspect <file.hcm>
hitechcloudcli modules install <file.hcm> --approve <perm,...> [--allow-unsigned]
hitechcloudcli modules upgrade <file.hcm> --approve <perm,...>
hitechcloudcli modules enable|disable|restart|remove <id> [--keep-data]
hitechcloudcli modules config <id> get | set --json-stdin
hitechcloudcli modules logs|health <id>
hitechcloudcli modules run <id> <command> [args...]
hitechcloudcli modules keys list|add <file.pub>|remove <key id>
hitechcloudcli modules settings --allow-unsigned on|off

Every command answers --json. (hitechcloudcli module, singular, is the panel's own services.)

For module authors​

The HiTechCloud DevKit ships with the panel in integrations/devkit: the integration guide in English and Vietnamese (integrations/devkit/docs/en/README.md, docs/vi/README.md), starter templates for PHP, Node.js, Python, Rust and Go, two complete example modules, and the devkit tool that validates, packages, signs and runs a module against a local mock panel.