Excellent suggestion @miked I’ll get this added to our backlog for sure.

I had the same problem as well and analyzed it. For my case, it seems like cloudflare is blocking IPs from my Hoster (Hetzner) by default so validation always fails at the bootstrap step.

Hey @Stell, thanks a lot for the info! I think this is all what I need to know for now - we will work with that and we’ll keep our fingers crossed that everything goes according to plan.

@Bolder You are correct, manual update states incorrect details that are miss leading. I’ve updated the docs and they should be published shortly to now properly reflect the manual update and also the offline update process. For those behind Proxy, you can follow the https://docs.multiportal.io/kb/article/0000050/. Just a heads up, at this stage if you have used the offline-update, there is no method currently to update the installation via the automatic process. Woody

MultiPortal has published security advisory MPSA-2026-001, a stored cross-site scripting issue in user and resource name fields. Severity: High (CVSS v3.1 base 8.7) Affected: MultiPortal Core 1.1.2, 1.1.3, and 1.2.0 Fixed in: 1.2.1 If you run an affected version, upgrade to 1.2.1 at your next maintenance window. The fix needs no data cleanup: existing names are made safe when they are displayed. Read the full advisory, including impact, remediation, and workaround: MPSA-2026-001 on docs.multiportal.io The fix ships in the 1.2.1 release. To report a vulnerability privately, see Reporting security issues.

Environment MultiPortal Version: 1,2.0 Proxmox VE Version: 9.2 Deployment Type: HA Cluster] Browser (if UI issue): Edge Description When creating a new user and assigning a role at creation, the role is not applied. The user is created successfully with no error shown, but the role field is blank in the users list. The failure only surfaces later when the account is used. Editing the same user afterwards and assigning the role works correctly. This may share a root cause with the existing thread “Suspected Bug: User Permissions Not Updated After Role Changes” — that one describes create working and later role changes not propagating; this is the inverse on the create path. Steps to Reproduce (if applicable) Create a new user and select the Service Provider Administrator role. Save. User is created, no error displayed. Users list shows the role field blank. Impersonate the user - Forbidden (#403). Edit the same user, assign Service Provider Administrator, save. Role now applies correctly and impersonation works Expected Behavior The role selected at creation is persisted and applied to the user. If it cannot be applied, an error is surfaced at creation rather than the user being created in a broken state. Actual Behavior The role is silently dropped. The user is created without permissions and no error is shown. The only signal is a 403 at point of use. Logs/Screenshots [[image: 1784206469866-39a43383-7712-4277-a140-b8caa926472d-image.jpeg] ]

Thanks for letting us know @guillaume , we’ll take a look at this for sure

I absolutely agree, and this is something we have already put on our roadmap, only it’ll be under a full catalogue re-imagining (for the better, I promise). Thanks for the feedback!

@ranjina.vazhayil , thanks for the confirmation, I’ll provide this to our team to see if we can replicate it.

Hi Currently, the manual installation process requires direct internet access, which prevents deployments in environments where outbound connections must go through a proxy. This is a significant limitation for organizations with strict security policies. We would also like the license validation/check to be able to use the configured proxy instead of requiring direct internet access. Providing full proxy support for the installation process and all external communications, including license verification, would greatly simplify deployments in secured and restricted environments. sincelery

Heck yes, love this @guillaume . We’re in the early planning stages for tags, providing every level (provider, reseller, tenant) to tag all objects in their respective tiers. I obviously can’t give any indicative times but just know we are totally on board with tags!

We would like to request an enhancement to MultiPortal regarding VM provisioning. Currently, when a VM is created with UEFI boot, the boot disk is automatically created in RAW format. This causes an issue when the storage backend is an LVM LUN, as RAW disks do not support snapshots in this configuration. Requested enhancement: Please add an option to specify the disk format (for example, QCOW2) for the UEFI boot disk during VM creation. Benefits: Enable snapshot support for VMs stored on LVM-backed storage. Provide greater flexibility in storage configuration. Allow administrators to choose the most appropriate disk format based on their storage backend and operational requirements. Current behavior: UEFI boot disk is always created in RAW format. Snapshot creation is not possible when the VM is stored on an LVM LUN. Expected behavior: Allow administrators to select the boot disk format (RAW or QCOW2) when provisioning a UEFI VM. Ensure QCOW2 can be used as the boot disk format to support snapshots where applicable.

Thanks :) I really wanted it to match our new site as well as WHMCS so clients get a fully “brand” experience…

Totally agree - this is something I’ll be working on

Thanks @Stell! It’s a great news knowing you’re already planning about, because this request come from customers real need. We will looking forward about this! :-)

Hey @danielbfusionred we’re actually adding something like this for storage changes in the next release. Feedback noted: we’ll look at adding pending reboots for other changes.

Hey MikeD, thanks for the post! We’re aware of this bug and we’re already investigating it.

Hey @southwalesowl, Adding the 127.0.0.1 multiportal.calligo.cloud hosts entry just allows MultiPortal and the console server to talk to each other locally, however, the error you now have ECONNREFUSED 127.0.0.1:443 means the console server cannot reach MultiPortal locally on port 443. That loopback shortcut only works when MultiPortal is handling its own traffic directly on the server. Can you please confirm: MultiPortal was installed using the automated script? Is an SSL configured on the box, or are you using a Load Balancer for MultiPortal? Confirm the system is reporting on port 443 sudo ss -ltnp | grep ':443' You should see something like ⎿ LISTEN 0 4096 *:443 *:* users:(("caddy",pid=4140634,fd=7)) Can you also comment out that hosts entry you added to your MultiPortal server, restart the console server, and try connecting again? Let me know if the old error comes back after you regenerated the new API key. Matt

Great news, thanks! This feature is fundamental for our customers that already upload and download appliances and VMs on their behalf, without admins intervention. Looking forward to see it on MultiPortal! :-)

I performed an additional test by running: php yii vm-post-task/process The command returns: Unable to get status for Proxmox task UPID:iaas-pve-s1-002:001E1CD9:01149D63:6A2D92BF:qmclone:103:multiportal@pve!ertyfghj: Proxmox task UPID:iaas-pve-s1-002:001E1CD9:01149D63:6A2D92BF:qmclone:103:multiportal@pve!ertyfghj: is still running, skipping... However, the clone operation has already completed successfully in Proxmox and the VM exists and is fully created. It appears that MultiPortal is unable to correctly determine the final status of the Proxmox clone task and continues to consider the UPID as running. This may also explain why the post-clone task never completes. Regarding the network issue, I can confirm that the network adapter is requested during deployment from the template, but it is never added to the VM. The network interface is missing not only in MultiPortal, but also in the VM configuration directly in Proxmox. As a result, the deployed VM is created without any network device attached. Could there be an issue with task status polling or UPID tracking in MultiPortal when used with Proxmox VE 9.2.3? One additional point that may be relevant: this is a brand new MultiPortal installation deployed in an offline environment behind a proxy. The documentation is not very explicit regarding offline deployments and proxy requirements, so I am not completely sure whether my installation is fully operational or if there are additional configuration steps required for this type of environment. Could you advise on how I can verify that the installation is healthy and fully functional? Are there any specific services, connectivity checks, background workers, queue processors, or diagnostic commands that should be validated after an offline installation behind a proxy? I would like to rule out any installation or connectivity issues before investigating the cloning and post-clone task problems further.