Website Management (Sites)¶
Website management enables the complete configuration of websites, including PHP settings, Nginx directives, preview domains, access restrictions, and deployment options.
Overview¶
The site table shows all configured websites with thumbnail preview, status, and configuration details.
Displayed Columns¶
| Column | Description |
|---|---|
| Preview | Thumbnail image of the website |
| Domain | Primary domain of the website |
| Customer | Assigned customer |
| Linux User | System username |
| PHP Version | Active PHP version |
| Status | Active or Disabled |
| Document Root | Path to the web directory |
Create Website¶
- Click Create Website
- Fill out the form:
| Field | Required | Description |
|---|---|---|
| Subscription | Yes | Associated hosting subscription |
| Domain | Yes | Domain of the new website |
| PHP Version | Yes | PHP version (loaded dynamically from the server) |
| Document Root | No | Subdirectory (default: domain root) |
- Click Create
Dynamic PHP Versions
The PHP version dropdown is populated dynamically from the server API. It always reflects the PHP versions actually installed on the target server, so you never have to guess which versions are available.
The system automatically configures:
- Nginx vhost with security policies
- PHP-FPM pool under the Linux user
- SSL certificate via Let's Encrypt (if enabled)
open_basedirrestriction- Upload directory protection (PHP execution blocked)
Edit Website¶
Click the Edit button (pencil icon) of a website to open its configuration.
Tab: General¶
| Field | Description |
|---|---|
| Domain | Primary domain of the website (changeable) |
| PHP Version | Change PHP version |
| PHP Handler | FPM or CGI |
| Document Root | Adjust web directory |
| Status | Enable/disable website |
| www ↔ Bare Domain Redirect | Automatic 301 redirect between www.domain and domain (off / to www / to bare domain). Details, including the safeguard against an opposing redirect from the application itself: Customer Manual → Managing Websites |
Change Domain¶
The primary domain of a website can be changed directly in the edit modal.
How to¶
- Open Websites and click the Edit button of the desired website
- Change the Domain field to the new domain
- Click Save
What happens automatically¶
| Step | Description |
|---|---|
| Nginx vhost | Old vhost is removed, new one created with the new domain |
| WordPress URLs | If WordPress is installed, siteurl and home are automatically updated via search-replace (all tables) |
| Panel database | Domain in sites, wordpress_installations and domains tables is updated |
| PHP-FPM | Pool remains unchanged (same Linux user) |
| Files | All files remain in the same location — only the domain mapping changes |
Validation¶
- The new domain must have a valid format (e.g.
example.com,shop.my-hosting.com) - The domain must not already be used by another website
- The change takes effect immediately — no restart required
After the domain change¶
- SSL must be manually activated for the new domain (under Domains → Enable SSL)
- DNS must point to the server before SSL can be requested
- Existing domain aliases and subdomains are preserved
Note
Make sure the DNS A record of the new domain points to the server's IP address before enabling SSL. Otherwise, certificate creation will fail.
Tab: PHP Configuration¶
PHP settings can be customized per website:
| Setting | Description |
|---|---|
| memory_limit | Maximum memory per PHP process |
| max_execution_time | Maximum execution time in seconds |
| request_terminate_timeout | Hard timeout after which a stuck PHP-FPM worker is killed (seconds). Catches scripts that don't stop despite max_execution_time. |
| PHP-FPM Slow Log | Logs PHP requests that run longer than the threshold, with a stack trace — helps locate slow spots in the code. |
| max_input_time | Maximum input time |
| post_max_size | Maximum POST size |
| upload_max_filesize | Maximum upload file size |
| max_input_vars | Maximum number of input variables |
| max_file_uploads | Maximum number of simultaneous uploads |
| display_errors | Error display (for development only!) |
| error_reporting | Error reporting level |
| session.gc_maxlifetime | Session lifetime |
| opcache.enable | Enable OPcache |
| open_basedir | Path restriction |
| disable_functions | Disabled PHP functions |
disable_functions
The default security settings disable dangerous functions such as exec, passthru, shell_exec, system, popen, and proc_open. Only change these if you understand the security implications.
Tab: Nginx Directives¶
Custom Nginx configuration directives can be added in the text field. These are inserted into the server block of the vhost configuration.
Examples:
# Additional headers
add_header X-Frame-Options "SAMEORIGIN";
# Redirect rule
location /old-page {
return 301 /new-page;
}
Syntax Validation
The system validates the Nginx configuration before saving. Syntax errors will cause the change to be rejected.
Preview Address¶
A website can be made reachable under a second address while its real domain still points at another server — the standard situation during migrations, where the customer wants to finish building the new site before switching the domain over.
Two sources for the address:
| Source | Requirement |
|---|---|
A name supplied by the customer, e.g. build.customer-domain.com |
A single A record in the customer's zone pointing at this server. No wildcard needed, works with externally managed zones too |
Generated automatically: preview-<hash>.<panel-domain> |
A DNS wildcard record *.<panel-domain> (A/AAAA) pointing at this server |
The wildcard is therefore optional. It is only needed for the generated names — and for staging clones, which still use a generated name exclusively. The corresponding note sits under Settings → Panel → Panel URL.
SSL: The panel obtains a dedicated Let's Encrypt certificate for every
preview address over HTTP-01 — single hostnames need no DNS access. The attempt
runs when the preview is switched on and once a day thereafter, because the usual
order is "switch on, read the address, then add the record". Until then the
preview runs over http://; once the certificate is in place the address stored
inside WordPress is moved from http to https as well. Renewal is handled by
the certbot timer, not by the panel's SSL worker.
DNS check: The dialog that switches the preview on checks the entered name against DNS and reports four states — points here, points at a different server, no A record, could not be checked. The last state is deliberate: if the DNS query goes unanswered, or the panel knows no public server IP, no claim is made rather than asserting a missing record. For the two middle states the dialog shows the finished record ready to copy.
WordPress: Switching the preview on moves siteurl and home of the
website's WordPress installations (including serialized references inside the
content) to the preview address, and switching it off moves them back to the
domain. Without that, WordPress would redirect every request to the domain that
is not reachable yet. Staging installations are excluded.
Permission: perm_preview_url in the package. The toggle in the WordPress
toolkit sits on the installation's tile.
Staging (test copy)¶
Staging clones a website's files and databases into a separate environment with its own vhost. The live site and its database are not touched; push-to-live moves the copy back later (the agent snapshots production first).
| Permission | perm_staging in the package |
| Directory | /var/www/customers/<user>/.staging_<site-id> |
| Vhost | /etc/nginx/sites-enabled/<user>-staging-<address-with-hyphens>.conf |
| Address | supplied by the customer, otherwise generated (preview-<hash>.<panel-domain>, needs a wildcard) |
| Databases | one copy per production database, mapped in sites.staging_dbs (JSON) |
HTTPS: The staging vhost runs over http:// for as long as no real
certificate exists for its address, and only grows its HTTPS half once one does.
It used to be otherwise, and every staging environment greeted the customer with
a certificate warning — the HTTP half redirected unconditionally while the HTTPS
half fell back to the placeholder certificate (fixed in 2.9.96). The panel
obtains the certificate over HTTP-01 and re-renders the vhost afterwards; the
daily SSL pass retries both if the DNS record only arrives later.
PHP version: The staging vhost uses the version actually installed on the
server, not the one recorded in the database. With a site set to 8.3 on a server
that only has 8.4, the fastcgi_pass used to point at a socket that never
existed and staging answered 502 (fixed in 2.9.96).
Give the reload a moment
nginx -s reload returns immediately while the reload itself is
asynchronous. A check made right after creation still hits the default vhost
and looks like a failure. The X-Robots-Tag: noindex response header tells
you whether the staging vhost actually answered.
Cleanup: Deleting removes the directory, the vhost and the staging
databases. To check nothing was left behind, the number of *-staging-*.conf
files under /etc/nginx/sites-enabled/ must match SELECT count(*) FROM sites
WHERE staging_active=true.
Tab: Access Restrictions¶
- IP Restriction: Allow access only from specific IP addresses
- Password Protection: Protect directories via HTTP authentication
Tab: Logs¶
Access to the latest entries of the website logs:
- Access Log — Access logs
- Error Log — Error logs
Logs can be viewed directly in the browser or downloaded.
Enable / Disable Website¶
- Click the Status toggle in the detail view
- Disabled websites show a default error page
- The Nginx configuration is automatically updated
Delete Website¶
- Click the Delete icon
- Confirm the deletion
Note About Files
When deleting a website, the Nginx configuration and PHP-FPM pool are removed. The website files in the home directory are optionally preserved.
Composer Management¶
For websites with PHP projects, Composer is available directly in the panel:
- Open the website details
- Navigate to the Composer tab
- Available actions:
- composer install — Install dependencies
- composer update — Update dependencies
- Output is displayed in real time
Node.js and Python apps¶
Besides PHP, a website can run as a Node.js or Python app. The app runs as its own systemd service on an internal port; nginx reverse-proxies requests to it. Availability is granted per package via the Node.js/Python permission.
Creating¶
When creating the website, choose App type Node.js or Python. The following fields appear:
- Start command — the command that starts the app (e.g.
npm startorgunicorn app:app). The assigned port is available as$PORT. - Port — internal port; leave empty for automatic assignment.
- Environment variables — one
KEY=VALUEper line.
Managing (app runtime)¶
The Manage app action on the website opens the app-runtime dialog:
- Status (active / stopped / failed) with Start / Stop / Restart
- Edit start command, port and environment variables — saving reconfigures and restarts the app
- Install dependencies —
npm install(Node.js) orpip install -r requirements.txtin a venv (Python), run as the website user - Logs — the app service's recent output (journald)
- Runtime version — the Node/Python version is selectable per app (default = system version)
Runtime versions¶
A runtime version can be chosen per app, both when creating and in the app-runtime dialog. As an admin you can provision additional versions directly:
- Node.js — enter the major version (e.g.
20); enconf downloads the official binary and stores it under/opt/enconf/runtimes/node/<major>/. - Python — enter the minor version (e.g.
3.12); enconf installs the distribution packagepython3.<minor>-venv.
The version is then available in the picker. Node apps use the chosen node/npm; Python apps build their venv with the chosen interpreter.
Git Deployment¶
For automated deployment via Git:
- Open the website details
- Navigate to the Git tab
- Configure:
- Repository URL — HTTPS or SSH
- Branch — Branch to deploy (e.g.
main) - Auto-Deploy — Automatic deployment on push (webhook)
-
Deploy Key — SSH key for private repositories
-
Click Deploy Now for manual deployment
Deploy Hooks
After the Git pull, commands can be executed automatically (e.g. composer install, npm run build).
Error Pages (Error Documents)¶
Custom error pages can be configured for standard HTTP error codes:
- 403 — Forbidden
- 404 — Not Found
- 500 — Internal Server Error
- 502 — Bad Gateway
- 503 — Service Unavailable