The resources inside a hosting plan
A hosting plan is not a single website. It is a container for website storage, one or more domain-to-folder mappings, an application runtime, databases and optional email. These resources have separate credentials and separate backup histories. Removing a domain mapping does not delete its files or database, and uninstalling an application does not necessarily remove every resource it used.
How a web request reaches a site
A visitor first resolves the domain through DNS. The resulting A or AAAA record must lead to the hosting service. The hosting then selects the attached hostname, negotiates TLS for HTTPS, maps the request to that hostname's document root and runs the requested file through the configured runtime. A dynamic application may then connect to its database. Test these layers in that order: DNS, TLS, document root, runtime and database.
Domains and document roots
Each attached domain or subdomain points to a relative folder in the hosting storage. For example, an apex domain can serve files from www while a shop subdomain serves a different application from shop. Several hostnames may intentionally share one root, but unrelated sites should use separate roots so that an upload, deployment or uninstall cannot overwrite another site. Domain registration and authoritative DNS remain independent of the hosting mapping.
Files and application code
Website files are stored below the hosting account's home directory. Publish them with encrypted SFTP, Silurian File Manager, Git deployment, Site Studio or a supported application installer. Use one publishing method per document root. Keep configuration files and application secrets outside public roots whenever the software supports it, avoid world-writable permissions, and keep an independent copy before replacing an existing site.
PHP and application execution
Standard plans execute PHP applications in a managed environment. The selected PHP version must be supported by the application, theme and extensions together. Production mode suppresses diagnostic output that could reveal filesystem paths or secrets; use development diagnostics only temporarily. Runtime changes affect executed code but do not update the application itself, so test the public site and its administration area after every version change.
Application databases
The included databases are separate network services. Applications must use the exact database hostname, database name, username and password supplied for that database; localhost and the hosting IP are not substitutes. Included MySQL databases accept a maximum of 30 concurrent connections. Persistent connection leaks or an unnecessarily large connection pool can therefore make a healthy database appear unavailable.
Email is a separate service
A website, its domain and its mailboxes are related but technically separate. Publishing a website does not route email. Mail delivery requires an activated email service, mailbox or forwarding destination, and correct MX and sender-authentication DNS records. Website-generated messages also use a separate script-mail or authenticated SMTP path and should be tested independently from mailbox login.
TLS, cache and application firewall
TLS protects traffic between a visitor and the hosting service; it does not repair an insecure application. A certificate must cover every hostname that serves HTTPS before redirects are enforced. CDN or hosting cache may continue serving an older response after files change, while the application firewall may reject requests that resemble an attack. Purge only the affected cache after a verified deployment, and disable a protection temporarily only when a reproducible compatibility test requires it.
Backups and a complete recovery
Website files and databases are backed up and restored independently. Select matching restore points when recovering a dynamic application; restoring yesterday's files with today's database can produce incompatible code, missing media or broken schema changes. A platform snapshot is not a substitute for an off-platform export, and a backup should be considered usable only after a restore has been tested.
Limits and performance
Shared hosting isolates customers but still applies plan limits to storage, databases, traffic and execution. A slow site can be caused by application code, external calls, an overloaded database, large uncached responses or a platform incident. Measure a simple static file and a minimal runtime script separately from the full application before deciding which layer is responsible.
