Monitoring

The alerts dashboard

Alerts are grouped by priority - from **P1** (most urgent) down to **P4** - and sorted so the most
critical issues are always at the top. They are split into four categories:

- **Alerts** - the main server and application checks in a non-OK state.
- **Mail Problems** - mail-specific issues, such as a growing mail queue or Sender Policy Framework (SPF) or Domain Name System (DNS) warnings.
- **Security Issues** - hosts with security or system packages that still need updating (for example
  an `apt` check reporting critical updates to apply).
- **Other** - lower-priority signals worth reviewing but not urgent.

Each alert names the affected host and service (for example a disk, swap, certificate, or
cache-hit-ratio check) with a short status message and how long it has been active. Selecting an
alert row opens the alert detail page for that check. The host name in
the row is a separate link and opens the host instead. The dashboard refreshes as new alerts
arrive.


Monitoring

The alert detail page

monitoring alerts alert detail incident reports create ticket P1 P2 P3 health dashboard fleet alerts

Selecting an alert opens a page for that one service check, at `/monitoring/<host>!<check>`. The
heading shows the host name followed by the check name, and the host name links to the host. You
also reach this page from the CPU, RAM and Disk graphs on a host's Health tab,
which open it in a new browser tab.

The page reads the current state from monitoring every time you open it. It has three panels and
one action:

- Status - the current state and the check output
- Graph - the measured values over time
- Incident reports - reports written about this check
- Create a ticket - hand the alert over to support

Select a panel header to collapse or expand it.

> [!NOTE]
> If the check no longer exists in monitoring, the page reports that it cannot be found. Go back
> to the dashboard and pick a current alert.


Monitoring

Status

A badge next to the panel title shows the current state: **OK**, **WARNING**, **CRITICAL** or
**UNKNOWN**. The panel lists:

| Field | What it tells you |
| --- | --- |
| **Since** | How long the check has been in this state, with the date and time it changed. |
| **Groups** | The monitoring groups this check belongs to. |
| **Plugin Output** | The message the check returned. It usually names the exact problem, for example a filesystem that is nearly full or a certificate that is about to expire. |

Each field is shown only when there is a value for it.


Monitoring

Graph

The **Graph** panel plots what the check measured. Use the **1H / 8H / 1D / 7D** buttons to change
the time range, from one hour to seven days. The panel is not shown for checks that record no
measurements, such as a check that only reports a state.

> [!TIP]
> Compare the 1-hour and 7-day views before you act. A single short spike is usually harmless; a
> line that climbs day after day needs attention.


Monitoring

Incident reports

When incident reports exist for this host and check, they are listed here, with the number of
reports next to the panel title. Each entry shows the report title, the alarm it relates to, and
how long ago it was written.

- **Open report** shows the full report in a window on top of the page.
- **PDF** opens the same report as a Portable Document Format (PDF) file in a new browser tab,
  where you can read or save it. The button appears only when a PDF version exists.

The report window has the same **PDF** button in its header. Select **Close** or the cross in the
header to return to the alert.


Monitoring

Create a ticket

**Create ticket**, at the top right of the page, opens the Hosted Power ticket portal in a new
browser tab. The subject is filled in with the host name and the check, so you do not have to
retype it. Use it when an alert needs follow-up from the support team - see
Support.


Monitoring

Per-host health

For the live health of a single host - top issues, CPU/memory/disk usage and individual service
checks - open that host's Health tab.


Monitoring

Understanding the metrics

The per-host view (and the Health tab) report four core resource metrics:

| Metric | What it means |
|---|---|
| **CPU usage** | How busy the processor is. Sustained high values mean the host is CPU-bound. |
| **RAM usage** | Used memory. Consistently high RAM with rising swap points to memory pressure. |
| **Memory swap** | Memory spilled to disk. Steady swap use hurts performance - a sign to investigate. |
| **Disk usage** | How full each filesystem is. A full disk causes failures; act before it fills. |

Each service the host runs (web server, databases, Redis, search, mail, certificates, and more) is also
checked individually and reports OK / Warning / Critical.


Monitoring

Alert priorities

Alerts are grouped by priority so you can triage quickly:

| Priority | Meaning |
|---|---|
| **P1** | Critical - something is down or broken and impacting the server. Needs immediate action. Max resolution time: **immediate**. |
| **P2** | Very urgent - down, broken or degraded. Max resolution time: **1 hour**. |
| **P3** | Urgent - a problem that could escalate if left unhandled. Max resolution time: **4 hours**. |
| **P4** | Not urgent - worth reviewing for long-term stability. Max resolution time: **48 hours**. |

> [!IMPORTANT]
> Not every alert is equally urgent, and not all of them need action. Triage them in order:
>
> - **P1 and P2 first** - these affect, or are about to affect, your live sites. Act on them right away.
> - **P3 next** - look at these when you have time; usually a trend to watch rather than an outage.
> - **P4 is optional** - informational only, fine to review during normal maintenance.
>
> Working top-down (P1 first) keeps your attention on what actually impacts visitors.

Alerts are also grouped by type, such as **Mail Problems** and **Other**. Hosted Power's team
monitors these alerts; follow up through Support for anything affecting your sites.


Monitoring

How monitoring works

TurboStack monitors your infrastructure and applications, and can integrate application
performance monitoring. For the underlying tools and what each provides, see
Monitoring (concepts).


Monitoring

Related

- Health (per host)
- Monitoring concepts
- Support
- Hosts


Platform Updates

platform updates release notes changelog announcements

# Platform Updates

Platform Updates is a date-ordered feed of release notes, new features and announcements about the TurboStack Platform. Check it to stay informed about changes that may affect how you work.


Platform Updates

What you'll find

Entries typically cover:

- **New features** and improvements to the platform.
- **Fixes** to existing behavior.
- **Security notices** and recommended actions.
- **Breaking changes** to be aware of.

> [!IMPORTANT]
> Some updates only take effect on your servers after a **full publish** of the host - an entry
> says so when that applies. See Publishing changes.


Platform Updates

Viewing updates

Open the feed from the **Platform updates** link in the page footer (at `/platform-updates`). The newest entries appear first, so the most recent changes are always at the top.

1. Go to `/platform-updates`.
2. Browse the feed from newest to oldest.
3. Open an entry to read its full details.

> [!TIP]
> Visit Platform Updates regularly so you do not miss new features or important announcements.


Platform Updates

Related

- Changelog - dated release notes in the documentation
- Support
- Introduction


Search

search global search find host find group find template

# Search

Global search lets you find matches across all of your hosts, groups and templates in a single place. Use it to jump directly to what you are looking for without browsing each list in turn.


Search

Using global search

Open global search at `/search`. As you type, results appear instantly and update with each keystroke, so you can refine your query until you find the right match.

1. Go to `/search`.
2. Start typing the name of a host, group or template.
3. Review the matching results, which are grouped by type.
4. Select a result to open it directly.

When there are many matches, results are paginated. Use the pagination controls to move through additional pages.


Search

Global search versus list filters

Global search is different from the search boxes on the **Hosts**, **Groups** and **Templates** pages:

- **Global search** (`/search`) looks across all hosts, groups and templates at once.
- **List search boxes** filter only the list you are currently viewing. For example, the search box on the Hosts page filters that list of hosts only.

> [!TIP]
> Use a per-list search box when you are already on a page and want to narrow that list. Use global search when you are not sure where something lives or want to move quickly between different types of items.


Search

Common tasks

- **Jump to a host by name** when you know what you are looking for but not where it is.
- **Find a group** to review or update its members.
- **Locate a template** before applying it to a host.


Search

Related

- Managing Hosts
- Groups
- Templates
- Navigating the Interface


Support

support contact help SLA service level agreement terms of service TOS general conditions contract report issue

# Support

The Support page brings together the different ways to get help with TurboStack when you need more than the documentation can offer.


Support

What you will find

On the Support page you can find:

- **Contact details**, including phone and email, for reaching the support team.
- **Links to documentation** for self-service help.
- **Service Level Agreement (SLA) and service information** describing the support you can expect.


Support

Service Level Agreement and Terms of Service

The Support page links to your SLA. Both documents are published on the Hosted Power website:

| Document | Link |
| --- | --- |
| **Service Level Agreement (SLA)** - the service levels, response times and support commitments that apply to your environment. | https://www.hosted-power.com/en/service-level-agreement-legal |
| **Terms of Service** - the general conditions of your contract with Hosted Power. | https://www.hosted-power.com/en/tos |

The published documents are the binding versions. For questions about which agreement applies to your
account, contact sales.


Support

Contact the service desk

Reach the support team by email at support@hosted-power.com or by
phone:

| Region | Phone |
| --- | --- |
| Belgium | +32 53 599 000 |
| Netherlands | 085 888 4 555 |
| France | 04 83 97 97 97 |

Office hours are **Monday to Thursday, 08:45 - 17:30** and **Friday, 08:45 - 16:30**. Outside those
hours, use the emergency service below.


Support

Round-the-clock emergency service

When the service desk is closed, an emergency service runs around the clock for failures that cause
the **critical unavailability** of services Hosted Power is contracted to provide or support. Access
to the emergency hotline is included when your **Service Level Agreement (SLA)** covers it; you can
find the number in your Hosted Power Customer Center. Report the issue by phone first, then send a
confirming email to support@hosted-power.com describing it (unless
agreed otherwise).

TurboStack also monitors your environments proactively, 24 hours a day, 7 days a week, so many
problems are caught before they affect your site. When a critical situation is detected, an on-call
procedure starts and an on-call engineer responds within the response time set by your SLA - for
example under 30 minutes on a Standard SLA, or under 15 minutes on a Platinum SLA.
If the issue is not resolved, it follows a fixed escalation path: from the operations engineer to the
technical team lead, and, if needed, to the CEO. For **commercial** matters the escalation follows a
separate path, starting with your **account manager** and moving to the COO and, if needed, the CEO.


Support

Critical and non-critical issues

When you report an issue, TurboStack decides whether it is a critical unavailability. This analysis
happens within the Service Level Agreement (SLA) response time and is done remotely, by phone,
email, or monitoring tools.

A **critical** issue is anything that prevents the correct functioning of your server and needs
immediate attention. This covers defects in the data center infrastructure, the network, the
hardware, and the server services that cause a proven unavailability of the services provided.

A **non-critical** issue is any other question that does not cause unavailability. Examples include:

- Questions about how to use the services.
- Software support for applications TurboStack provides.
- Configuration changes that are not needed to fix a critical problem.

Non-critical issues are also analyzed within the SLA response time and handled remotely. You may be
asked for more information, or to carry out simple checks or changes together with the support team.


Support

When to use Support

Use the Support page when you need help beyond the documentation - technical and operational issues. You can also contact Support to enable platform features that Hosted Power provisions, such as Virtual Private Network (VPN) or high availability. For **commercial** questions - plans, pricing, upgrades or contracts - contact sales instead.

> [!NOTE]
> Some features, such as those described in Networking, are provisioned by Hosted Power. Contact Support through this page to request them.


Support

Before you contact support

Many issues have a self-service fix - check these first:

- The host's Health tab and the Monitoring dashboard.
- Recent deployments in History, and the application's troubleshooting page
  under Applications.
- The general Troubleshooting page.


Support

What to include in a request

For a faster answer, include:

- The **host name** and the **application/domain** affected.
- **What you expected** versus **what happened**, and when it started.
- Any **error message** or relevant **log output** (see the application's Troubleshooting page).
- Whether a recent **publish/deploy** preceded the problem.


Support

Related

- Troubleshooting
- Networking
- Platform Updates
- Introduction


Templates

templates host configuration reusable setup server provisioning

# Templates

Templates are pre-built, reusable host configurations. Use them to standardize how new servers are set up, save time, and ensure consistency across your hosts. If you set up similar servers often, such as when onboarding a new project, save the configuration once as a template and reuse it.


Templates

Global and custom templates

TurboStack provides a set of global default templates to get you started. You can also create your own custom templates that capture the exact configuration your projects need.


Templates

Viewing templates

To see all available templates, open `/templates`. Select any template to open it at `/templates/{template}` and review or edit its configuration.


Templates

Creating a template

1. Go to `/templates`.
2. Select `Create`.
3. In the modal, enter a name for the template.
4. Optionally add an `image` or `icon` to make the template easy to recognise.
5. Confirm to create the template and open it for editing.

Creating a template opens the YAML editor. Here you paste a generalized configuration of a server
that you want to reuse. This is useful when you regularly deploy servers with a similar setup, such
as a fixed MySQL version or a common set of PHP packages.

Here is an example template that sets up an Odoo application behind Nginx:

```yaml
---
webserver: nginx

postgresql_version: 16

os_extra_packages:
- libxml2-dev
- libxslt1-dev
- libldap2-dev
- libsasl2-dev

system_users:
- username: prod
  vhosts:
  - server_name: example.com www.example.com
    app_name: odoo
    app_type: odoo
    python_version: 3.10.17
    docker_enabled: true
    cert_type: selfsigned
```

See The Source (YAML) view for how the YAML editor maps to the GUI
configuration.


Templates

Editing a template

1. Open the template from `/templates`.
2. Adjust the configuration to suit your needs.
3. Save your changes.

> [!TIP]
> Keep a small number of well-maintained templates rather than many similar ones. This makes it easier to apply a consistent setup across every new host.


Templates

Applying a template to a host

You install a template's configuration onto a host to apply its settings. A host only accepts a
template while its configuration is still empty, because installing a template overrides any
existing settings. When a host's configuration is empty, TurboStack shows a banner above the
configuration to tell you so.


Templates

Install a template onto a host

1. Open the host and confirm the empty-configuration banner is shown.
2. In the left-hand menu, select `Templates`.
3. On the template you want, select `Install`. This opens the template setup window.
4. Choose the server you want to install the template to from the drop-down menu.
5. Enter the `server name`, the URL you want your application to be reachable at.
6. Fill in any remaining configuration options, then select `Install` to send the configuration to
   the server.
7. Return to the host's page. The new application is added to the configuration.
8. Select `Save & publish` to deploy the configuration to your server.

> [!IMPORTANT]
> Installing a template only fills in the configuration. Nothing is deployed until you select
> `Save & publish`.


Templates

Pre-fill a host from a template

As an alternative to installing from the **Templates** page, you can pre-fill an empty host
configuration with the `Copy` option:

1. Open the host you want to configure.
2. Select `Copy`.
3. Choose `From template`.
4. Select the template you want to use.

The host's configuration is filled in from the template, ready for you to review and adjust.

> [!NOTE]
> Both methods only work on hosts whose configuration has not yet been set. See
> Managing hosts for more on the `Copy` options.


Templates

Common use cases

- Standardize the setup of every new server.
- Save time by reusing a known-good configuration.
- Ensure consistency across hosts that serve the same role.


Templates

Related

- Managing hosts
- Groups


Troubleshooting

troubleshooting common issues publish changes certificate credentials

# Troubleshooting

This page covers common questions and how to resolve them. Each item includes a short answer and a link to the relevant documentation.


Troubleshooting

My changes aren't visible on the server

Configuration changes are stored in TurboStack until you deploy them. You must **publish** your changes for the server to match your configuration. See Publishing changes.


Troubleshooting

A deployment failed

Open the **Deploys** tab in the host's History to read the logs and find the cause. Fix the configuration, then publish again. See History.


Troubleshooting

My Let's Encrypt certificate isn't issuing

For the `http` challenge, the domain must point to the server so the challenge can be completed. For wildcards or domains that do not yet point to the server, use the `dns` challenge instead. See Applications.


Troubleshooting

Where do I find server/database credentials?

Server and database credentials are available on the **Credentials** tab. See Credentials.


Troubleshooting

I can't sign in / two-factor problems

Review the Two-factor authentication guide. If you are locked out, contact support.


Troubleshooting

I need more help

If your issue is not covered here, reach out for assistance. See Support.

> [!TIP]
> When reporting a problem to support, include the host name, the time of the issue, and any relevant deployment logs to speed up diagnosis.


Troubleshooting

Related

- Publishing changes
- History
- Support
- TurboStack CLI - reload services, clear caches and inspect the firewall over SSH


Application parameters

vhost parameters application yaml server_name app_type php_version cert_type git

<!-- GENERATED FILE - do not edit. Source: data/yaml-parameters.yml -->

# Application parameters

Every key on this page is set per application, under `system_users[].vhosts[]`.
A [!badge variant="success" text="GUI"] key has a field in the interface; a
[!badge variant="warning" text="YAML only"] key is set in the
Source (YAML) view, which accepts the same configuration.


Application parameters

Domain and application type

Every application needs at least a domain and a certificate. The application type tells
TurboStack which software to provision and configure.

**Example** - every key in this section, with realistic values:

```yaml
system_users:
  - username: prod
    vhosts:
      - server_name: example.com www.example.com
        app_type: wordpress       # leave empty for a plain PHP site
        app_install: true         # run the installer, not just prepare the config
        app_name: shop            # only for a second app under the same user
        monitoring_url: /health    # what uptime monitoring requests
```


Application parameters

`server_name`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="danger" text="required"]

The domain names this application answers on, separated by spaces. This is the application's address. Without it the application is not reachable.

**Note:** required. Must be unique across the host.


Application parameters

`app_type`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

For example `wordpress`, `magento2`, `shopware`, `laravel`, `odoo`, `generic` - the GUI dropdown lists the values available now.

Tells TurboStack which application to provision, so it applies the right web server rules, caching and file layout. Saves you from configuring the stack by hand for a known application.

**Note:** leave it empty for a plain PHP site. The GUI dropdown lists the currently supported types.


Application parameters

`app_install`

[!badge variant="info" text="boolean"] [!badge variant="warning" text="YAML only"]

Default `false`.

Actually runs the installer for the chosen application type, instead of only preparing the configuration. Get a working installation without downloading and installing the software yourself.


Application parameters

`app_name`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

Names a secondary application under the same system user, in its own subfolder. Run several applications under one account, for example a shop and a separate blog.

**Note:** lowercase letters and digits, starting with a letter, at most 33 characters. Only one application per user may leave this empty.


Application parameters

`monitoring_url`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

The URL that uptime monitoring requests for this application. Point monitoring at a health-check endpoint instead of the homepage.


Application parameters

Certificates


Application parameters

`cert_type`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="danger" text="required"]

One of `letsencrypt`, `selfsigned`, `custom`.

Selects where the certificate comes from - issued automatically, self-signed, or supplied by you. Choose `letsencrypt` for free automatic HTTPS that renews itself, or `custom` for a certificate you bought.

**Note:** required once `server_name` is set.


Application parameters

`cert_fullchain`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

The certificate chain, in PEM format, for a certificate you supply yourself. Use a certificate from your own supplier, for example an extended-validation certificate.

**Note:** only with `cert_type: custom`. Must match `cert_pvk`, which is verified before deployment.


Application parameters

`cert_pvk`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

The private key, in PEM format, belonging to `cert_fullchain`. Required alongside your own certificate.

**Note:** only with `cert_type: custom`.

> [!WARNING]
> A mismatch between key and certificate stops the deployment.


Application parameters

`cert_challenge`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"]

One of `http`, `dns`. Default `http`.

How ownership of the domain is proven when a certificate is issued. Domain Name System (DNS) validation is the only way to get a wildcard certificate, and it works before the domain points at the server.


Application parameters

`cert_provider`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"]

One of `hostedpower`, `cloudflare`.

Which DNS provider is used for DNS validation. Lets the platform create the validation record for you automatically.

**Note:** only with `cert_challenge: dns`.


Application parameters

`cert_cloudflare_api_token`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The API token used to create the DNS validation record. Needed when your domain is managed at Cloudflare and you use DNS validation.

**Note:** only with `cert_provider: cloudflare`.


Application parameters

Runtimes

Each application picks its own runtime and version, so applications on one host can run
different versions side by side. Setting the version key is what enables that runtime -
there is no separate "enable" key.

Prefer a version that is still supported. Older versions keep working if your application
needs them, but they may no longer receive security updates, so plan to upgrade one
application at a time. The GUI dropdown always lists the versions available now.

**Example** - every key in this section, with realistic values:

```yaml
system_users:
  - username: prod
    vhosts:
      - server_name: example.com
        php_version: "8.4"           # one runtime per application
        # nodejs_version: "24"       # Node.js app (usually with proxy_enabled)
        # python_version: "3.13"     # Python app
        # ruby_version: "3.4"        # Ruby app
        # ruby_start_cmd: bundle exec puma -C config/puma.rb
        # ruby_sidekiq: true
        # ruby_sidekiq_cmd: bundle exec sidekiq -q default
        # dotnet_version: "10.0"     # .NET app
        docker_enabled: false        # run a containerized app
        k8s_enabled: false           # run Kubernetes workloads
        rabbitmq_enabled: false      # give this app a message broker
```


Application parameters

`php_version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

For example `8.2`, `8.3`, `8.4` - the GUI dropdown lists the values available now.

The PHP version this application runs on, with its own process pool. Match the version your application supports, and upgrade one application at a time.

**Note:** quote the value, for example `"8.4"`. The GUI dropdown lists the installed versions.


Application parameters

`nodejs_version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

For example `22`, `24` - the GUI dropdown lists the values available now.

Installs the given Node.js major version for this application. Run a Node.js application. Setting this key is what enables the runtime.

**Note:** quote the value, for example `"24"`. Usually combined with `proxy_enabled`.


Application parameters

`python_version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

For example `3.12`, `3.13` - the GUI dropdown lists the values available now.

Installs the given Python version for this application. Run a Python application.


Application parameters

`ruby_version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

For example `3.3`, `3.4` - the GUI dropdown lists the values available now.

Installs the given Ruby version for this application. Run a Ruby application such as Rails.


Application parameters

`ruby_start_cmd`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: A standard Puma start command.

The command used to start the Ruby application server. Use a different application server than the default.


Application parameters

`ruby_sidekiq`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `false`.

Runs a Sidekiq background-worker service for this application. Process background jobs for a Ruby application.


Application parameters

`ruby_sidekiq_cmd`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Overrides the command used to start Sidekiq. Pass your own queue or concurrency options.


Application parameters

`dotnet_version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

For example `8.0`, `10.0` - the GUI dropdown lists the values available now.

Installs the given .NET version and runs your application as a service behind the web server. Run a .NET application.


Application parameters

`docker_enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"]

Default `false`.

Allows this application's system user to run containers. Run a containerized application, with the web server proxying to the container.

**Note:** usually combined with `proxy_enabled` and `proxy_upstream_port`.


Application parameters

`k8s_enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `false`.

Installs a lightweight Kubernetes orchestrator on the host. Run container workloads that need orchestration.


Application parameters

`rabbitmq_enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"]

Default `false`.

Provisions a message-broker account for this application, and installs the broker on the host if needed. Applications that process work in the background, such as OroCommerce, need a message broker.


Application parameters

Application code from a Git repository

TurboStack can clone a Git repository for an application and update it on every publish, so
the code on the server always matches the branch or tag you chose. Add repositories in the
interface under **Configure application**, on the **GIT** tab.

**Example** - every key in this section, with realistic values:

```yaml
system_users:
  - username: prod
    vhosts:
      - server_name: example.com
        git:
          - repo: git@github.com:example/shop.git
            version: main            # branch, tag or commit
            path: public_html        # relative to the account's own folder
```


Application parameters

`git`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

The repositories that are cloned and kept up to date for this application. Deploy from your own repository instead of copying files to the server by hand.

**Note:** the clone runs as the account that owns the application, so the files get the right owner straight away.


Application parameters

`git.repo`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="danger" text="required"]

The address of the repository to clone, either an HTTPS or an SSH address. Tells the platform where your code lives.

**Note:** required for every entry. An entry without it is skipped.


Application parameters

`git.version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

Default `main`.

Which branch, tag or commit is checked out. Follow a branch on a staging host, and pin a production host to a released tag.


Application parameters

`git.path`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

Default: The account's own folder.

Where the repository is placed, relative to the account's folder. Put the code straight into the folder the application is served from, for example `public_html`.

**Note:** the path is read as relative to the account's folder, so a leading slash is ignored. Leave it empty to clone into the account's folder itself.


Application parameters

Caching and proxying

Use these to put a cache in front of an application, or to publish an application that runs
as its own process such as Node.js, Python or a container.

**Example** - every key in this section, with realistic values:

```yaml
system_users:
  - username: prod
    vhosts:
      - server_name: example.com
        varnish_enabled: true        # full-page cache (PHP storefronts)
        # For a Node.js/Python/.NET/container app instead:
        # proxy_enabled: true
        # proxy_upstream_port: 3000   # local port your app listens on
        # proxy_upstream_host: 127.0.0.1
```


Application parameters

`varnish_enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"]

Default `false`.

Puts this application behind the full-page cache. The single biggest speed win for PHP storefronts such as Magento and Shopware.

**Note:** nothing at host level - turning this on is what installs Varnish on the host, and the platform picks the version. The host keys under Caching and queues only tune it. Do not use this for Node.js applications.


Application parameters

`proxy_enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"]

Default `false`.

Makes the web server forward requests to an application running on a local port. The standard way to publish a Node.js, Python, .NET or containerized application.


Application parameters

`proxy_upstream_port`

[!badge variant="info" text="integer"] [!badge variant="secondary" text="port"] [!badge variant="success" text="GUI"] [!badge variant="danger" text="required"]

Default `3000`.

The local port your application listens on. Tells the web server where to send the requests.

**Note:** required when `proxy_enabled` is true.


Application parameters

`proxy_upstream_host`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `127.0.0.1`.

The address the web server forwards to. Only change it when the application runs somewhere other than this server.


Application parameters

PHP tuning

These override the automatically tuned PHP process pool for one application. The defaults
suit almost every site - change them only with measured evidence.

**Example** - every key in this section, with realistic values:

```yaml
system_users:
  - username: prod
    vhosts:
      - server_name: example.com
        php_version: "8.4"
        # Override the auto-tuned PHP-FPM pool only with evidence:
        php_fpm_pm_max_children: 40
        php_fpm_pm_start_servers: 8
        php_fpm_pm_min_spare_servers: 5
        php_fpm_pm_max_spare_servers: 12
        php_fpm_pm_max_requests: 500
        php_enhance: true            # skip file-change checks (reload after deploy)
        php_opcache_preload_script: /var/www/prod/example.com/config/preload.php
        php_user_tmp_dir: true       # dedicated temp folder for this app
```


Application parameters

`php_fpm_pm_max_children`

[!badge variant="info" text="integer"] [!badge variant="secondary" text="count"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default: Inherited from the host.

The maximum number of PHP processes this application may run at once. Raise it for a busy application, lower it to stop one application using all the memory.

> [!WARNING]
> Too high a value can exhaust server memory and take down every application on the host.


Application parameters

`php_fpm_pm_start_servers`

[!badge variant="info" text="integer"] [!badge variant="secondary" text="count"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Inherited from the host.

How many PHP processes are started immediately. Reduces warm-up delay after a restart on a busy application.


Application parameters

`php_fpm_pm_min_spare_servers`

[!badge variant="info" text="integer"] [!badge variant="secondary" text="count"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Inherited from the host.

The minimum number of idle PHP processes kept ready. Absorbs traffic spikes without waiting for new processes.


Application parameters

`php_fpm_pm_max_spare_servers`

[!badge variant="info" text="integer"] [!badge variant="secondary" text="count"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Inherited from the host.

The maximum number of idle PHP processes kept ready. Frees memory again after a spike.


Application parameters

`php_fpm_pm_max_requests`

[!badge variant="info" text="integer"] [!badge variant="secondary" text="count"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default: Inherited from the host.

How many requests a PHP process handles before it is recycled. Recycling limits the impact of memory leaks in application code.


Application parameters

`php_enhance`

[!badge variant="info" text="boolean"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default `false`.

Stops PHP from checking whether source files changed on disk. A real speed gain on production applications that are deployed, not edited live.

> [!WARNING]
> Code changes are ignored until PHP is reloaded. Never use it on a site you edit directly.


Application parameters

`php_opcache_preload_script`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Loads your framework into memory once at startup, instead of on every request. A large speed gain for frameworks that support preloading, such as Symfony and Laravel.

**Note:** only one application per PHP version may set this, and the file must exist. Otherwise the deployment fails.


Application parameters

`php_user_tmp_dir`

[!badge variant="info" text="boolean"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default `false`.

Gives this application its own temporary folder instead of the shared one. Keeps sessions and uploads separated between applications on the same host.


Application parameters

Performance monitoring

Connect an external application-performance monitoring product to a single application.

**Example** - every key in this section, with realistic values:

```yaml
system_users:
  - username: prod
    vhosts:
      - server_name: example.com
        newrelic_appname: "Example production"
        newrelic_license: "nr_xxxxxxxxxxxx"
        # Tideways instead of, or next to, New Relic:
        tideways_apikey: "tw_xxxxxxxxxxxx"
        tideways_service: web
        tideways_sample_rate: 25
```


Application parameters

`newrelic_appname`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The name this application reports under in New Relic. Recognise the application in your monitoring dashboard.


Application parameters

`newrelic_license`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The licence key used to send performance data. Enables application performance monitoring for this application only.


Application parameters

`tideways_apikey`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The key used to send profiling data to Tideways. Find slow code paths in a PHP application.


Application parameters

`tideways_service`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The service name this application reports under. Separate several applications in the same Tideways account.


Application parameters

`tideways_sample_rate`

[!badge variant="info" text="integer"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

What percentage of requests is profiled. Lower it to reduce the overhead of profiling on a busy site.


Application parameters

Related

- YAML configuration reference
- The Source (YAML) view
- Publishing changes


Host service parameters

host yaml webserver mysql_version redis varnish elasticsearch services dkim mail_devtool

<!-- GENERATED FILE - do not edit. Source: data/yaml-parameters.yml -->

# Host service parameters

Every key on this page is set once per host, at the top of the configuration.
A [!badge variant="success" text="GUI"] key has a field in the interface; a
[!badge variant="warning" text="YAML only"] key is set in the
Source (YAML) view, which accepts the same configuration.


Host service parameters

Web server

One web server runs per host and serves every application on it.

**Example** - every key in this section, with realistic values:

```yaml
webserver: nginx             # nginx | apache2
# da_webserver: nginx_apache # DirectAdmin hosts only - the panel builds its own web server
```


Host service parameters

`webserver`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"]

One of `nginx`, `apache2`. Default `nginx`.

Selects the web server for this host. Nginx suits almost every workload. Choose Apache when an application needs `.htaccess` files or Apache modules.


Host service parameters

`da_webserver`

[!badge variant="info" text="enum"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

One of `apache`, `nginx`, `nginx_apache`. Default: `nginx_apache` when TurboShield is on, otherwise `apache`.

Which web server the DirectAdmin control panel builds and runs. `nginx_apache` puts Nginx in front of Apache, which keeps `.htaccess` support while Nginx serves the traffic. A DirectAdmin host manages its own web server, so it needs a separate setting from `webserver`.

**Note:** only on hosts that run the DirectAdmin control panel. Every other host chooses its web server with `webserver`.


Host service parameters

Databases

Enable the database your application needs and pick its version. You rarely need to set a
memory size. The platform sizes the database to the server's memory for you and re-tunes it
every time you publish, so the sizing grows automatically as the server grows. Only set a
size key when a measurement shows the automatic value is wrong for your workload.

Prefer a version that is still supported. Older versions keep working, but may no longer
receive security updates. The GUI dropdown lists the versions available now.

**Example** - every key in this section, with realistic values:

```yaml
# MySQL (Percona) - most PHP apps
mysql_version: "8.4"           # 5.7 | 8.0 | 8.4
mysql_innodb_size: 8G          # buffer pool, auto-tuned; override with evidence
mysql_bindaddress: 127.0.0.1   # keep restricted to trusted networks
mysql_server: true
# mysql_timezone: Europe/Brussels   # default DB time zone
# Split app/database-server topology instead:
# mysql_server_only: true
# mysql_client_host_name: db1.example.com
# mysql_client_host_ip: 10.0.0.5

# PostgreSQL - Odoo, Medusa and others
postgresql_version: "17"
postgresql_shared_buffers: 8GB
postgresql_extensions: [pg_stat_statements]
postgresql_listen_addresses: localhost
postgresql_extra_access:
  - {type: host, database: appdb, user: reporting, address: 10.0.0.0/24, auth_method: scram-sha-256}
# postgresql_client_only: true
# postgresql_client_host_name: db1.example.com
# postgresql_client_host_ip: 10.0.0.5

# MongoDB
mongodb_version: "8.0"         # 7.0 | 8.0
mongodb_bindip: 127.0.0.1

# Microsoft SQL Server - .NET apps
mssql_version: "2022"          # 2019 | 2022 | 2025 (depends on the server OS)
mssql_edition: Developer       # Developer | Enterprise | Express | Standard | Web
```


Host service parameters

`mysql_version`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"]

One of `5.7`, `8.0`, `8.4`.

Installs MySQL in the given version. Leave it out, or set `0`, to not install it. The database most PHP applications use, including WordPress, Magento and Shopware.

> [!WARNING]
> Changing the major version on a live host is a migration, not a setting. Plan and test it.


Host service parameters

`mysql_innodb_size`

[!badge variant="info" text="string"] [!badge variant="secondary" text="size (MB/GB)"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Tuned to the server.

How much memory MySQL uses to cache data and indexes (the InnoDB buffer pool). The platform sets this to the server's memory automatically and re-tunes it on every publish, so it grows as the server grows. It is the most effective database performance setting, but only override the automatic value with measured evidence.


Host service parameters

`mysql_bindaddress`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Local only.

Which network addresses MySQL accepts connections on. Give an address, or the keyword `ANY` to listen on every interface. Needed when a separate application server must reach this database.

**Note:** on a host that runs Kubernetes or Docker, MySQL listens on every interface unless you set this key yourself.

> [!WARNING]
> `ANY` puts the database on every interface, including any public one. Exposing a database to the public internet is a serious risk - give a specific private address and restrict access with the firewall.


Host service parameters

`mysql_server`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `true`.

Whether the database server itself is installed. Set it to false on an application server that only needs the client tools.


Host service parameters

`mysql_server_only`

[!badge variant="info" text="boolean"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default `false`.

Installs only the database server, without the local application-side setup. For a dedicated database server that hosts no applications.


Host service parameters

`mysql_client_host_name`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Points this server's database client at a database on another server. Split application and database across two servers.


Host service parameters

`mysql_client_host_ip`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The address of that remote database server. Used together with `mysql_client_host_name`.


Host service parameters

`mysql_timezone`

[!badge variant="info" text="string"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default: The server's time zone.

Sets the default time zone of the MySQL database server. Make database timestamps match the time zone your application expects, regardless of the server's own time zone.


Host service parameters

`postgresql_version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

For example `16`, `17`, `18` - the GUI dropdown lists the values available now.

Installs PostgreSQL in the given version. The database used by Odoo and Medusa, and an option for several other applications.

> [!WARNING]
> Changing the major version on a live host is a migration. Plan and test it.


Host service parameters

`postgresql_shared_buffers`

[!badge variant="info" text="string"] [!badge variant="secondary" text="size (MB/GB)"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Tuned to the server.

How much memory PostgreSQL uses for caching (shared buffers). The platform sets this to the server's memory automatically and re-tunes it on every publish, so it grows with the server. It is the main PostgreSQL performance setting, but only override the automatic value with measured evidence.


Host service parameters

`postgresql_extensions`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

One of `vector`, `postgis`, `timescaledb`, `pg_stat_statements`. Default `empty`.

Enables extra PostgreSQL extensions. Adds capabilities such as geographic data or vector search.

**Note:** only these four names are accepted. Any other value stops the deployment with an error.


Host service parameters

`postgresql_listen_addresses`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Local only.

Which addresses PostgreSQL accepts connections on. Give an address, or the keyword `ANY` to listen on every interface. Needed for a separate application server.

**Note:** on a host that runs Kubernetes or Docker, PostgreSQL listens on every interface unless you set this key yourself.

> [!WARNING]
> `ANY` puts the database on every interface, including any public one. Give a specific private address and restrict access with the firewall.


Host service parameters

`postgresql_extra_access`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `empty`.

Extra access rules stating which user may reach which database from which address. Grant a specific external system access without opening the database entirely.


Host service parameters

`postgresql_client_only`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `false`.

Installs only the client tools, not the server. For an application server that connects to a database elsewhere.


Host service parameters

`postgresql_client_host_name`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Points this server's database client at a PostgreSQL database on another server. Split application and database across two servers.

**Note:** used with `postgresql_client_only` and `postgresql_client_host_ip`.


Host service parameters

`postgresql_client_host_ip`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The address of that remote PostgreSQL server. Used together with `postgresql_client_host_name`.


Host service parameters

`mongodb_version`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

One of `7.0`, `8.0`.

Installs MongoDB in the given version. For applications that store documents rather than tables.


Host service parameters

`mongodb_bindip`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Local only.

Which addresses MongoDB accepts connections on. Give a comma-separated list of addresses, or the keyword `ANY` to listen on every interface. Needed for a separate application server.

**Note:** on a host that runs Kubernetes or Docker, MongoDB listens on every interface. Unlike the other databases it does so even when this key is set to `127.0.0.1`, so give a specific private address if you need to keep it narrow.

> [!WARNING]
> `ANY` puts the database on every interface, including any public one. Give specific private addresses and restrict access with the firewall.


Host service parameters

`mssql_version`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

One of `2019`, `2022`, `2025`.

Installs Microsoft SQL Server. Required by .NET applications such as nopCommerce.

**Note:** which versions are available depends on the server operating system.


Host service parameters

`mssql_edition`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

One of `Developer`, `Enterprise`, `Express`, `Standard`, `Web`.

Which SQL Server edition is installed. Editions differ in features and licensing. The GUI dropdown lists the available ones.


Host service parameters

Caching and queues

Caching keeps your application fast, and a message broker lets it process work in the
background. As with the databases, the cache sizes (`redis_memory`, `varnish_cache_size`)
are set to the server's memory automatically and re-tuned on every publish, so they grow
with the server. Only override a size when a measurement shows you need to.

**Example** - every key in this section, with realistic values:

```yaml
redis_enabled: true
redis_memory: 2gb             # cache instance maxmemory
# redis_persistent_memory: 1gb  # persistent (on-disk) instance maxmemory
redis_listen_addresses: localhost
# Varnish is installed by turning on varnish_enabled for an application - there is no host
# key to install it, and the platform chooses the version itself. These only tune it:
varnish_cache_size: 512m
varnish_type: opensource      # opensource | enterprise
# varnish_customvcl: |        # advanced: your own cache rules
#   sub vcl_recv { }
# varnish_modules: false      # advanced: leave out the extra module set (vmods)
# varnish_backend_host: origin.example.com   # advanced: custom origin
# varnish_backend_port: 8080
rabbitmq_version: latest      # latest | a series such as 4.0.x
rabbitmq_plugins: [rabbitmq_shovel, rabbitmq_shovel_management]
```


Host service parameters

`redis_enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"]

Default `true`.

Installs Redis, used for sessions and object caching. Recommended for almost every application, which is why it is on by default.


Host service parameters

`redis_memory`

[!badge variant="info" text="string"] [!badge variant="secondary" text="size (MB/GB)"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Tuned to the server.

How much memory the cache instance may use. Rarely needs changing. The platform sets this to the server's memory automatically and re-tunes it on every publish, so it grows with the server. The automatic value accounts for disk use as well as memory.

> [!WARNING]
> Raising it also increases disk use. Override the automatic value only after measuring.


Host service parameters

`redis_persistent_memory`

[!badge variant="info" text="string"] [!badge variant="secondary" text="size (MB/GB)"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default: Tuned to the server.

How much memory the persistent Redis instance may use - the instance that keeps its data on disk. The platform sizes this to the server's memory automatically and re-tunes it on every publish. Override only after measuring, for workloads that persist a lot of cache or session data.

> [!WARNING]
> Raising it also increases disk use.


Host service parameters

`redis_listen_addresses`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Only `internal`. Default: Local only.

Which addresses Redis accepts connections on. Leave it unset to stay on localhost; `internal` also binds the host's private network addresses. Needed when another server must reach the cache.

**Note:** `internal` is the only accepted value. Anything else, including `any`, stops the deployment with an error. On a host that runs Kubernetes or Docker, Redis uses `internal` unless you set this key yourself.

> [!WARNING]
> Keep it restricted to trusted networks. Setting `internal` turns off the Redis protected mode, and so does running Kubernetes or Docker on the host.


Host service parameters

`varnish_version`

[!badge variant="info" text="string"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

For example `7.6`, `8.0` - the GUI dropdown lists the values available now. Default: Chosen by the platform.

Pins the version of the full-page cache. You almost never set this. Nothing has to be set at host level to run Varnish. Turning on `varnish_enabled` for any application installs it, and the platform picks the version itself: 8.0, or 7.6 on Debian 11 and older, or 6.0 for the Enterprise edition. Setting this key by hand only does anything on a host where no application has `varnish_enabled` at all. That installs the cache before anything uses it.

> [!WARNING]
> As soon as one application on the host has `varnish_enabled`, the platform's own choice replaces whatever you put here, and it does not warn you that it did.


Host service parameters

`varnish_cache_size`

[!badge variant="info" text="string"] [!badge variant="secondary" text="size (MB/GB)"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Tuned to the server.

How much memory the full-page cache may use. The platform sets this to the server's memory automatically and re-tunes it on every publish, so it grows with the server. A larger cache holds more pages, but takes memory from the applications, so only override the automatic value after measuring.


Host service parameters

`varnish_type`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

One of `opensource`, `enterprise`. Default `opensource`.

Which edition of the cache is installed. The commercial edition adds features that need a licence.

**Note:** `enterprise` only works when Hosted Power has put a licence in place for this host. Without it the deployment stops with an error, so leave it on `opensource` unless the licence has been arranged.


Host service parameters

`varnish_customvcl`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Replaces the generated cache rules with your own. For caching behavior the standard configuration cannot express.

> [!WARNING]
> Custom cache rules are easy to get wrong and can serve the wrong content to visitors.


Host service parameters

`varnish_modules`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `true`.

Installs the extra Varnish module set (vmods) alongside the cache. Custom VCL often calls functions that only exist in these modules.

**Note:** open-source Varnish only. The Enterprise edition ships its own modules and ignores this key.


Host service parameters

`varnish_backend_host`

[!badge variant="info" text="string"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default: The local application.

Points the cache at a custom backend host instead of the local application. Put the full-page cache in front of an origin that runs on another server.

**Note:** set together with `varnish_backend_port`; the custom backend is only used when both are set.


Host service parameters

`varnish_backend_port`

[!badge variant="info" text="integer"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

The port of the custom cache backend host. Used together with `varnish_backend_host`.


Host service parameters

`rabbitmq_version`

[!badge variant="info" text="string"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

For example `latest`, `4.0.x` - the GUI dropdown lists the values available now. Default `latest`.

Pins the message broker to a specific version. Match a version your application is tested against.


Host service parameters

`rabbitmq_plugins`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `empty`.

Enables extra broker plugins. Adds protocols or management features your application needs.


Host service parameters

Search

A search engine powers product and content search. Magento requires one; most other
applications do not need it. The heap size is set to the server's memory automatically and
re-tuned on every publish, so it grows with the server. Only set a heap key when a
measurement shows you need to.

**Example** - every key in this section, with realistic values:

```yaml
# Use either Elasticsearch or OpenSearch on a host, not both.
elasticsearch_version: "8.x"       # required by Magento 2
elasticsearch_heap_size: 2g
elasticsearch_plugins: [analysis-icu]
# elasticsearch_kibana: true       # Kibana web interface
# elasticsearch_network_host: INTERNAL   # private network only, never public
# opensearch_version: "2.x"
# opensearch_heap_size: 2g
# opensearch_plugins: [analysis-icu]
# opensearch_dashboards: true
# opensearch_dashboards_usermanagement: true   # login for the dashboards
```


Host service parameters

`elasticsearch_version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

For example `8.x`, `9.x` - the GUI dropdown lists the values available now.

Installs Elasticsearch in the given version. Required by Magento 2 and used by Akeneo for catalog search.

**Note:** the value is a release channel such as `8.x`, not an exact version. To not install it, omit the key or set an empty string `""` - never the integer `0`, which fails the deployment.

> [!WARNING]
> Changing the major version usually means rebuilding your indexes.


Host service parameters

`elasticsearch_heap_size`

[!badge variant="info" text="string"] [!badge variant="secondary" text="size (MB/GB)"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Tuned to the server.

How much memory the search engine may use (the JVM heap). The platform sets this to the server's memory automatically and re-tunes it on every publish, so it grows with the server. Too little makes search slow; too much starves the rest of the server, so only override the automatic value after measuring.


Host service parameters

`elasticsearch_plugins`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `empty`.

Installs extra search plugins. Adds language-specific analysis for better search results.


Host service parameters

`elasticsearch_kibana`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `false`.

Installs the Kibana web interface for Elasticsearch, reachable at `https://<host>/kibana`. Inspect indexes and run queries in a browser.

**Note:** an `elasticsearch_version` must be set. The web server proxies the path and asks for a login first - use one of the host's system user accounts.


Host service parameters

`elasticsearch_network_host`

[!badge variant="info" text="string"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default `localhost`.

Which address Elasticsearch listens on - `localhost`, `INTERNAL` for private-network addresses, or a specific address. Reach the search engine from another server on a private network.

**Note:** `INTERNAL` resolves to the loopback addresses plus the host's private IPv4 addresses - the same keyword `redis_listen_addresses` uses.

> [!WARNING]
> Never bind it to a public address.


Host service parameters

`opensearch_version`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

For example `2.x`, `3.x` - the GUI dropdown lists the values available now.

Installs OpenSearch in the given version. An alternative search engine, used by Shopware among others.

**Note:** use either Elasticsearch or OpenSearch on a host, not both. The value is a release channel such as `2.x`; to not install it, omit the key or set an empty string `""`, never the integer `0`.


Host service parameters

`opensearch_heap_size`

[!badge variant="info" text="string"] [!badge variant="secondary" text="size (MB/GB)"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default: Tuned to the server.

How much memory OpenSearch may use (the JVM heap). Set to the server's memory automatically and re-tuned on every publish, so it grows with the server. Same trade-off as the Elasticsearch heap - only override the automatic value after measuring.


Host service parameters

`opensearch_plugins`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `empty`.

Installs extra OpenSearch plugins. Adds language-specific analysis.


Host service parameters

`opensearch_dashboards`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `false`.

Installs the OpenSearch web interface, reachable at `https://<host>/dashboards`. Inspect indexes and run queries in a browser.

**Note:** the web server proxies the path and asks for a login first - use one of the host's system user accounts.


Host service parameters

`opensearch_dashboards_usermanagement`

[!badge variant="info" text="boolean"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default `false`.

Turns on login and user management for the OpenSearch dashboards. Protect the dashboards with authentication and user accounts.

**Note:** `opensearch_dashboards` must be enabled.


Host service parameters

Host-wide runtime and packages

Settings that apply to the whole server rather than to one application.

**Example** - every key in this section, with realistic values:

```yaml
php_main_version: "8.4"           # PHP used on the command line
# php_versions: ["8.3", "8.4"]    # install extra PHP versions side by side
# php_ioncube_enabled: true       # ionCube loader for encoded/licensed apps
composer_version: lts             # latest | lts | 2 | 2.2
# composer_keep_updated: true     # auto-update the Composer binary
os_extra_packages: [imagemagick, jq]
system_packages_upgrade_time: "03:30"
maintenance:                      # window for updates that need a reboot
  - day: 4                        # 1 = Sunday ... 7 = Saturday
    hour: 22                      # 0-23
supervisor_enabled: false
```


Host service parameters

`php_versions`

[!badge variant="info" text="list"] [!badge variant="warning" text="YAML only"]

For example `['8.3', '8.4']` - the GUI dropdown lists the values available now. Default: The versions your applications use.

Which PHP versions are installed and available on the server. Run applications that need different PHP versions side by side. Normally derived from your applications; set it to install an extra version explicitly.


Host service parameters

`php_ioncube_enabled`

[!badge variant="info" text="boolean"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default `false`.

Installs the ionCube loader for PHP. Required to run commercial PHP software distributed as encrypted, licensed code.


Host service parameters

`php_main_version`

[!badge variant="info" text="string"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

For example `8.2`, `8.3`, `8.4` - the GUI dropdown lists the values available now. Default: The lowest version any application uses.

Which PHP version is used on the command line. Matters when you run scripts over SSH and several PHP versions are installed.


Host service parameters

`composer_keep_updated`

[!badge variant="info" text="boolean"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default `true`.

Keeps the Composer binary automatically updated. Always run a current Composer without updating it by hand.


Host service parameters

`composer_version`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"]

One of `latest`, `lts`, `2`, `2.2`. Default `lts`.

Which Composer version is installed. Some applications need a specific Composer version to install correctly.


Host service parameters

`os_extra_packages`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

Installs extra operating-system packages. Add a tool or library your application needs, without root access.


Host service parameters

`system_packages_upgrade_time`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

When automatic package updates are installed. These are routine updates that do not need a reboot. Move updates to a quiet moment for your business.


Host service parameters

`maintenance`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default: a weekly window managed by the platform.

Sets the weekly window when the platform applies updates that need a reboot. Pick a low-traffic moment so a reboot does not interrupt visitors during your busy hours.

**Note:** each entry has a day (1 = Sunday through 7 = Saturday) and an hour (0-23). Set it from the Advanced tab, which offers day and hour dropdowns.


Host service parameters

`supervisor_enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `false`.

Installs a process manager for long-running background processes. An alternative to user system services for keeping workers running.


Host service parameters

Mail

TurboStack signs outgoing mail with DomainKeys Identified Mail (DKIM), so a receiving server
can check that a message really came from your domain. A separate setting turns a host into a
mail testing host, where messages are collected on the server instead of being delivered. Both
live on the **Advanced** tab, under **Mail Settings**. For the DNS side of mail authentication,
see Email deliverability.

**Example** - every key in this section, with realistic values:

```yaml
dkim:
  keys:
    - fqdn: example.com          # sign mail sent from this domain
    - fqdn: shop.example.com
      selector: shop2026         # optional, default is cloud
# Development and staging hosts only - collect mail instead of delivering it:
mail_devtool: mailpit           # mailpit | mailhog
# mailhog_install: true         # written by the interface toggle; mail_devtool does the work
```


Host service parameters

`dkim.keys`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

The mail domains this host signs outgoing mail for. A signing key pair is generated on the server for each entry, and existing keys are never overwritten. Signed mail is far more likely to reach the inbox instead of the spam folder.

**Note:** `dkim` must be a map that contains a `keys` list. The older `dkim: true` form is refused and stops the deployment. After the key is generated, publish the matching public record in the Domain Name System (DNS).


Host service parameters

`dkim.keys.fqdn`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="danger" text="required"]

The mail domain this key signs for, written in full. Tells the platform which sender domain the key belongs to.

**Note:** required for every entry. An entry without it stops the deployment.


Host service parameters

`dkim.keys.selector`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `cloud`.

The label that identifies this key in DNS. The record you publish is the selector, followed by `._domainkey.` and the domain. Lets one domain hold more than one key, which is what makes it possible to replace a key without a gap in signing.


Host service parameters

`mail_devtool`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

One of `mailpit`, `mailhog`.

Installs a mail testing tool with a web interface that collects the messages your applications send. See exactly what your application sends, including the full message, without anything reaching a real recipient.

**Note:** only the two values above are accepted; anything else stops the deployment. The platform also points PHP at the collector by default.

> [!WARNING]
> Use this on development and staging hosts only. While it is set, mail your applications send is kept on the server instead of being delivered.


Host service parameters

`mailhog_install`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `false`.

Records that mail collecting is switched on for this host. The interface writes it when you enable **Enable mail capturing and mail testing**, which then shows the `mail_devtool` field. Only meaningful together with `mail_devtool`.

**Note:** on its own this key installs nothing. `mail_devtool` is what selects and installs the tool, so set that as well.


Host service parameters

Advanced database monitoring

Advanced database monitoring collects query-level statistics from the databases on this host
and sends them to a central collection server, where slow queries, locks and load are kept over
time. Set it up on the **Advanced** tab, under **Advanced Database Monitoring**.

**Example** - every key in this section, with realistic values:

```yaml
pmm_master:
  server_hostname: monitor.example.com   # the server that collects the statistics
pmm_sampling_rate: 50                    # record one query in every fifty
```


Host service parameters

`pmm_master.server_hostname`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The collection server this host sends its database statistics to. Setting it is what switches advanced database monitoring on. Find the queries that make a database slow, with history you can compare against a quiet period.

**Note:** at least one database must be configured on the host. Without one, the panel stays empty.


Host service parameters

`pmm_sampling_rate`

[!badge variant="info" text="integer"] [!badge variant="secondary" text="count"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Default `50`.

How often a query is recorded. A value of `50` records one query in every fifty, not one in two. Lower it for a more complete picture on a quiet database, raise it to keep the measuring itself cheap on a busy one.

**Note:** only used together with `pmm_master.server_hostname`.


Host service parameters

Related

- YAML configuration reference
- The Source (YAML) view
- Publishing changes


YAML configuration reference

yaml reference turbostack yaml configuration parameters host configuration ansible variables

<!-- GENERATED FILE - do not edit. Source: data/yaml-parameters.yml -->

# YAML configuration reference

A host's configuration is one YAML document. This reference lists every key you can set,
what it changes on the server, and why you would use it.

The GUI and the Source (YAML) view describe the same
configuration, so anything here can also be set through the forms where a field exists.
Keys marked **YAML only** have no field in the GUI.

> [!NOTE]
> Version numbers, application types and similar option lists are not repeated here,
> because they change over time. The GUI dropdown always shows the values available today.

> [!TIP]
> In a hurry? The configuration recipes are complete, copy-ready
> configurations for common scenarios - a simple site, an online store, Odoo and more.


YAML configuration reference

The sections

| Section | What it covers | Keys |
|---|---|---|
| Applications | The YAML keys you set per application (vhost) - domain, certificate, runtime, code deployment, proxying and per-application tuning. | 43 |
| Host services | The YAML keys you set once per host - web server, databases, caching, queues, search, mail and database monitoring. | 61 |
| Users and access | The YAML keys for system users, their applications, file transfer accounts, extra database users and SSH access. | 14 |
| Security | The YAML keys for TurboShield and the firewall - protection level, bot lists, trusted clients, country rules and ports. | 12 |


YAML configuration reference

How a host configuration is structured

Host-level keys sit at the top. Below them, `system_users` lists the accounts, and each
account has `vhosts`: its applications. A key belongs to exactly one of those three levels,
which the **Scope** of every key tells you.

```yaml
# Host level: services shared by every application on this server
webserver: nginx
mysql_version: "8.4"
redis_enabled: true

turboshield:
  enabled: true
  level: medium

firewall_whitelist:
  - 203.0.113.10        # office

# The accounts on this server
system_users:
  - username: prod

    # The applications owned by this account
    vhosts:
      - server_name: example.com www.example.com
        app_type: wordpress
        php_version: "8.4"
        cert_type: letsencrypt
        varnish_enabled: true
```


YAML configuration reference

Keys you will not find here

Some variables appear in server output or in examples elsewhere but cannot be set by you:

- **Computed values.** The platform derives them from what you did set. For example, the
  Node.js runtime is enabled by setting `nodejs_version` on an application, and there is no
  separate key to switch it on.
- **Platform-managed settings.** The system type, monitoring level and backup schedule are
  set by Hosted Power for your server.


YAML configuration reference

Related

- The Source (YAML) view - how to open and edit the YAML
- Publishing changes - how to apply it
- API reference - the same model over HTTP


Configuration recipes

yaml example config example magento config wordpress config odoo config sample configuration recipe

<!-- GENERATED FILE - do not edit. Source: data/yaml-parameters.yml -->

# Configuration recipes

Each recipe below is a complete host configuration for a common scenario. Copy the one
closest to your situation into the Source (YAML) view,
change the domain and version to suit, and publish. Every key used here is explained in
the parameter reference.

> [!NOTE]
> You do not set memory sizes in any of these recipes. The platform sizes each service to
> the server automatically and re-tunes it on every publish, so a bigger server scales the
> configuration up without any change here.


Configuration recipes

A simple website (WordPress)

A content site or blog on its own domain, with automatic HTTPS.

```yaml
webserver: nginx
mysql_version: "8.4"           # WordPress stores its data in MySQL
redis_enabled: true            # object cache (recommended, especially WooCommerce)
system_users:
  - username: prod
    vhosts:
      - server_name: example.com www.example.com
        app_type: wordpress
        php_version: "8.4"
        cert_type: letsencrypt  # automatic HTTPS
```

This is the smallest useful configuration: one application, a database and a
cache. You do not size anything - the platform tunes MySQL and Redis to the
server automatically. Setting `cert_type: letsencrypt` requests a certificate
and redirects HTTP to HTTPS once it is issued.


Configuration recipes

A busy online store (Magento 2)

A Magento 2 storefront that must stay fast during a sale.

```yaml
webserver: nginx
mysql_version: "8.4"           # Magento core database
elasticsearch_version: "8.x"   # required by Magento for catalog search
redis_enabled: true            # sessions and object cache
system_users:
  - username: prod
    vhosts:
      - server_name: shop.example.com www.shop.example.com
        app_type: magento2
        php_version: "8.4"
        cert_type: letsencrypt
        varnish_enabled: true   # installs and fronts the full-page cache
```

Magento needs all four performance layers: the database, a search engine,
Redis for sessions and the object cache, and Varnish for full-page caching.
Varnish needs nothing at host level: `varnish_enabled` on the storefront
installs it and puts the store behind it.
Every memory size (buffer pool, Redis, Varnish, search heap) is auto-tuned to
the server and re-tuned on every publish, so a bigger server scales the store
up without any change here.


Configuration recipes

A Shopware store

A Shopware 6 storefront with caching.

```yaml
webserver: nginx
mysql_version: "8.4"           # Shopware core database
redis_enabled: true            # cache and session storage
system_users:
  - username: prod
    vhosts:
      - server_name: shop.example.com www.shop.example.com
        app_type: shopware
        php_version: "8.4"
        cert_type: letsencrypt
        varnish_enabled: true   # full-page cache for storefront performance
```

Like Magento, Shopware benefits from Redis and a full-page cache. It does not
require a separate search engine on TurboStack. If you prefer OpenSearch over
Elasticsearch for product search, set `opensearch_version` instead - never
both on one host.


Configuration recipes

Odoo (business software)

Move an Odoo installation onto TurboStack.

```yaml
webserver: nginx
postgresql_version: "17"       # Odoo requires PostgreSQL
system_users:
  - username: prod
    vhosts:
      - server_name: odoo.example.com
        app_type: odoo          # TurboStack runs Odoo behind nginx for you
        cert_type: letsencrypt
```

Odoo uses PostgreSQL, not MySQL, and runs as a service behind an Nginx reverse
proxy that TurboStack sets up from `app_type: odoo`. You do not set a PHP
version - Odoo is a Python application managed by the platform.


Configuration recipes

A Laravel application

A PHP application built on Laravel, with background queues.

```yaml
webserver: nginx
mysql_version: "8.4"           # application database
redis_enabled: true            # queues, cache and sessions
system_users:
  - username: prod
    vhosts:
      - server_name: app.example.com
        app_type: laravel
        php_version: "8.4"
        cert_type: letsencrypt
        # rabbitmq_enabled: true  # add a message broker if your jobs need one
```

Laravel uses Redis for its queue, cache and session drivers, so `redis_enabled`
covers most background-job needs. Add a dedicated message broker with
`rabbitmq_enabled` only if your application specifically uses one.


Configuration recipes

A Node.js application

A Node.js service (for example an API or a JavaScript framework).

```yaml
webserver: nginx
system_users:
  - username: prod
    vhosts:
      - server_name: api.example.com
        app_type: generic
        nodejs_version: "24"     # setting the version enables the Node.js runtime
        proxy_enabled: true      # nginx forwards requests to your Node process
        proxy_upstream_port: 3000
        cert_type: letsencrypt
```

A Node.js application is enabled simply by setting `nodejs_version` - there is
no separate "enable" key. Because the application listens on its own port,
`proxy_enabled` tells the web server to forward requests to it, and
`proxy_upstream_port` is the port your process listens on.


Configuration recipes

Several applications on one host

Two applications, each with its own runtime, on the same server.

```yaml
webserver: nginx
mysql_version: "8.4"
redis_enabled: true
system_users:
  - username: shop
    vhosts:
      - server_name: shop.example.com
        app_type: magento2
        php_version: "8.4"
        cert_type: letsencrypt
        varnish_enabled: true
  - username: api
    vhosts:
      - server_name: api.example.com
        app_type: generic
        nodejs_version: "24"
        proxy_enabled: true
        proxy_upstream_port: 3000
        cert_type: letsencrypt
```

One host can run several applications side by side, each under its own system
user and with its own runtime and version. Host services (MySQL, Redis) are
shared; the per-application keys under each `vhosts` entry are independent.


Configuration recipes

Application server plus a separate database server

Keep the database on its own server for larger workloads.

```yaml
# On the application server:
webserver: nginx
mysql_client_host_name: db1.example.com
mysql_client_host_ip: 10.0.0.5
system_users:
  - username: prod
    vhosts:
      - server_name: app.example.com
        app_type: laravel
        php_version: "8.4"
        cert_type: letsencrypt
# On the database server (separate host configuration):
# mysql_version: "8.4"
# mysql_server_only: true
```

For a larger workload you can split the database onto its own server. The
application host points at it with `mysql_client_host_name` and
`mysql_client_host_ip`. The database host is configured with
`mysql_server_only: true`, so it installs the server without a web stack.


Configuration recipes

Dependencies and rules

The rules that connect keys. Keep these in mind when you change a configuration.

- **A runtime is enabled by setting its version key.** There is no separate enable key. `php_version`, `nodejs_version`, `python_version`, `ruby_version` and `dotnet_version` each enable that runtime just by being set.
- **Varnish is enabled per application, and that is the whole of it.** `varnish_enabled: true` on any application installs Varnish on the host and puts that application behind it. There is no host key to install it first, and the platform chooses the version. The host keys under Caching and queues (`varnish_cache_size`, `varnish_type`, `varnish_customvcl`) only tune a cache that an application has already asked for.
- **A host uses either Elasticsearch or OpenSearch, never both.** Set `elasticsearch_version` or `opensearch_version`, not both on the same host.
- **To not install a search engine, omit the key or set an empty string.** `elasticsearch_version: ""` disables it. Never use the integer `0` - it fails the deployment.
- **A proxied runtime (Node.js and similar) needs the proxy turned on.** Set `proxy_enabled: true` and `proxy_upstream_port` so the web server forwards requests to the application process.
- **A separate database server uses the client/server split keys.** On the database host set `mysql_server_only: true`; on the application host set `mysql_client_host_name` and `mysql_client_host_ip` to point at it.
- **Memory sizes are auto-tuned - do not set them up front.** `mysql_innodb_size`, `redis_memory`, `varnish_cache_size`, `elasticsearch_heap_size` and similar are sized to the server automatically and re-tuned on every publish. Override only with measured evidence.
- **Prefer a supported (non-EOL) version.** Older versions still install but may not receive security updates. The GUI dropdown lists the versions available now.


Configuration recipes

Related


Security parameters

turboshield yaml firewall_whitelist bot_protection country block firewall ports

<!-- GENERATED FILE - do not edit. Source: data/yaml-parameters.yml -->

# Security parameters

Every key on this page is set once per host, at the top of the configuration.
A [!badge variant="success" text="GUI"] key has a field in the interface; a
[!badge variant="warning" text="YAML only"] key is set in the
Source (YAML) view, which accepts the same configuration.


Security parameters

TurboShield

TurboShield protects your applications against malicious traffic. For what each mechanism
does, see What is TurboShield?.

**Example** - every key in this section, with realistic values:

```yaml
turboshield:
  enabled: true
  level: medium              # low | medium | high | attack
  allow_bots: [channable]
  limit_bots: [bytespider, gptbot]
  bot_protection: true       # browser check for suspicious visitors (Nginx)
```


Security parameters

`turboshield.enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"]

Default `true`.

Turns the protection on for this host. On by default. Switching it off removes the protection completely.


Security parameters

`turboshield.level`

[!badge variant="info" text="enum"] [!badge variant="success" text="GUI"]

One of `low`, `medium`, `high`, `attack`. Default `medium`.

How aggressive the limits are, and whether the attack-only mechanisms run. Raise it while an attack is happening, and lower it again afterwards.


Security parameters

`turboshield.allow_bots`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

Bots that are never slowed down. Protects crawlers your revenue depends on, such as marketplace and comparison feeds.


Security parameters

`turboshield.limit_bots`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

Bots that are strictly slowed down. Your lever against crawlers that consume capacity without bringing customers.


Security parameters

`turboshield.bot_protection`

[!badge variant="info" text="boolean"] [!badge variant="warning" text="YAML only"]

Default `false`.

Shows suspicious visitors an automatic browser check before they reach your site. Effective against scraping and credential stuffing spread across many addresses.

**Note:** requires Nginx.


Security parameters

Trusted addresses and the firewall

The firewall controls which networks and ports reach the server at all. The trusted list is
shared with TurboShield.

**Example** - every key in this section, with realistic values:

```yaml
firewall_whitelist:
  - 203.0.113.10         # office
  - 198.51.100.0/24      # partner integration
firewall_country_block: "CN,RU"
# Or restrict to only certain countries instead:
# firewall_country_allow: "BE,NL,FR"
firewall_tcp_ports: [80, 443, 8080]
firewall_udp_ports: [53]
```


Security parameters

`firewall_whitelist`

[!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

Addresses that bypass every check and can never be blocked automatically. The most important list to maintain. Prevents your own office, integrations and monitoring from being locked out.

> [!WARNING]
> A trusted address skips all protection. Keep the list short and never add a broad public range.


Security parameters

`firewall_country_block`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

Refuses all traffic from the listed countries. Cuts a lot of unwanted traffic when you only sell in certain regions.

> [!WARNING]
> Blocks real customers and travelling staff in those countries.


Security parameters

`firewall_country_allow`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

Allows traffic only from the listed countries. For applications meant for one region only, such as an internal tool.

> [!WARNING]
> Everything else is refused, including search engines and monitoring.


Security parameters

`firewall_tcp_ports`

[!badge variant="info" text="list"] [!badge variant="warning" text="YAML only"]

Default: Detected automatically.

Which TCP ports the firewall opens. Open a port for your own service.

> [!WARNING]
> Every open port is a way in. Only open what you actually use.


Security parameters

`firewall_udp_ports`

[!badge variant="info" text="list"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default: Detected automatically.

Which UDP ports the firewall opens. For services that do not use TCP.


Security parameters

Web Application Firewall

The Web Application Firewall (WAF) inspects incoming requests and blocks attacks against the
application itself, such as SQL injection and cross-site scripting. It also scans the files on
the host for malware. TurboStack uses Imunify for this. You switch it on per host on the
**Security** tab.

**Example** - every key in this section, with realistic values:

```yaml
imunify:
  enabled: true
  email: security@example.com
```


Security parameters

`imunify.enabled`

[!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"]

Default `false`.

Installs and activates the Web Application Firewall and malware scanning on the host. Blocks application-layer attacks that the network firewall cannot see, and finds malware in your files.


Security parameters

`imunify.email`

[!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

The address that receives Web Application Firewall alerts, such as a malware detection. Without it you only see findings when you open the interface yourself.

**Note:** only used when `imunify.enabled` is true.


Security parameters

Related

- YAML configuration reference
- The Source (YAML) view
- Publishing changes


Users and access parameters

system_users username ftp sftp db_extra_users ssh_keys ssh_port

<!-- GENERATED FILE - do not edit. Source: data/yaml-parameters.yml -->

# Users and access parameters

Each key below carries a label for where it belongs in the configuration.
A [!badge variant="success" text="GUI"] key has a field in the interface; a
[!badge variant="warning" text="YAML only"] key is set in the
Source (YAML) view, which accepts the same configuration.


Users and access parameters

System users

A system user is the account that owns the files and runs the applications. Every
application belongs to exactly one system user.

**Example** - every key in this section, with realistic values:

```yaml
system_users:
  - username: prod
    vhosts:
      - server_name: example.com
        app_type: wordpress
```


Users and access parameters

`system_users`

[!badge variant="secondary" text="host"] [!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

The list of accounts on this host, each with its own applications. Separating applications per account keeps their files, databases and processes apart.


Users and access parameters

`username`

[!badge variant="secondary" text="system user"] [!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

The account name, which also determines the home directory and the database name. Required for every account.

**Note:** lowercase letters and digits, starting with a letter, at most 24 characters. Some reserved names are refused.


Users and access parameters

File transfer accounts

File transfer accounts give someone access to files without giving them the system account
itself. Prefer Secure File Transfer Protocol (SFTP) over plain FTP.

**Example** - every key in this section, with realistic values:

```yaml
ftp_sftp: true             # use encrypted SFTP (host level)
ftp_sftp_port: 222
ftp_hostname: sftp.example.com
system_users:
  - username: prod
    ftp:
      - user: designer
        homedir: /var/www/prod/example.com   # must be inside the user's directory
```


Users and access parameters

`ftp`

[!badge variant="secondary" text="system user"] [!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

Extra file-transfer accounts under this system user. Give an external designer or agency access to one folder only.


Users and access parameters

`user`

[!badge variant="secondary" text="system user"] [!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

The login name of the file-transfer account. Required for every entry under `ftp`.


Users and access parameters

`homedir`

[!badge variant="secondary" text="system user"] [!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

The folder this account is limited to. Restricts access to one application instead of the whole account.

**Note:** must be inside the system user's own directory. The deployment fails otherwise.


Users and access parameters

`ftp_sftp`

[!badge variant="secondary" text="host"] [!badge variant="info" text="boolean"] [!badge variant="success" text="GUI"] [!badge variant="danger" text="required"]

Default `false`.

Enables encrypted file transfer over SFTP. Plain FTP sends passwords unencrypted. Use SFTP whenever you can.

**Note:** required before you can add SSH keys to a file-transfer account, otherwise the deployment fails.


Users and access parameters

`ftp_sftp_port`

[!badge variant="secondary" text="host"] [!badge variant="info" text="integer"] [!badge variant="secondary" text="port"] [!badge variant="warning" text="YAML only"] [!badge variant="ghost" text="advanced"]

Default `222`.

The port SFTP listens on. Avoids a clash with regular SSH.


Users and access parameters

`ftp_hostname`

[!badge variant="secondary" text="host"] [!badge variant="info" text="string"] [!badge variant="success" text="GUI"] [!badge variant="ghost" text="advanced"]

The host name shown for file-transfer connections. Give customers a branded address to connect to.


Users and access parameters

Extra database users

Extra database accounts. The `admin` role has full read/write access to all databases on the
server; the `readonly` role has read-only access.

**Example** - every key in this section, with realistic values:

```yaml
system_users:
  - username: prod
    db_extra_users:
      - name: reporting
        db_role: readonly       # admin | readonly
```


Users and access parameters

`db_extra_users`

[!badge variant="secondary" text="system user"] [!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

Additional database accounts alongside the automatically created one. Give a reporting tool or an external developer their own database login.


Users and access parameters

`name`

[!badge variant="secondary" text="system user"] [!badge variant="info" text="string"] [!badge variant="success" text="GUI"]

The login name of the extra database user. Required for every entry under `db_extra_users`.

**Note:** lowercase letters and digits, starting with a letter, at most 24 characters, and unique.


Users and access parameters

`db_role`

[!badge variant="secondary" text="system user"] [!badge variant="info" text="enum"] [!badge variant="success" text="GUI"] [!badge variant="danger" text="required"]

One of `admin`, `readonly`.

The role - `admin` has full read/write access to all databases on the server, `readonly` has read-only access. A reporting tool or external analyst should almost always be `readonly`; `admin` reaches every database on the server.

**Note:** required, and must be exactly one of the two values.


Users and access parameters

SSH access

SSH gives command-line access to the server. Keys are safer than passwords, because a key
cannot be guessed.

**Example** - every key in this section, with realistic values:

```yaml
ssh_keys:
  - ssh-ed25519 AAAAC3Nza... team@example.com
ssh_passwords: false         # disable password login (keys only)
ssh_port: 22                 # YAML only; the firewall opens the new port for you
```


Users and access parameters

`ssh_keys`

[!badge variant="secondary" text="host"] [!badge variant="info" text="list"] [!badge variant="success" text="GUI"]

Default `empty`.

Public keys that get access to every account on this host. Give your whole team access in one place, without sharing passwords.


Users and access parameters

`ssh_port`

[!badge variant="secondary" text="host"] [!badge variant="info" text="integer"] [!badge variant="secondary" text="port"] [!badge variant="warning" text="YAML only"]

Default `22`.

The port the server listens on for SSH. A non-standard port removes most automated login attempts from your logs.

> [!WARNING]
> Set the wrong value and you lock yourself out. The firewall is opened for the new port automatically.