Settings Reference
Settings Reference explains the SHM configuration areas that control hosting behavior, security posture, service availability, resource limits, customer features, backups, and automation.
Where to find it: Documentation > Hosting Manager > Settings Reference.
Available to: Anyone reading the public documentation. The related SHM action still follows the role stated on its page.
What this page does
Use this reference before changing settings that can affect many accounts. SHM settings are operational policy: they decide what customers can use, how resources are limited, how services behave, how backups are retained, and how access is protected.
Before you start
Examples use placeholder accounts, domains, addresses, and credentials. Replace them deliberately, and never paste passwords, API keys, tokens, or private keys into tickets or shared notes.
Why use it — and when not to
Use Settings Reference to understand or plan the supported workflow. Do not treat an example as authorization or as proof of the current state on a particular SHM server.
Settings Areas
| Settings area | What it controls | Recommended approach | Risk if misconfigured |
|---|---|---|---|
| Server settings | Provider identity, panel behavior, default service choices, hostname-related behavior, and global operating preferences. | Change during planned maintenance and document provider-wide decisions. | Incorrect server-level defaults can affect all accounts and support workflows. |
| Security settings | Login protection, 2FA expectations, SSH policy, shell posture, API access, IP restrictions, and account security options. | Use restrictive defaults and open access only for a defined business reason. | Weak policy increases account takeover, abuse, and lateral movement risk. |
| Account defaults | Default quotas, limits, features, contact behavior, shell policy, and resource values applied during provisioning. | Keep defaults aligned with standard packages and update them when product plans change. | Bad defaults create inconsistent accounts and extra manual correction work. |
| Packages | Customer hosting plan limits: disk, bandwidth, domains, databases, mailboxes, FTP, CPU, RAM, processes, I/O, IOPS, inodes, mail rate, and feature profile. | Use packages for repeatable commercial plans instead of manual per-account exceptions. | Under-limited plans can overload shared infrastructure; over-restrictive plans create support tickets. |
| Reseller packages | Delegated reseller capacity, account counts, IP limits, package availability, shell permission, and commercial boundaries. | Define clear reseller offers with capacity limits and escalation paths. | Loose reseller policy can oversell capacity or expose excessive privileges. |
| Feature profiles | Which modules and tools account users can see and use, including AI, DNS, databases, mail, backups, security, and application tools. | Expose only the features included in the plan and supported by the provider. | Wrong feature visibility confuses customers or gives access to unsupported workflows. |
| Apache and Nginx | Web-server integration, domain rebuild behavior, routing, service validation, and applied domain configuration. | Use tested templates and verify domains after changes. | Incorrect web settings can break hosted websites. |
| PHP | PHP versions, per-domain/runtime options, extensions, OPcache behavior, and account PHP settings. | Choose supported versions and validate application compatibility. | Wrong PHP runtime or extension settings can break applications. |
| MariaDB/MySQL | Database service behavior, user/database management support, process visibility, and compatibility expectations. | Use least-privilege database users and confirm backups before destructive changes. | Poor database policy can expose data or cause application outages. |
| PostgreSQL | PostgreSQL availability, account databases, account roles, pgAdmin access, and process visibility. | Enable only when supported operationally and document customer use cases. | Incorrect grants or unsafe process termination can affect applications. |
| Mailbox behavior, queues, delivery reports, rate limits, spam/filter options, and mail-service integration. | Keep rate limits and authentication policy aligned with deliverability goals. | Misconfiguration can create delivery failures or reputation problems. | |
| DNS | Zone management, record behavior, provider integration, domain validation, and Cloudflare-related workflows where enabled. | Use controlled record changes and verify propagation/validation. | Incorrect DNS can break websites, mail, SSL validation, and external services. |
| FTP/SFTP and shell | File-access delegation, FTP accounts, normal shell, JailShell, and NoLogin modes. | Prefer no shell or JailShell unless full shell is required and approved. | Excessive access increases account-level risk. |
| Cache and web manager | Cache behavior, site runtime tools, domain web settings, and application acceleration controls. | Apply changes per account/domain and verify site behavior. | Aggressive cache settings can show stale content or hide application errors. |
| Backup | Local/remote backup behavior, schedules, retention, restore points, and restore logging. | Keep backup policy aligned with recovery objectives and test restore workflows. | Bad backup policy creates unrecoverable customer loss during incidents. |
| Firewall and ModSecurity | Network filtering, block/allow lists, WAF policy, DDoS-related controls, and exception handling. | Use precise allow/deny entries and review logs before weakening protection. | Overly broad rules can block customers or expose services. |
| AI and API | AI availability, model/provider behavior, usage limits, API users, API keys, scopes, and source-IP restrictions. | Use limits, scoped access, key rotation, and no-secret prompt handling. | Unrestricted automation can create broad operational and security risk. |
Change Control Guidance
- For global settings, record why the change is being made and which accounts may be affected.
- For package settings, review whether existing accounts should inherit the change or only future accounts should use it.
- For security settings, test access from an approved account before relying on the change.
- For runtime settings, verify one representative website/application before broad rollout.
- For backup and restore settings, test recovery before assuming the policy is production-ready.
How to use it
- Identify whether the task is server-wide, reseller-scoped, or limited to one account.
- Open the page that owns the resource instead of using a nearby page with a similar name.
- Read the page-specific prerequisites and impact before changing anything.
- Verify the result in SHM and from the customer-facing service.
Result and next check
Reading this page changes nothing in SHM. Follow the linked workflow only after confirming the role, target, and expected impact.
Theme color