Managing Hosting Accounts in PCAdmin

Practical PanelConfig guidance for Managing Hosting Accounts In PCAdmin, with safe workflow, clear records, and operational review notes.

Managing Hosting Accounts In PCAdmin explains how this part of PanelConfig should be used in a production hosting operation. It focuses on practical decisions, audit visibility, and safe execution rather than marketing language. Hosting accounts are provider-owned records that connect users, packages, domains, usage, and service state.

Usage

Use this guide when you are configuring, reviewing, or troubleshooting managing hosting accounts in pcadmin for a hosting provider, agency, reseller, or customer account. It is useful during initial setup, operational handover, incident review, and routine maintenance.

Workflow

Open the related PanelConfig page: PCAdmin Dashboard and module sidebar under /app/admin.
Confirm the account, domain, user, or server context before changing anything. In provider environments, many records have similar names.
Review current status, ownership, package limits, and any pending jobs before making a change.
Make the smallest safe change first. For destructive or customer-visible operations, keep a ticket or internal note with the reason.
Re-check the page, job queue, audit log, and any affected service status after the operation completes.

Checklist

Check	Why it matters
Ownership	Prevents changes on the wrong customer, reseller, or hosting account.
Current status	Avoids repeating an action that is already pending, suspended, queued, failed, or completed.
Limits and dependencies	Shows whether package limits, DNS state, storage, service health, or credentials affect the result.
Audit trail	Gives support and operations teams a reliable record of who changed what and why.

PCAdmin: PCAdmin Dashboard and module sidebar under /app/admin

PCUser: PCUser pages are customer-scoped equivalents for many hosting modules.

Related PCCLI: php cli/pc accounts:list

Flow

flowchart TD
    A[Create Account] --> B[Assign Package]
    B --> C[Add Domain]
    C --> D[Create Website]
    D --> E[Issue SSL]
    E --> F[Monitor Usage]
    F --> G[Audit Changes]

Records

Typical records involved: audit_logs, login_history, jobs, services, server_health_checks, server_metrics. Some actions only read these records, while write actions may update status fields, create queue records, write audit entries, or refresh timestamps. For integration-ready areas, do not assume an external provider action has completed until the local job and provider-side evidence agree.

Notes

Security and audit notes: use least-privilege access, avoid sharing raw credentials, keep customer-impacting changes tied to a reason, and review Audit Logs or Login History when an action affects authentication, access, DNS, mail flow, backups, SSL, firewall, WAF, or account status.

Troubleshooting

If the page is empty, confirm the related database table exists and that the user role has permission to view the module.
If a change appears stuck, check Jobs, Job Logs, and Services before repeating the operation.
If an external dependency is involved, verify it independently: DNS propagation, ACME challenge visibility, remote backup storage, mail DNS records, or provider API state.
If the result is sensitive or customer-visible, capture the exact timestamp, account id, domain, and operator before escalating.

Example

php cli/pc accounts:list

php cli/pc accounts:suspend --id=N --reason="text", php cli/pc accounts:unsuspend --id=N, php cli/pc email:accounts

← Operator Workflow Suspending and Unsuspending Accounts Safely →