API support for per-user page/function permission overrides?

[Wolfcom]

Hi,

we are integrating PNLCS with Panelica and would like to automate package-specific permissions during account provisioning.

We currently use the global USER role as a restricted baseline. This works well for our smaller hosting plans, where features such as Docker, Node.js, Python, Laravel and Git should not be available.

For higher plans (e.g. Business), we can manually enable selected features for an individual user through:

Users → Edit User → Page Permissions → Page Overrides / Function Overrides

We tested this successfully. For example, adding individual ALLOW overrides for Docker pages makes Docker Manager available for that specific user while the global USER role remains restricted.

The question is:

Is there currently an external API endpoint to create/update these per-user page and function permission overrides?

We checked the external API documentation (408 endpoints) and the /v1/accounts/{id} update endpoint, but could not find fields or endpoints for these permission overrides.

Our intended provisioning flow is:

PNLCS order → Panelica account created with plan → automatically apply additional page/function permissions depending on the purchased product.

This would allow us to keep one restricted global USER baseline while automatically granting additional features to Business/Pro customers without manually editing every new Panelica user.

If this is not currently available through the external API, is there another supported way to automate these overrides, or would this require a feature request?

Thanks!

[Wolfcom]

Thanks, that makes sense. Maybe I am approaching this from the wrong direction, so let me ask it from a hosting provider's point of view. If I offer several different hosting products, what is the intended way in Panelica to control which features are available for each product? I don't mean resource limits such as CPU, RAM, disk space, number of databases, etc. Those are clear and can be defined in the service plans. I mean actual features/modules such as: * Docker / Containers * Node.js * Python * Laravel * Git / Deployment For example, I might want to offer: Basic / WordPress: no Docker, Node.js, Python or Laravel Business: Docker + Node.js + Laravel Pro: all available developer features At the moment I can restrict these pages globally for the USER role, and I can manually enable individual pages for a specific user using Page Permission Overrides. But that would require manually changing permissions for every Business/Pro customer. What is the intended way to handle this with different hosting products/plans? Is there already another mechanism for assigning feature/module access based on the user's service plan that I have missed? I'm mainly trying to understand the intended Panelica architecture before building anything around it. thanks Dejan Am 2026-09-20 23:08, schrieb Cedric Conday:

…

The endpoints exist in routes/api.php but aren't implemented -- both getuserpermissions and updateuserpermissions return 501: _"Per-user permissions are not implemented; every login on an account has the same access."_ getpermissionslist does work, but it returns the static list of permission names (clients, orders, invoices, tickets, services, domains, servers, settings, reports, addons, system), not anything per-user. So there's nothing to automate against yet. -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [3] and Android [4]. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

-- WEBDESIGN & ONLINE MARKETING Berta Wolf Tel.: +43 (0) 699 150 68 950 Web: wolfcom.at [5] E-Mail: ***@***.*** Neue-Heimat-Str. 4, 9400 Wolfsberg Österreich Links: ------ [1] #46?email_source=notifications&email_token=CO7NHDUGR2FNXQBXJCAAAVD5QBBLPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGMYTINRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18531460 [2] https://github.com/notifications/unsubscribe-auth/CO7NHDRQZLWM4OGDF3K57PL5QBBLPAVCNFSNUABJKJSXA33TNF2G64TZHMYTEMJTHE3TEMZUGU5UI2LTMN2XG43JN5XDWMJQHA2TGNRWHGQXMAQ [3] https://github.com/notifications/mobile/ios/CO7NHDXETK6PDBBGYSMGGFT5QBBLPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGMYTINRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM [4] https://github.com/notifications/mobile/android/CO7NHDQLURMNCIHNMRAI5D35QBBLPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGMYTINRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE [5] https://wolfcom.at/

[CedricConday]

The axis is the plan, not per-user permissions.

For a product on a Panelica server module in managed mode, PNLCS already builds
a panel plan from the product configuration and keeps it in sync:
managedPlanSpec() maps the product's res_* options onto the plan columns and
ensureManagedPlan() creates or PATCHes pnlcs-p<product_id> on /v1/plans.
Every account on that product lands on that plan.

The plan carries the feature switches as well as the limits:
ssh_access_enabled, ftp_access_enabled, mysql_access_enabled,
cron_jobs_enabled, ssl_enabled, backup_enabled and max_containers. Docker
is therefore a plan lever — max_containers: 0 on Basic, a real number on
Business and Pro. Which apps a plan may install is decided in the panel's app
catalogue.

Node.js, Python and Laravel have no flag in that contract. hostingFeatures()
returns the full list — emails, files, databases, ftp, subdomains, cron, dns,
backups, containers, laravel, nodejs, python — for every Panelica service except
one marked as a container plan, which gets containers alone. There is no
per-product switch for those three today.

[Wolfcom]

Thanks, that clears up the intended architecture for me. So for different hosting products, managed plans are the intended way to control both resource limits and the features that are currently part of the plan contract. The remaining part I am trying to understand is Node.js, Python and Laravel. If these are currently returned for every normal Panelica hosting service and there is no per-product switch, is product-level control for these features planned? For example, the goal would be: Basic / WordPress: no Node.js, Python or Laravel Business: Node.js and Laravel Pro: Node.js, Python and Laravel Is that something you intend to add to the managed plan contract in the future? thanks regards Dejan Am 2026-09-21 20:00, schrieb Cedric Conday:

…

The axis is the plan, not per-user permissions. For a product on a Panelica server module in managed mode, PNLCS already builds a panel plan from the product configuration and keeps it in sync: managedPlanSpec() maps the product's res_* options onto the plan columns and ensureManagedPlan() creates or PATCHes pnlcs-p<product_id> on /v1/plans. Every account on that product lands on that plan. The plan carries the feature switches as well as the limits: ssh_access_enabled, ftp_access_enabled, mysql_access_enabled, cron_jobs_enabled, ssl_enabled, backup_enabled and max_containers. Docker is therefore a plan lever -- max_containers: 0 on Basic, a real number on Business and Pro. Which apps a plan may install is decided in the panel's app catalogue. Node.js, Python and Laravel have no flag in that contract. hostingFeatures() returns the full list -- emails, files, databases, ftp, subdomains, cron, dns, backups, containers, laravel, nodejs, python -- for every Panelica service except one marked as a container plan, which gets containers alone. There is no per-product switch for those three today. -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [3] and Android [4]. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

-- WEBDESIGN & ONLINE MARKETING Berta Wolf Tel.: +43 (0) 699 150 68 950 Web: wolfcom.at [5] E-Mail: ***@***.*** Neue-Heimat-Str. 4, 9400 Wolfsberg Österreich Links: ------ [1] #46?email_source=notifications&email_token=CO7NHDXGWDPE2UMBALNQSEL5QFUFNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGQZTINZVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18543475 [2] https://github.com/notifications/unsubscribe-auth/CO7NHDVSHH6WCCPRFFTZOZ35QFUFNAVCNFSNUABJKJSXA33TNF2G64TZHMYTEMJTHE3TEMZUGU5UI2LTMN2XG43JN5XDWMJQHA2TGNRWHGQXMAQ [3] https://github.com/notifications/mobile/ios/CO7NHDQMYJBWUPHWNSGGMAD5QFUFNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGQZTINZVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM [4] https://github.com/notifications/mobile/android/CO7NHDSA5G23C5VY3IT6SAT5QFUFNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGQZTINZVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE [5] https://wolfcom.at/

[Panelica]

Hi Dejan,

Thank you for the detailed questions, and sorry for the wait.

To your last question: on the Panelica side, a plan already has its own limits for Node.js, Python and Laravel apps and a Git switch, and the panel enforces them when an app is created. The gap is on the PNLCS side: managed plans do not send these fields yet, and the client area always shows the Node.js, Python and Laravel tools for a Panelica service. We have no fixed date for closing it.

We built PNLCS to be modular for exactly this kind of case: server modules, hooks, themes and the API can be extended without changing the core. enahosting.com is a good example of how far that goes. They run PNLCS in production with 34 products on the Panelica module, including one-click app hosting and container plans, and several fixes they made on their own install are now part of PNLCS.

As the README says, our main focus is the Panelica project itself, and PNLCS moves forward largely with help from the people who use it. So a pull request for this would be very welcome: the three app limits (and Git) in managedPlanSpec() and the product form, and hostingFeatures() hiding the tools a plan does not include. If it fits the existing architecture and works for current installs, we will gladly review and merge it, with credit. Tests help it along; the contributing guide and module guide are good starting points.

Thanks again, and we would be happy to see you among the contributors.

Panelica Team