@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

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

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.

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

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!

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!

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.

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] ]

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