PanelicaDocs
panelica.com
Docs / Databases / Database Users

Database Users

Panelica 1.0.375 Verified 2026-07-23 Databases

Database Users manages MySQL accounts directly: who can log in, from where, into which databases, with which privileges. These are real MySQL users; the page reads and writes mysql.user itself, so what you see here is what the database server actually enforces.

Panel locationDatabases → Database Usershttps://YOUR-SERVER-IP:8443/databases/users
 MySQL Users
UserHostDatabasesPrivilegesStatusActions
example_wplocalhost115activeprivileges · password · lock · delete

Creating a user

Username, host, password, databases, privileges. The host decides where the user may connect from: localhost (same server, the right choice for hosted websites), % (any host, flagged with a warning), or a preset subnet pattern. Databases are a multi-select of the server's databases, and privileges come as a checkbox grid of 17 privileges in three groups (data, structure, administration) with four one-click templates: Read Only, Read/Write, Full (No Admin) and All Privileges. An optional connection cap limits the account's simultaneous connections.

Behind the scenes: creation is plain, verifiable SQL: CREATE USER, one GRANT per selected database, an optional MAX_USER_CONNECTIONS cap, then FLUSH PRIVILEGES; a failed grant rolls the user back out. The privilege list is a strict whitelist: server-level privileges that could break out of a database (SUPER, FILE, SHUTDOWN, RELOAD, GRANT OPTION, replication and user-management rights) are rejected outright, whatever the request says. The backend also enforces a password policy of its own: 8-128 characters, upper- and lowercase plus a digit, and no SQL keywords inside the password. Passwords are applied to MySQL and not stored by the panel; what MySQL holds is the only copy.
Protected accounts stay out of reach. The server's own accounts (root, mysql system users, the panel's internal users, monitoring users) are excluded from the list, so they cannot be picked in the UI, and deleting core system accounts is refused outright.

Managing users

Manage Privileges reopens the grid per database; saving revokes and re-grants cleanly rather than layering grants. Change Password offers a 16-character generator and a live strength meter. Disable locks the account with MySQL's native ACCOUNT LOCK (connections are refused but grants and password survive; enable unlocks). Delete demands typing DELETE, then drops the user; root and the core system accounts are refused.

Least privilege, practically: give websites the Read/Write template on their one database; reserve Full (No Admin) for staging and development databases; and treat All Privileges plus host % as the combination that should make you pause. Note that the everyday database users created together with a database on the MySQL Databases page already follow this philosophy, with DROP withheld.

Access

Behind the databases license feature, with per-operation permission keys (view, create, manage privileges, toggle status, change password, delete). Visibility follows the roles and permissions chain, mapping MySQL users to their owners through the databases they are granted on. The same management exists on the External API under databases:* scopes.

Panelica Documentation · Written and verified against the live panel. · Last verified 2026-07-23 on Panelica 1.0.375