4.1.0

Added​

• Customer portals as independent Next.js apps: Mail (port 2091), DNS (2092) and S3 (2093). Each is built once in the Release workflow and shipped as its own signed tarball (portal-mail.tar.gz, portal-dns.tar.gz, portal-s3.tar.gz, listed in SHA256SUMS), runs as the unprivileged user hitechcloud-portal under its own systemd unit on loopback, and is served by the front-end over TLS only, on its own port and on any hostname added with hitechcloudcli portals host add. English and Vietnamese, no CDN, no remote fonts, a strict CSP. The panel stays the only source of truth: the portals hold no data of their own and read and write through the portal API, so what a customer changes in a portal is what 2083, 2087 and the CLI show.
• Mail Portal: domains with the records each one needs and whether public DNS has them, health checks with one-click fixes, mailboxes and their passwords, aliases and forwarders, delivery rules and autoresponders, devices (autoconfiguration), restore points and restores of a mailbox, the customer's own portal hostname, opening the webmail, and the event feed.
• DNS Portal: zones and records (add, edit in place by id, delete, with If-Match conflict detection), zone import (with a dry run), export and check, DNSSEC, and the record templates.
• S3 Portal (external S3 only: AWS, Cloudflare R2, Wasabi, Backblaze B2 or any S3-compatible endpoint; the stack installs no S3 server): connections with secrets sealed at rest and never shown again, a connection test, buckets, and an object browser with search, sort, paging, upload, download, share links, rename, copy, move, delete and a usage view. Endpoints are checked against private and special-purpose addresses.
• The portal API (/api/portal/v1, hitechcloudpanel/openapi/portal-v1.yaml) is the one contract the three apps use: bearer sessions, per-portal scopes, loopback only, rate limits, audit lines, ETags. Its TypeScript types are generated from the OpenAPI file and checked in CI.
• hitechcloudcli portals install|update|enable|disable|status|repair|logs|port|host|converge: installs a portal from the release tarball after verifying it against the signed SHA256SUMS, switches a new version in atomically and puts the old one back when /healthz does not answer, renders the unit, environment, vhost and firewall rule, and is run by every update, so an update never leaves an old portal behind. hitechcloudcli mailportal ... is kept as a deprecated alias. The admin panel can issue sign-in tickets for the three portals.

Changed​

• The Mail Portal of 4.0.8 (the server-rendered pages on 2091 served by a second panel process) is replaced by the Mail app. Its unit hitechcloud-mailportal.service becomes hitechcloud-portalapi.service (the old name is kept as an alias for one release) and the process now serves the JSON portal API on 127.0.0.1:2094 only. The update retires the old public listener and keeps the portal's hostnames (/etc/hitechcloud/mailportal/hosts.conf moves to /etc/hitechcloud/portals/hosts.conf).

Fixed​

• The portal API crash-looped with listen :2083: Address in use. Its unit loads panel.env for the database and cache settings, and systemd lets an EnvironmentFile override Environment=, so panel.env's LISTEN_ADDR=:2083 won over the unit's own. The address is now set by the command itself (ExecStart=/usr/bin/env LISTEN_ADDR=127.0.0.1:2094 ...), the update renders the unit again and restarts it, and hitechcloudcli portals status says "listening on the wrong port" when the API is on 2083.
• The portal apps' BFF route cannot be walked out of its allowed prefix by a slash, a dot segment or an encoded dot inside a path part, and its request bodies are capped. The S3 portal's endpoint guard sees through IPv6 spellings of private IPv4 addresses.

Known limitations​

• Mail Portal: "sign in as" for a mail service still uses the old autologin link (admin tickets live in the admin process's memory and cannot be redeemed by the portal yet). There is no passkey step for two-factor sign-in.
• S3 Portal: an object larger than 5 GiB cannot be copied or moved; deleting a folder is capped at 5000 objects; object versions can be viewed and downloaded, not restored or deleted.
• A published S3 connection is recorded as a backup destination reference (PORTAL_S3_CONNECTION) only; the Backups engine does not use it yet.
• There is no shared secret between the portal apps and the portal API (BFF secret): a process on the same server can reach 127.0.0.1:2094 with a token it holds. The API is not exposed beyond loopback.
• DNS Portal: the ALIAS record type is not offered, and nameserver (NS) verification is limited.