Skip to content

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

  1. Click Create Website
  2. 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)
  1. 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_basedir restriction
  • 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

  1. Open Websites and click the Edit button of the desired website
  2. Change the Domain field to the new domain
  3. 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

  1. Click the Delete icon
  2. 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:

  1. Open the website details
  2. Navigate to the Composer tab
  3. Available actions:
  4. composer install — Install dependencies
  5. composer update — Update dependencies
  6. 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 start or gunicorn app:app). The assigned port is available as $PORT.
  • Port — internal port; leave empty for automatic assignment.
  • Environment variables — one KEY=VALUE per 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) or pip install -r requirements.txt in 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 package python3.<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:

  1. Open the website details
  2. Navigate to the Git tab
  3. Configure:
  4. Repository URL — HTTPS or SSH
  5. Branch — Branch to deploy (e.g. main)
  6. Auto-Deploy — Automatic deployment on push (webhook)
  7. Deploy Key — SSH key for private repositories

  8. 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