Groups

Assigning hosts to a group

The `Hosts` tab controls the membership of the group. It shows two lists side by side:

- **Available Hosts** - the hosts you can still add.
- **Selected Hosts** - the hosts that are already in the group.

Select a host in **Available Hosts** to move it to **Selected Hosts**. Select a host in
**Selected Hosts** to move it back. Each list has its own search box, so you can filter a long
list before you move anything.

1. Open the group and select the `Hosts` tab.
2. Search for a host if the list is long, then select it to move it to the other list.
3. To include every available host at once, use `Add all hosts`. To clear the membership, use
   `Remove all hosts`.
4. Select `Save`, then publish the group to apply its settings to the new
   member hosts.

> [!NOTE]
> You can check which groups a host belongs to from that host's `Groups` tab. Any setting defined on a group automatically applies to all of its hosts.


Groups

Setting group-level SSH keys

groups SSH keys shared settings security rules fleet management publish group group history revert

1. Open the group and select the `SSH` tab.
2. Add the SSH keys you want every member host to receive.
3. Save your changes. The keys are inherited by all hosts in the group.


Groups

Setting group-level security rules

1. Open the group and select the `Security` tab.
2. Define the firewall and security rules to apply.
3. Save your changes. The rules are inherited by all hosts in the group.

> [!IMPORTANT]
> Because group settings are inherited, removing a key or rule from a group removes it from every member host. Review the group's membership before making changes.


Groups

Publishing a group

Saving a group stores your changes in TurboStack. The member hosts only change once you
**publish** the group. The buttons for this sit in the group header, next to the group name.

| Action | What it does |
| --- | --- |
| `Save` | Stores the group configuration. Nothing is applied to the member hosts yet. |
| `Save & Publish` | Saves your changes and starts a deployment on the group's hosts right away. |
| `Save & Full Publish` | In the menu next to `Save & Publish`. Shows a preview of every host in the group first, then re-applies the whole configuration on each of them. |

Above the header, TurboStack tells you where the group stands: how many unpublished changes it
has, or when the last publication succeeded or only partly succeeded. Selecting the unpublished
changes message opens the History view.


Groups

The deploy preview

`Save & Full Publish` opens a preview before anything is deployed. It lists every host in the
group, so you can see what the deployment will do:

| Column | What it shows |
| --- | --- |
| **Hostname** | The member host that will be deployed. |
| **Pending local changes** | How many unpublished changes that host still has of its own. Zero is shown in green, anything higher in yellow. |
| **Components** | The parts of the configuration that will be deployed on that host, for example `firewall` or `webserver`. A dash means no specific components. |
| **Deploy Type** | `Deploy` when specific components are listed, or `Full Deploy` when the whole configuration is re-applied. |
| **Open Host** | Opens that host in a new browser tab, so you can check it before you publish. |

The list is paginated when the group has many hosts.

Select `Deploy` to continue, or `Cancel` to close the preview without deploying. A confirmation
then asks whether you are sure, because this deploys all hosts. Select `Yes, Deploy` to start the
deployment, or `No` to go back.


Groups

Following the deployment

While a publication runs, a **PUBLISHING** progress indicator appears at the top right of the
group page and fills up as the run proceeds. The publish buttons stay disabled until the run
finishes, so two deployments cannot overlap.

If a host fails, TurboStack reports an error and lists each failing host with the output of its
deployment, so you can see what went wrong before you close the message. The full result of every
run is kept in the History view.

> [!NOTE]
> After a publication that only partly succeeded, a normal `Save & Publish` retries just the hosts
> that failed. Use `Save & Full Publish` when you want every host in the group to run again.


Groups

Group history

The clock icon in the group header opens the **History** view, with two tabs: **Revisions** and
**Deploys**.


Groups

Deploys

Each row is one publication of the group: who started it, the date, the status (`published`,
`partially published` or `error`), the deploy type, the components, and the start and finish
times. Select the arrow at the start of a row to expand it and see the result per host: the host
name, its status, deploy type, components, output, and start and finish times. When the output is
long, `Show full error` shows it in full.

This is where you check a publication that reported a problem: the per-host output usually names
the step that failed.


Groups

Revisions

Every save is recorded as a revision. The table lists the user and date, the configuration
**Path** that changed, the components, whether the change is already published, and the **From**
and **To** values, so you can see exactly what changed. Revisions that have been reverted are
shown on a gray background.

`Revert` on a row restores the group configuration to that revision. A confirmation shows the
**Current** configuration and the configuration **After Revert**, one above the other, so you can
compare them before you apply the change.

> [!TIP]
> Reverting only changes the stored configuration. Publish afterwards to
> apply the rollback to the member hosts.


Groups

Editing a group

`Edit` in the group header opens the **Edit group** window, where you change the group name.

1. Select `Edit`.
2. Enter the new name. Names accept letters only: dashes and other special characters are
   rejected.
3. Select `Save` to apply the new name, or `Cancel` to keep the current one.


Groups

Deleting a group

`Delete` in the group header removes the group from TurboStack. TurboStack asks you to confirm
first: select `Delete` to confirm, or `Cancel` to keep the group.

> [!WARNING]
> Deleting a group cannot be undone. Its SSH keys and security rules are no longer inherited by
> the hosts that were members, so review the membership before you delete it.


Groups

Common use cases

Groups are most useful when you organize access and hosts by role. Two common scenarios are
role-based SSH access and role-based node grouping.


Groups

Scenario 1: role-based SSH access tiers

Use groups to centralize user rights with SSH keys, so people get access based on their role.

1. Identify the different **levels of access** required within your system.
2. Create groups based on these access levels - for example `admin`, `developers`, and `sysadmins`.
3. Add each person to the group that matches their role and responsibilities.
4. Have each person generate their own SSH key pair, then add it to the group's SSH keys.
5. Have people from different groups sign in over SSH to confirm access is restricted according to
   the group-based configuration.
6. Review group memberships regularly so they still match your organization's requirements.

> [!NOTE]
> Hosted Power monitors system logs for unauthorized access attempts and takes appropriate action if
> necessary.


Groups

Scenario 2: role-based node grouping

Use groups to manage TurboStack nodes by the role they fulfill, keeping configuration consistent
across your infrastructure.

1. Determine the different **roles** your nodes will fulfill - for example web node, database node,
   and application node.
2. Create a group for each server role.
3. Assign each node to the group that matches its role.


Groups

Related

- Managing hosts
- Security
- SSH access
- Publishing changes (per host)
- History (revisions, deploys and cloning)


Email

turbostack email postfix dkim spf dmarc mail deliverability

# Email

TurboStack is primarily an application-hosting platform. Outbound (transactional) mail is handled by the **local mail service** on your host. Domain authentication (DKIM) and a development mail-catcher are set up under the host's **Advanced > Mail Settings** (Advanced).


Email

Sending mail

Your applications send through the **local mail service** by default - no external SMTP credentials
are required for basic delivery. To keep that mail out of spam folders, publish the DNS records below
(SPF, DKIM, DMARC). For high-volume or marketing mail, use an external SMTP provider instead.


Email

Common email ports

When you configure an application's outbound mail or a desktop mail client, use these standard ports. Simple Mail Transfer Protocol (SMTP) sends mail; Internet Message Access Protocol (IMAP) and Post Office Protocol version 3 (POP3) read it.

| Service | Port | Encryption |
| --- | --- | --- |
| SMTP submission (from a client) | `587` | STARTTLS |
| SMTP submission (implicit TLS) | `465` | Transport Layer Security (TLS) on connect |
| SMTP (server to server) | `25` | opportunistic |
| IMAP | `143` | STARTTLS |
| IMAP over TLS | `993` | TLS on connect |
| POP3 | `110` | STARTTLS |
| POP3 over TLS | `995` | TLS on connect |

Prefer the encrypted submission ports (`587` with STARTTLS, or `465` with implicit TLS) for sending from an application. Port `25` is for server-to-server delivery, not client submission.


Email

Deliverability (DNS records)

To land in inboxes rather than spam folders, authenticate your domain with three Domain Name System (DNS) records. Add these where you manage your domain's DNS. If Hosted Power manages your DNS, add them in the Customer Center DNS management; otherwise add them at your DNS provider - see Connecting your domain.

| Record | Type | Purpose |
| --- | --- | --- |
| **Sender Policy Framework (SPF)** | TXT | Authorises the server to send mail for your domain. |
| **DomainKeys Identified Mail (DKIM)** | TXT | Cryptographically signs your mail - use the selector and key from Mail Settings. |
| **Domain-based Message Authentication, Reporting and Conformance (DMARC)** | TXT | Sets the policy for how receivers handle messages that fail SPF or DKIM. |


Email

Set up DKIM

DKIM signs your outbound mail so receiving servers can confirm it genuinely came from your domain.
Set it up from the host's **Advanced > Mail Settings**:

1. Enter the **Fully Qualified Domain Name (FQDN)** you send mail from.
2. Choose a **selector** - this becomes the subdomain part of the DKIM record.
3. Connect over SSH and run `tscli dkim records` to get the DKIM record to publish.
4. Add that record as a **TXT** record in your domain's DNS - in the
   Customer Center DNS management if Hosted
   Power manages your DNS, otherwise at your DNS provider.
5. Back on the server, run `tscli dkim validate` to confirm the record was created correctly.


Email

SPF record syntax

An SPF record is a single DNS TXT record that starts with `v=spf1`, lists the mechanisms that authorise senders, and ends with an `all` mechanism. Each mechanism carries a qualifier that sets the result when it matches.

| Qualifier | Result | Meaning |
| --- | --- | --- |
| `+` | pass | Authorised (the default when no qualifier is written) |
| `-` | fail | Not authorised; reject |
| `~` | softfail | Probably not authorised; accept but mark |
| `?` | neutral | No statement |

| Mechanism | Matches |
| --- | --- |
| `ip4:` / `ip6:` | A specific IPv4 or IPv6 address or range |
| `a` / `mx` | The domain's A record(s) or MX host(s) |
| `include:` | The SPF record of another domain, for a third-party sender |
| `all` | Everything; put it last, as `-all` or `~all` |

Examples:

```text
v=spf1 mx -all
v=spf1 ip4:203.0.113.10 include:example.net -all
```

Keep one SPF record per domain and stay within the 10-lookup limit - see Mail deliverability.


Email

Development mail

**Mailpit** and **Mailhog** are development mail-catchers that capture outbound mail so you can inspect it without delivering it. Enable one from **Advanced > Mail Settings** (the mail capturing/testing option); it is then reachable at `https://<hostname>/mailpit` or `https://<hostname>/mailhog` with your system user's credentials. Mailpit is recommended (Mailhog is no longer maintained).

> [!WARNING]
> Never enable a mail-catcher on a production host - it intercepts mail instead of sending it.

> [!NOTE]
> For high-volume or marketing email, use a dedicated email/SMTP provider.


Email

Related

- Advanced settings
- Connecting your domain
- Customer Center DNS management - add the SPF, DKIM and DMARC records.
- Mail deliverability - fix mail landing in spam, blocklists and authentication.
- Security hardening checklist
- Hosts


FTP and SFTP access

ftp sftp ftp user filezilla ftp_sftp file transfer erp integration

# FTP and SFTP access

You can create dedicated FTP and Secure File Transfer Protocol (SFTP) users with their own **home directory**, separate from your main
system user. This is most often used to connect an external system - for example an Enterprise Resource Planning (ERP) system - to a
store, giving it access only to the files it needs (product images, stock exports, report PDFs).


FTP and SFTP access

In the GUI

1. Open the host and go to **Applications**. Expand the account, open its settings (the cogwheel), and
   select **Add FTP user**.
2. Enter the user name and the **home directory** (keep it a subfolder, not the account's home), and
   enable Transport Layer Security (TLS) if your client needs it.
3. **Save**, then **Save & Publish**.


FTP and SFTP access

In YAML

Add an `ftp` block under the system user - see The Source (YAML) view:

```yaml
system_users:
  - username: prod
    vhosts:
      - server_name: www.example.com
        app_type: shopware
        php_version: "8.4"
        cert_type: letsencrypt
    ftp:
      - user: prod_ftp
        homedir: /var/www/prod/public_html/ftp
```


FTP and SFTP access

Choose FTP or SFTP

A host uses **either** FTP or SFTP for all users. To use SFTP, add this above `system_users`:

```yaml
ftp_sftp: true
```

SFTP runs over port **222** through the existing FTP daemon and users, not the SSH service. Port 22
stays reserved for SSH. If your ERP needs another port, set it:

```yaml
ftp_sftp_port: 2222
```

Plain FTP uses port **21**.


FTP and SFTP access

Connect

Get the user name and password from the host's Credentials tab, then connect
with a client such as FileZilla using the host name, the user, and the right port (21 for FTP, 222 -
or your custom port - for SFTP).


FTP and SFTP access

Fix a "Login failed" error

- **Wrong credentials** - even a stray space in the password causes a `530` login error.
- **Home directory does not exist** - the path assigned to the user must exist on the server.
- **No TLS** - TLS is required and enforced. Enable "Explicit FTP over TLS" in your client. Only
  disable it for a system that genuinely cannot do TLS (passwords would be sent in plain text).
- **IP blocked** - your IP may be (temporarily) firewalled. Add it to the allow-list under the host's
  **Security** tab - see Security.


FTP and SFTP access

Related

- Advanced settings
- Applications
- Credentials
- Security


Advanced settings

advanced settings mail settings varnish rabbitmq operating system docker host advanced supervisor windows update new relic infrastructure database monitoring

# Advanced settings

The host's **Advanced** tab gathers configuration options for mail, caching services, file transfer, the operating system, and database monitoring. These options control the host's runtime environment.

> [!NOTE]
> Many Advanced options are hidden for cPanel and DirectAdmin hosts.

This tab covers:

- Mail settings - set up DomainKeys Identified Mail (DKIM) and a development mail catcher
- Varnish options - tune the Varnish HTTP cache
- RabbitMQ options - configure the RabbitMQ message broker plugins
- FTP server options - SFTP and FTPS file-transfer access
- Operating system - choose the OS, extra packages, and the maintenance window
- Advanced database monitoring - deep monitoring for your databases
- New Relic Infrastructure - send server metrics to your own New Relic account


Advanced settings

Mail settings

Set up **DKIM** (your mail domain's FQDN and a selector) so receivers can authenticate your outbound mail. You can also enable a **development mail catcher** (Mailpit or Mailhog) that captures outgoing mail so you can inspect it without delivering it. See Email.

> [!WARNING]
> A development mail catcher intercepts mail instead of sending it. Never enable it on a production host.


Advanced settings

Varnish options

Varnish provides HTTP caching. You can tune Varnish behavior from the Advanced tab. These options appear once an application has Varnish enabled. For details on caching strategy and configuration, see Services.

| Setting | Description |
| --- | --- |
| **Varnish Cache Size** | The memory Varnish uses to store cached content. It auto-scales to the server by default. Turn the toggle on to set your own size and unit. |
| **Varnish Flavor** | Choose the Varnish build: **Open Source** or **Enterprise**. Open Source is free. Enterprise needs a separate license. Written to the host YAML as `varnish_type`. |
| **Varnish Modules** | Available with the Open Source build. Turn it on to install the extra Varnish modules. |
| **Custom VCL** | Turn this on to use your own Varnish Configuration Language (VCL) instead of the default. |

By default, Varnish uses a default VCL that TurboStack tunes for your application type. To supply your own, turn on the custom VCL option and place your VCL file in `/etc/varnish/conf.d/` on the server.

> [!TIP]
> Start with the default VCL. Only switch to a custom VCL when you need caching rules the default does not cover.


Advanced settings

RabbitMQ options

RabbitMQ provides message queuing for your applications. The Advanced tab configures the broker itself. See Services for related service configuration.

This pane is only usable once RabbitMQ is in use on the host. Until then it shows the message that RabbitMQ is not activated, and asks you to first create an application with RabbitMQ enabled. Enable RabbitMQ on an application under **Configure application > Technologies**, then return here.

When RabbitMQ is active, you can select the broker plugins to install (`rabbitmq_plugins`). The field is a multi-select, so you can pick more than one:

| Plugin | What it adds |
| --- | --- |
| `rabbitmq_prometheus` | Exposes broker metrics in the Prometheus format, so you can collect them in your own metrics tooling. |
| `rabbitmq_shovel` | Moves messages from a queue on this broker to another broker. |
| `rabbitmq_shovel_management` | Adds the shovel configuration and status to the RabbitMQ management interface. |

```yaml
rabbitmq_plugins: [rabbitmq_shovel, rabbitmq_shovel_management]
```

Publish the host to install the plugins you selected.


Advanced settings

FTP server options

You can configure file transfer access, including SSH File Transfer Protocol (SFTP) and FTPS settings and the protocols you want to allow. These options appear once the host has an FTP user. For interactive shell access, see SSH access.

**Enable Valid Certificate For FTP Server** generates a Transport Layer Security (TLS) certificate for the FTP daemon using a hostname you choose. Turn the toggle on, then enter the **FTP hostname**. Clients that connect over FTPS then see a valid certificate instead of a self-signed one.

> [!IMPORTANT]
> The FTP hostname must point to the server's IP address, or the certificate cannot be issued.


Advanced settings

Operating system

You can select and configure the host's operating system and related settings.

| Setting | Description |
| --- | --- |
| OS selection | Choose the operating system, such as Debian or AlmaLinux. |
| Composer version | Choose the Composer version installed for your PHP applications (`composer_version`). |
| Supervisord support | Install a process manager for long-running background processes (`supervisor_enabled`). |
| `os_extra_packages` | Add extra OS packages - see Installing extra OS packages. Keep this list minimal. |
| Automatic update time | The daily time when routine package updates that do not need a reboot are installed (`system_packages_upgrade_time`). |
| Maintenance window | Set when updates that require a reboot are applied, so you can pick your least-critical time (`maintenance`). Add one or more day and hour windows. |

> [!TIP]
> Keep `os_extra_packages` as small as possible. Each added package increases the host's maintenance and security surface.

> [!TIP]
> Most security updates are applied automatically without a reboot. The **maintenance window** is for the occasional update that does need a reboot - set it to a low-traffic time (for example overnight) so the reboot never lands during your busiest hours.


Advanced settings

Supervisor

**Supervisord support** (`supervisor_enabled`) installs a process manager on the host. A process manager keeps a long-running process running: it starts the process, restarts it when it exits, and collects its output in a log file. Use it for queue workers, message-queue consumers and other background processes that must not stop.

Each system user gets its own instance, so you configure your processes without root access:

| Path | What it is |
| --- | --- |
| `~/.config/supervisor/conf.d/` | Your program configuration files. A sample file is placed here for you. |
| `~/.config/supervisor/log/` | The log output of the processes you defined. |

`~` is your system user's home directory, for example `/var/www/prod/`. After you add or change a configuration file, apply it with the `supervisorctl` command over SSH.

TurboStack's own way of running background processes is a user system service, managed by systemd. That needs no host-level setting and is the better starting point: it is already used for the queue workers and consumers of the supported applications. Turn on Supervisord support when your application or deployment tooling expects a supervisor instead.


Advanced settings

Windows update schedule

On a Windows host, the Operating System pane shows a **Windows update** schedule instead of the Linux settings above. The schedule is the Windows counterpart of the maintenance window. It sets the day and the hour when Windows updates are installed, so a reboot happens at a moment you choose.

The schedule is a table with a **Day** and an **Hours** column. Click **Edit** on the entry, select a day and an hour, then click **Save**. A new host starts with Sunday 09:00.

> [!NOTE]
> This applies only to hosts running Windows. On Linux hosts you set the maintenance window instead, and the Composer, Supervisord and extra-package settings are not shown on a Windows host.


Advanced settings

Advanced database monitoring

**Advanced Database Monitoring** collects query-level metrics for the databases on this host and sends them to a central monitoring master server, where you read the dashboards. Enable it when you need to see which queries are slow, not only that the database is busy. See Monitoring.

The pane is only usable when the host has a database service configured (MySQL, PostgreSQL, Microsoft SQL Server or MongoDB). Without one it shows **No database server configured** - add a database on the Services tab first.

| Setting | Description |
| --- | --- |
| Enable | Turns advanced database monitoring on for this host. The remaining fields appear once it is on. |
| Master server hostname | The host name of the monitoring master server that collects the metrics (`pmm_master.server_hostname`). Required when monitoring is enabled. |
| Sampling rate | Under **Advanced Settings**. Metrics are collected from every Nth query (`pmm_sampling_rate`, default `50`). A lower number gives more detail, and adds more load to this server and to the master. |

```yaml
pmm_master:
  server_hostname: monitoring.example.com
pmm_sampling_rate: 50
```

> [!TIP]
> Keep the default sampling rate unless you are investigating a specific problem. Lower it temporarily, then set it back.

If you do not have a monitoring master server yet, you can run one on TurboStack - see Self-hosted platforms.


Advanced settings

New Relic Infrastructure

The **New Relic Infra** pane connects the server itself to your own New Relic account. Server metrics such as processor, memory, disk and processes then appear next to the application data you already collect there. This is a bring-your-own-account setting: TurboStack installs and configures the agent, you supply the license key and keep your own New Relic subscription.

The pane only appears in the left menu when at least one application on this host has New Relic application performance monitoring enabled. Turn that on first under **Configure application > Monitoring > New Relic APM** - see Applications.

| Field | Description |
| --- | --- |
| **License Key** | The license key of your New Relic account. Use the main account license key, not the separate infrastructure key. |
| **Log Configuration** | Optional. Paste valid YAML that tells the infrastructure agent which log files to forward. TurboStack writes it to `/etc/newrelic-infra/logging.d/customer.yml` on the server, so use the format the agent expects there. Leave it empty to forward no logs. |

Leave the license key empty to not install the infrastructure agent. Publish the host to apply either change.

> [!NOTE]
> This pane covers the server's own metrics. The **application performance monitoring** keys for New Relic, Tideways and Blackfire, and the **Docker** and **Kubernetes** settings, are configured **per application** - in the **Configure application** dialog (Technologies and Monitoring tabs), not on the host's Advanced tab. See Applications.


Advanced settings

Related

- Installing extra OS packages
- FTP and SFTP access
- User system services - the alternative to Supervisor.
- Services
- Applications
- SSH access
- Monitoring
- Hosts


Installing extra OS packages

os_extra_packages install apt package extra os packages debian package php extension package

# Installing extra OS packages

TurboStack manages your servers for you, so you do not have root access to run `apt install` yourself.
To add extra operating-system packages - for example an extra PHP extension - you declare them in
your host configuration with **`os_extra_packages`**, and TurboStack installs them for you. Because
the list lives in your configuration, the same packages are reproduced when you set up similar
servers later.

> [!WARNING]
> This is an advanced feature. Do **not** use `os_extra_packages` to install packages for services
> that TurboStack already manages - such as MySQL/MariaDB, PostgreSQL, Elasticsearch/OpenSearch,
> Redis, Varnish, PHP or the web server. Installing your own versions of these conflicts with the
> managed setup and can break the host. Use it only for genuinely extra packages (for example a small
> tool or a PHP extension). If you are not sure exactly what you need here, **contact
> support first** - they will set it up safely with you.


Installing extra OS packages

Where to set it

You can set `os_extra_packages` in two ways:

- **Advanced tab** - open the host, go to **Advanced > Operating System > OS Extra Packages**, and
  pick from the common packages offered. See Advanced settings.
- **Source (YAML) view** - for any package that is not in the list, add it directly as YAML. See
  The Source (YAML) view.

`os_extra_packages` is a **list** (it must be an array, not a single value). It can be set on a host,
or on a group to apply to every member host.

```yaml
os_extra_packages:
  - acl
```


Installing extra OS packages

Find the exact package name

Packages are installed with Debian's apt package manager, so you need the exact apt package name.
Connect over SSH and search for it (this also shows whether it is already installed):

```bash
apt search <packagename>
```

For example, to find PHP extension packages for PHP 8.2:

```bash
apt search php8.2
```

Copy the exact names into your configuration:

```yaml
os_extra_packages:
  - php8.2-amqp
  - php8.2-ssh2
  - php8.4-dom
```


Installing extra OS packages

Install packages for your active PHP version

If your configuration defines `php_main_version`, you can reference it so the right PHP packages are
installed automatically when you change versions:

```yaml
php_main_version: "8.2"
os_extra_packages:
  - php{{ php_main_version }}-amqp
  - php{{ php_main_version }}-ssh2
```


Installing extra OS packages

Apply and verify

1. **Save & Publish** the host. TurboStack installs the listed packages (apt, kept at "present")
   while applying the configuration - see Publishing changes.
2. Verify over SSH that a package is installed:
   ```bash
   dpkg -l <packagename>
   ```

> [!TIP]
> Keep `os_extra_packages` as small as possible. Every extra package adds to the host's maintenance
> and security surface. Add only what your application needs.


Installing extra OS packages

Related

- Advanced settings
- The Source (YAML) view
- Publishing changes
- SSH access
- Support
- Hosts


Git deployment

git deployment deploy from git git integration continuous deployment

# Git deployment

Git Deployment lets you deploy your application code from a Git repository onto a TurboStack host.


Git deployment

Opening the GIT tab

1. Go to the **Applications** tab of your host.
2. Open the settings for the application you want to deploy to.
3. In the **Configure application** dialog, select the **GIT** tab.


Git deployment

Adding a Git integration

1. Select **Add GIT integration**.
2. In **Git Settings**, configure the integration:

| Setting | Description |
|---|---|
| **Remote repository** | The Git repository to deploy from. |
| **Version/branch** | The branch or version to deploy. |
| **Deployment path** | The path on the host where the code is deployed. |

3. Save your changes.

You can add multiple repositories to a single application by repeating these steps.


Git deployment

Private repositories over SSH

For private repositories accessed over SSH, the server must be able to authenticate to the repository.

1. Save or generate the system user's SSH keys on the server - a notice in the **GIT** tab reminds you to do this.
2. Add the resulting public key to your Git provider as a deploy key.
3. Configure the Git integration with the SSH repository URL.

> [!IMPORTANT]
> Without the system user's SSH keys saved on the server, deployments from private repositories over SSH will fail to authenticate.

> [!TIP]
> Use a dedicated branch for deployments so you control exactly what reaches the server.


Git deployment

Related

- Applications
- Versioned releases with a symlink layout - atomic deploys and rollback from CI/CD.
- SSH
- Credentials
- Hosts


Applications

applications system users vhosts applications PHP databases FTP certificates technologies

# Applications

The host's **Applications** tab is where you manage what the server runs. It uses a simple
two-level model: a host has one or more **system users** (operating-system accounts that own
files and run apps), and each system user has one or more **applications** - also called
*applications* or *vhosts*.

> [!NOTE]
> On cPanel, DirectAdmin and Windows hosts, accounts and applications are managed by the control
> panel and this tab is presented differently.

This tab covers:

- Working with an account - expand a system user, edit its settings, or add new ones
- Clone an application - copy an existing account into a new one
- Configure application - hostnames, certificates, technologies, monitoring, Git, and databases
- FTP users - add FTP/SSH File Transfer Protocol (SFTP) access for a system user


Applications

Working with an account

Each system user appears as a collapsible row. Click the **▾ chevron** on the right to expand it.

When expanded, the row shows:

- **Account actions** (icons next to the name): **copy** the username, **edit** the account,
  **settings**, and **delete**.
- **Applications** - the list of applications under this account, each with **copy**, **settings**
  (opens *Configure application*) and **delete** icons, plus an **Add app or database** button.
- **FTP Users** - FTP accounts for this user, with an **Add FTP user** button.

At the bottom of the tab:

- **Add new app** - create a new system user (enter a **Username** and optional **Description**).
- **Clone app** - copy an existing account's configuration into a new one.
- **Migration Hero** - migrate an existing site onto the host with guided assistance.

> [!WARNING]
> Deleting a system user removes the applications that belong to it. Review its contents first.


Applications

Clone an application

**Clone app** copies an existing account into a new one. It replicates the account's configuration
and can also copy its files and its database. Use it to build a staging copy from production, or to
promote a staging setup to production, without configuring everything again.

The clone wizard runs in these steps:

1. At the bottom of the **Applications** tab, click **Clone app**.
2. Select the **source host** and the **account** to clone. The source can be this host or another
   host you manage.
3. Choose the **destination account**. Pick an existing account or create a new one. Then choose
   whether to clone the **database**, the **files**, or both. Click **Next**.
4. Select the **hostname(s)** for the new account and the **certificate** type to activate. Click
   **Next** to start the clone.
5. TurboStack clones the account. The **publishing** indicator in the top left shows progress. When
   it finishes, the top right shows a success message with a timestamp.

> [!TIP]
> Clone from production to a staging account to test a change on a real copy of your site before you
> apply it live.

> [!NOTE]
> Cloning the database and files copies data as well as configuration. Clone into a staging account,
> not over a live one you still need.


Applications

Configure application

Use **Add app or database**, or the **settings** icon on an application, to open the **Configure
application** dialog. Its settings are organized into tabs.


Applications

Name

Give the application a name, or leave **Default** enabled to use the default naming.


Applications

Hostnames

Set the domain(s) the application answers to, and its Transport Layer Security (TLS) certificate.

- **Hostname** - one or more domains (`server_name`); add or remove rows with **Add hostname**
  / **Delete**.
- **Certificate** - the certificate type:
  - **Let's Encrypt** - automatic certificates. Choose a **Certificate provider** (and, for
    Cloudflare Domain Name System (DNS), supply a **Cloudflare API token**) and, under **Advanced settings**, a
    **Certificate challenge** (`http` is recommended as the most compatible).
  - **Self-signed** - a self-signed certificate.
  - **Custom** - paste your own **certificate** and **private key**.

> [!IMPORTANT]
> Custom certificate and private-key material is sensitive - treat it like any other secret.


Applications

Technologies

Enable the runtimes and services this application needs. The left menu lists each technology;
selecting one shows its settings.

| Technology | What you configure |
|---|---|
| **Application Settings** | The **App Type** (e.g. Generic, WordPress, Magento, Odoo...). |
| **PHP** | Enable PHP and pick a **version**; advanced PHP-FPM tuning, OPcache and IonCube. |
| **Python** | Enable Python and set a **version**. |
| **Ruby** | Enable Ruby, set a **version** and startup command, optionally **Sidekiq**. |
| **Docker** | Run the application in Docker. |
| **K8s** | Enable Kubernetes for the application. |
| **Varnish** | Enable the Varnish HTTP cache for this application. |
| **NodeJS** | Enable Node.js and pick a **version**. |
| **.NET** | Enable .NET, pick a **version** and an optional listen port. |
| **RabbitMQ** | Enable the RabbitMQ message broker for this application. |
| **Reverse Proxy** | Forward requests to a backend: set the upstream **IP/Hostname** and **Port**. |

See Services for the server-level versions these build on.


Applications

Monitoring

Set a **Monitoring URL** for the application's health check, and optionally enable application
performance monitoring - **New Relic**, **Tideways**, or **Blackfire**. See
Monitoring (concepts).


Applications

Git

Configure Git-based deployment: the **remote repository**, **version/branch** and **deployment
path**. Add multiple repositories with **Add GIT integration**.


Applications

Database info

View and manage the application's databases.

- **MySQL** / **PostgreSQL** - the auto-provisioned **database**, **username** and **password**
  (hidden by default; use the eye and copy icons). Open **phpMyAdmin** directly when available.
- **RabbitMQ** - only listed when this application has RabbitMQ enabled. It shows the **VHost**,
  **Username** and **Password** to connect to the message broker, plus a **Go to RabbitMQ** button
  that opens the management interface. The virtual host and the user are named after the system
  user, so each account keeps its own queues.
- **User Credentials** - the system user's own login.
- **Extra database users** - add additional database users with a **readonly** or **admin**
  role (each gets its own password). Use **Add extra database user**; remove with the delete icon.

> [!TIP]
> Use an extra **readonly** user for reporting or integrations that should not modify data.


Applications

FTP users

Add an FTP/SFTP account for a system user with **Add FTP user**: set the **user**, the **home
directory**, and whether **TLS** is required. Manage credentials later from the
Credentials tab.


Applications

Related

- Services - web server, databases, caching and search.
- Git deployment - deploy application code from a Git repository.
- Migration Hero - migrate an existing site onto this host.
- Credentials - retrieve the access details created here.
- FTP and SFTP access - give an external system file access.
- Publishing changes - apply your changes to the server.
- Source (YAML) view - edit the same configuration as YAML.


Migration Hero

migration hero migrate site move application site migration

# Migration Hero

Migration Hero copies an existing site from an external server onto a TurboStack host, guiding you through the process with a step-by-step wizard. It transfers the configuration, files and database for a fast setup with minimal effort.

> [!NOTE]
> To move a site from one TurboStack host to another, use Account Cloning instead of Migration Hero.


Migration Hero

Before you start

The destination application must already exist and have completed a successful Save & Publish at least once. Migration Hero copies data into an existing account; it does not create one for you.

You also need valid SSH credentials for the remote source (a password or an SSH key). Without them, TurboStack cannot connect to copy the data and databases.


Migration Hero

Opening Migration Hero

1. Open the host you want to migrate into.
2. Go to the **Applications** tab.
3. Select **Migration Hero**.


Migration Hero

Running the wizard

Migration Hero is a three-step wizard.


Migration Hero

1. Source Information

Describe the remote server you are migrating from:

| Field | Description |
|---|---|
| **IP/Hostname Remote Source** | The address of the external server holding the site. |
| **Username Remote Source** | The user account used to connect to the remote server. |
| **Authentication Method** | How TurboStack authenticates: a password or an SSH key. |

Then provide the credentials for the method you chose:

- **Password** - enter the password for the remote user, then click **Next**.
- **SSH key** - click **Generate SSH Key**, add the generated public key to the `.ssh/authorized_keys` file of the remote user on the source server, then click **Next**.


Migration Hero

2. Destination app

Choose the destination account on this host that will receive the site. This must be an existing account.

Then select what to migrate using the toggles:

- **Clone files** - copy the application files.
- **Clone database** - copy the database.

Enable one or both, then click **Next**.


Migration Hero

3. Destination VHost

For each application, set the **hostname(s)** it should listen on and choose the **certificate type** to generate (for example `letsencrypt`). When you are done, click **Start Import** to begin the migration.

A migration progress popup appears in the bottom-right corner. When it finishes, the migration is complete.


Migration Hero

What Migration Hero changes

Migration Hero only copies the data and database(s) from the remote host. It makes no changes on the remote system, so your source server keeps running untouched.

> [!NOTE]
> Because the migration is a copy, you can safely test the result on the destination before switching any traffic away from the original server.


Migration Hero

Related

- Applications
- Git deployment
- Publishing changes
- Hosts


TLS certificates

turbostack tls ssl certificate lets encrypt https wildcard certificate dns challenge cloudflare hosted power dns bring your own certificate

# Transport Layer Security (TLS) certificates

TurboStack secures your applications with HTTPS. You choose how each application gets its certificate on
the **Applications** tab, under an application's **Hostnames** settings (`cert_type`).


TLS certificates

Certificate types

| `cert_type` | Use it for |
|---|---|
| `letsencrypt` | **Recommended.** Free, automatic certificates that renew themselves. |
| `selfsigned` | Internal/test sites where a trusted certificate isn't required. |
| `custom` | **Bring your own certificate** - buy one from any authority and import the **certificate**, **chain** and **private key** (GUI or YAML). |

> [!IMPORTANT]
> Custom certificate and private-key material is sensitive - treat it like any other secret.


TLS certificates

Let's Encrypt (automatic HTTPS)

Set `cert_type: letsencrypt` and publish. TurboStack requests the certificate and **renews it
automatically** before it expires. List every hostname the site answers to in `server_name`
(space-separated) so they are all covered.

> [!NOTE]
> For Let's Encrypt to succeed, the domain must already point to the server - see
> Connecting your domain.

> [!TIP]
> If you cannot adjust DNS yet but still need HTTPS, start with a `selfsigned` certificate and switch
> to `letsencrypt` once the domain points to the server.


TLS certificates

Validation challenge: HTTP vs DNS

Under **Advanced settings** you can choose the `cert_challenge`:

- **`http`** (recommended, most compatible) - validates by serving a file over HTTP. The domain
  must resolve to the server.
- **`dns`** - validates via a Domain Name System (DNS) record. Use it for wildcard certificates, or for domains
  that don't yet point to the server. When your domain uses **Hosted Power DNS**, TurboStack creates
  the validation record automatically. For domains on **Cloudflare**, you supply a **Cloudflare API
  token** so TurboStack can create the record for you.


TLS certificates

Wildcards and multiple domains

- **Multiple domains/subdomains:** add them all to `server_name`.
- **Wildcard (`*.example.com`):** requires the **DNS** challenge.


TLS certificates

Bring your own certificate

Most sites only need Let's Encrypt. To use a certificate you bought yourself, buy it from any
certificate authority, then set `cert_type: custom` and import it - either in the GUI (the application's
**Hostnames** settings) or in YAML. Paste the **private key** and the **full chain** in order: your
certificate, then the intermediate certificate(s), then the root. If the publish fails, the
intermediates are usually in the wrong order.

> [!NOTE]
> You almost never need to buy a certificate - Let's Encrypt covers nearly all cases. If you are
> unsure, contact support.


TLS certificates

Generate a CSR

To buy a certificate you provide a Certificate Signing Request (CSR).

Generate the key and CSR on the server so the private key never leaves it. Create a config file
`server.san` (use `*.example.com` as `commonName` for a wildcard):

```ini
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
countryName = BE
organizationName = Example Company
commonName = www.example.com
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.example.com
DNS.2 = example.com
```

```bash
openssl req -sha256 -new -newkey rsa:4096 -nodes -keyout server.key -out server.csr -config server.san
```

Give `server.csr` to your certificate authority.


TLS certificates

Extract a certificate from a PFX file

If you were given a `.pfx` (Personal Information Exchange) file, split it into the certificate and key to paste them in:

```bash
openssl pkcs12 -in certificate.pfx -nokeys -out certificate.pem -nodes   # certificates
openssl pkcs12 -in certificate.pfx -nocerts -out priv-key.pem  -nodes    # private key
```


TLS certificates

Build a PFX file

To hand a certificate to a Windows or Internet Information Services (IIS) system, combine the private key, certificate and chain into one `.pfx`:

```bash
openssl pkcs12 -export -out server.pfx -inkey server.key -in server.crt -certfile chain.pem
```

> [!NOTE]
> OpenSSL 3.x uses a newer default encryption that some older Windows or IIS versions cannot import. If the target refuses the file, add `-legacy`:
> `openssl pkcs12 -export -legacy -out server.pfx -inkey server.key -in server.crt -certfile chain.pem`


TLS certificates

Buy a certificate through the Customer Center

You can also order a paid certificate, still commonly sold as a Secure Sockets Layer (SSL)
certificate, through the Customer Center at
portal.hosted-power.com. The portal generates the Certificate
Signing Request (CSR) for you and handles the paperwork, then hands you the issued certificate to
import.

> [!NOTE]
> You almost never need to buy a certificate. Let's Encrypt covers nearly all cases. If you are
> unsure whether a paid certificate is right for you, contact support first.

To order a certificate:

1. Open the Customer Center and start a new certificate order.
2. Choose the certificate product. Unless you were told to get a specific type, choose a **Sectigo
   Positive SSL** certificate.
3. Provide the CSR. If you already have one, paste it. If not, choose the option to generate a new
   CSR now, and the portal creates it for you.
4. Enter the organization data for the requesting organization. For a Sectigo Positive SSL
   certificate this data is not verified against public records.
5. For **Certificate Common Name**, enter the domain you want the certificate to cover.
6. Choose the approver email address for domain-control validation (see below).


TLS certificates

Domain-control validation

The certificate authority confirms you control the domain by sending a validation email. The approver
address must be on the root domain of the requested domain, and it must be one of these five
addresses:

- `admin@example.com`
- `administrator@example.com`
- `hostmaster@example.com`
- `webmaster@example.com`
- `postmaster@example.com`

> [!IMPORTANT]
> Make sure you can receive mail at one of these five addresses on your domain before you order.
> No other address is accepted for validation.

After you complete the order, the validation email arrives at the address you chose. Follow its
instructions to confirm the request. Once validated, the certificate is usually issued within about
10 minutes and becomes available in the Customer Center. Import it into your application as a custom
certificate (see Bring your own certificate).


TLS certificates

Redirecting to HTTPS

On TurboStack the HTTP-to-HTTPS redirect is handled for you once a certificate is active - see
Force HTTPS. Also set your application's site URL to
`https://` so it generates secure links.


TLS certificates

Related

- Applications - where you set `server_name` and `cert_type`.
- Connecting your domain - DNS prerequisites.
- Security and Security hardening.
- Hosts


Backups and restore

backups restore backup jobs file backup database backup recovery

# Backups and restore

The host's **Backups** tab lets you browse backup jobs and restore data from them. You can restore files and databases to different targets so you can verify recovered data before it overwrites your live environment.

This tab covers:

- Automatic backups - the scheduled backups TurboStack takes for you
- Browsing backup jobs - find a backup and open its contents
- Creating an on-demand backup - start a backup yourself
- Tracking backup jobs - follow backup and restore jobs in progress
- Restoring files - recover files to a chosen target
- Restoring MySQL - recover MySQL databases, tables, or a dump
- Restoring PostgreSQL - recover PostgreSQL databases, tables, or a dump


Backups and restore

Automatic backups

TurboStack takes **automatic daily backups** of your host, kept for **20 days**, in addition to the on-demand backups you can start yourself. Backups cover your files and databases. Use the steps below to browse and restore from any available backup.

> [!TIP]
> Want your backups kept longer than 20 days, or extra snapshots? Ask Support.


Backups and restore

Browsing backup jobs

Each backup job in the list shows:

| Field | Description |
| --- | --- |
| Job ID | The unique identifier for the backup job. |
| Date/time | When the backup was taken. |
| Size | The size of the backup. |
| Actions | A **Contents** button opens the backup so you can browse it and choose what to restore. |

Backups are grouped by content type - **Files**, **MySQL** and **PostgreSQL** - which you select on the left. When you start a restore, a dialog opens and updates automatically with progress until the restore completes.

> [!TIP]
> Restore to `~/hprestore` or to a new database first, then verify the recovered data before overwriting live data.


Backups and restore

Creating an on-demand backup

Besides the automatic scheduled backups, you can create a backup yourself at any time.

1. Open the host's **Backups** tab and select **Create Backup** from the left.
2. In the dialog, tick what to include - **Files**, **MySQL** and/or **PostgreSQL**. The database
   options appear only for the databases enabled on the host.
3. Click **Create Backup**.


Backups and restore

Tracking backup jobs

The **Jobs** entry on the left shows the status of backup and restore jobs in progress, so you
can follow a running backup or restore to completion. Each row lists the user, the date, the job
type, the backup type, the status and the time it finished; the eye icon at the end of a row opens
the job's details.


Backups and restore

Restoring files

When you restore files, choose one of the following targets:

| Target | Description |
| --- | --- |
| Recovery folder | Restore into the dedicated `~/hprestore` folder. |
| Overwrite existing | Restore files back to their original location, overwriting what is there. |
| Custom path | Restore into a path you type, so you can recover to a specific location. |

To restore files:

1. Open the host's **Backups** tab.
2. Select the backup job you want to restore from.
3. Choose **Files** as the content type.
4. Select a target: the `~/hprestore` recovery folder, overwrite existing files, or a custom path you
   enter.
5. Start the restore and follow the progress in the dialog.


Backups and restore

Restoring MySQL

To restore MySQL data:

1. Open the host's **Backups** tab.
2. Select the backup job you want to restore from.
3. Choose **MySQL** as the content type.
4. In the tree browser, select the databases (and, if needed, individual tables) to restore from the backup.
5. Start the restore. The selected data is restored into your `~/hprestore` folder, not directly into the live database - from there you can review and import it.


Backups and restore

Restoring PostgreSQL

PostgreSQL restores the same way as MySQL:

1. Open the host's **Backups** tab.
2. Select the backup job you want to restore from.
3. Choose **PostgreSQL** as the content type.
4. In the tree browser, select the databases (and, if needed, individual tables) to restore from the backup.
5. Start the restore. The selected data is restored into your `~/hprestore` folder, not directly into the live database - from there you can review and import it.


Backups and restore

Related

- Services
- Applications
- Backups and recovery
- Hosts


Credentials

credentials passwords access details database credentials FTP server access

# Credentials

The **Credentials** tab gathers the access details for a host - server-level access and the
credentials for each system user account.

This tab covers:

- Server - host-level access, addresses, and platform details
- Per-account credentials - databases, FTP, and user passwords

> [!IMPORTANT]
> Credentials are secrets. Passwords are hidden by default - click the eye icon to reveal one.
> Use the copy icons rather than retyping, and never share or store these values insecurely.


Credentials

Server

The **Server** section lists host-level access:

- **Hostname** - the server's fully-qualified name.
- **Server Public IPv4** and **Server Public IPv6** - the server's public addresses.
- **Platform**, **Webserver**, and the database version.

On a host managed by a control panel (cPanel or DirectAdmin, see
System types), the Server section also shows the panel's
**admin** login (the `admin` account and its password). Use it to sign in to the control panel
itself. The server's root password is not shown; server-level access is managed for you by
Hosted Power.


Credentials

Per-account credentials

Each system user has its own section showing its account name, PHP version and applications, plus
the credentials it owns:

- **MySQL databases** - database, user and password for each database.
- **Database extra users** - additional read-only or admin database users.
- **PostgreSQL databases** - same layout as MySQL, when PostgreSQL is enabled.
- **FTP users** - FTP username, password and path.

Every value has a copy icon, and passwords have a reveal toggle.


Credentials

Related

- Applications
- SSH access
- Hosts


Health

health monitoring top issues service checks CPU memory disk host monitoring

# Health

The **Health** tab is a live overview of a host. It surfaces the most important problems first
and shows real-time resource usage and the status of every monitored service.

This tab covers:

- Top issues - ranked list of detected problems
- Latest reports - investigation reports for this host
- Host monitoring - CPU, memory, swap, and disk graphs
- Services - status of every monitored service check


Health

Top issues

A ranked list of the most important problems detected on the host. Each issue shows a severity
(CRITICAL / HIGH / MEDIUM / LOW / INFO) and a category (PERFORMANCE / AVAILABILITY / SECURITY /
STABILITY). Expand an issue to see what is happening, a recommended fix, and links to open the
related investigation reports.

> [!TIP]
> The list is ordered by importance, and not every issue is equally urgent. Start with **CRITICAL**
> and **HIGH** - these affect availability, performance or security right now. **MEDIUM**, **LOW**
> and **INFO** are worth knowing about but rarely need immediate action; handle them during normal
> maintenance.

When nothing has been detected, the panel is empty and reports that there are no top issues for the
host.


Health

Latest reports

The most recent investigation reports for the host, newest first. Open a report to read its
full details, or download the Portable Document Format (PDF) when available.

When you open a report, its address appears in the browser URL, so the report is bookmarkable
and shareable. Use the **Link** button in the report header to copy that address to your
clipboard (the button confirms with **Copied**). Anyone who opens the copied link, and who has
access to the host, lands on the Health tab with the same report already open.

> [!TIP]
> Paste the link into a support ticket or a message to a colleague so they see the exact report
> you are looking at, instead of describing it.


Health

Host monitoring

Resource-usage cards for the four things that most often cause a slow or failing site. Each card
shows a current percentage, an OK / Warning / Critical status, and a graph. Use the
**1H / 8H / 1D / 7D** buttons to change the time range (1 hour to 7 days). The view refreshes
automatically.

| Card | What it measures | What a high value means and what to do |
| --- | --- | --- |
| **CPU** (Central Processing Unit) | How busy the server's processor is. | Sustained high CPU means the server is doing more work than it can keep up with, so pages slow down. Look for a traffic spike, a heavy task, or inefficient code. See High CPU and load. |
| **RAM** (Random Access Memory) | How much of the server's working memory is in use. | High memory use is normal up to a point. The risk is running out - see swap below. |
| **Memory swap** | Disk space used as overflow when RAM is full. | If swap is rising, the server has run out of fast memory and is using slow disk instead, which makes everything slower. See Out of memory. |
| **Disk** | How full the server's storage is. | A full disk causes uploads, logs, databases and backups to fail. Free up space before it reaches 100%. See Disk space. |

> [!TIP]
> Use the 7-day (7D) view to tell a one-off spike from a steady trend. A single short spike is
> usually harmless; a line that climbs day after day needs attention.


Health

Services

A list of all monitored service checks for the host - for example the database, web server, cache and
connectivity checks. Each check shows its status (OK, Warning, Critical or Unknown), the latest output
from the check, and when it last ran. An **Unknown** status means the check could not determine the
service state, for example because it did not return a result.

A check in Warning, Critical or Unknown state is the place to start when something is wrong: the output
usually names the exact problem (for example a service that is not running, or a certificate about to
expire). Many issues can be resolved from the command-line tool or by
publishing a corrected configuration.

> [!TIP]
> The Health tab covers one host. For an overview across all your hosts, use
> Monitoring. For how monitoring works, see
> Monitoring (concepts).


Health

Related

- Monitoring
- Threat Center
- Hosts


Hosts

hosts server list host workspace configuration tabs

# Hosts

A **host** represents one of your servers and the configuration it should run. The **Hosts**
area is your starting point: browse all your servers, check their live health, and open any host
to configure it.

> [!NOTE]
> Editing a host changes its *intended* configuration. Changes only take effect on the server
> once you **publish** them - see Publishing changes.

- The Hosts list - browse and search your servers
- The host workspace - configuration tabs and header actions


Hosts

The Hosts list

After signing in you land on the **Hosts** dashboard (also reachable from the sidebar, at `/`).

Each row shows the **host name**, a **configuration summary** (application types, web server,
database versions), a **server usage** badge, live **health indicators** (status, memory, CPU,
disk - hover for details), and a **Manage** button.

Use the **search box** to filter by name; the **Number of Items** control sets the page size. To
search across groups and templates too, use the global Search.


Hosts

The host workspace

Click **Manage** on a host to open it (`/hosts/{id}`). The configuration is organized into tabs,
with action buttons in the top-right header.


Hosts

Configuration tabs

| Tab | What it covers |
|---|---|
| Health | Live monitoring: top issues, CPU/memory/disk usage, service checks |
| Threat Center | Security findings and vulnerabilities (TurboRadar) |
| Applications | Applications (vhosts) and their system users |
| Services | Web server, databases, caching and search engines |
| Advanced | Mail, Varnish, RabbitMQ, FTP server, operating system |
| Groups | Group membership for this host |
| SSH | SSH keys and authentication |
| Security | TurboShield, IP allow-list, GeoIP, web application firewall |
| Backups | Restore files and databases from backups |
| Credentials | Server and per-account access details |


Hosts

Header actions

- **`</>` Source** - switch to the YAML editor (`/hosts/yaml/{id}`); in Source view a **GUI**
  button switches back and a **Copy** button copies the configuration.
- **Revisions** (clock icon) - open the History view (revisions, deploys, cloning).
- **Save** - store changes without deploying. **Save & Publish** - store *and* deploy (see
  Publishing changes).

> [!TIP]
> Prefer the **GUI** editor for everyday changes and **Source** (YAML) for advanced or bulk
> edits. Both edit the same configuration. Set your default in
> Profile & preferences.

When a host's configuration is empty, you can pre-fill it with **Copy > From host** or
**Copy > From template** (see Templates).


Hosts

Next steps

- Publishing changes - apply your configuration to the server.
- Applications and Services - configure what the host runs.


Publishing changes

publish deploy save and publish full publish deployment types rollback

# Publishing changes

Changing a host's configuration does not affect the running server until you **publish** it.

- Save vs. publish - what each action does
- Deployment types - choose the right publish mode
- Preview what publishing will do - the On publish indicator
- Following a deployment - track progress and review logs


Publishing changes

Save vs. publish

- **Save** stores your changes in TurboStack only. The server is unchanged, and an **unpublished
  changes** badge appears as a reminder.
- **Save & Publish** stores your changes *and* deploys them so the server matches your
  configuration.


Publishing changes

Deployment types

Open the **Save & Publish** menu (the ▾ next to the button) to choose how the configuration is
applied:

| Action | What it does | When to use |
|---|---|---|
| **Save & Publish** | Applies your (unpublished) configuration changes to the server. | Everyday changes. |
| **Save & Full Publish** | Runs a complete deployment that re-applies the whole configuration. | After larger changes, or to be thorough. |
| **Save, Delete & Full Publish** | Full deployment that **permanently removes** anything you deleted from the configuration. | Only when you intend to remove resources and their data. |

> [!WARNING]
> **Save, Delete & Full Publish** permanently destroys the data associated with objects you
> removed from the configuration. You must type `DELETE` to confirm. Use it only when you are
> certain.


Publishing changes

Preview what publishing will do

Before you publish, TurboStack shows an **On publish** indicator in the host header and in the
History view. It tells you the scope of the next publish, so there are no
surprises:

| On publish shows | What it means |
|---|---|
| **Nothing to publish** | The server already matches your saved configuration. |
| A list of components (for example `nginx`, `php`, `mysql`) | Only these parts are redeployed, which is faster. |
| **Full Deploy** | The whole configuration is re-applied. |

TurboStack only escalates to a full deployment when a change is structural, such as adding a
system user. Ordinary setting changes redeploy just the affected components. Changes that cancel
each other out, or backup settings, do not trigger a deployment on their own.


Publishing changes

Following a deployment

When you publish, a progress dialog tracks the deployment with a live spinner and the latest log
output, refreshing automatically until the job finishes, errors, or times out. While a
deployment is running, the publish and credentials actions are temporarily disabled to prevent
overlapping deployments.

You can review every past deployment - including who triggered it, the result, and the full
logs - on the **Deploys** tab of the History view.

> [!TIP]
> If a change causes a problem, restore an earlier revision from the
> History view and publish it to roll back.


Publishing changes

Related

- History (revisions, deploys & cloning)
- Credentials
- Hosts


revisions history deploys cloning revert rollback configuration history

# History - revisions, deploys and cloning

The **Revisions** button (clock icon) in a host's header opens the **History** view. It has
three tabs: **Revisions**, **Deploys**, and **Cloning**. Each tab uses a two-pane layout: a
searchable list on the left, and the full detail of the selected entry on the right.

- Revisions - view and revert configuration changes
- Deploys - deployment log and full output
- Cloning - copy an account between hosts or users

The header of the History view also shows an **On publish** indicator: it tells you what
publishing will do right now, before you start. See
Preview what publishing will do.


Revisions

Every time you save, TurboStack records a **revision**. The left pane lists the change history,
newest first, with the author, their avatar, and how long ago the change was made. Consecutive
saves that belong to one change are grouped into a single entry. Select an entry to see its
detail: which configuration paths changed, the before and after values (the net difference), and
whether the revision has been published. Use the search box to filter the list.

- **Revert revision** - restore the configuration to an earlier state. A confirmation shows the
  current configuration next to the after-revert preview before you apply it.

> [!TIP]
> Reverting only changes the configuration; publish afterwards to apply the rollback to the
> server (see Publishing changes).


Deploys

The Deploys tab is the deployment log. The left pane lists each deployment with its author,
date, and status (**Published**, **Error**, or **Partially published**). Select an entry to see
its detail: the deploy type (**Deploy** / **Full Deploy** / **Full & Reset Deploy**), the
**Components** deployed, the start and finish times, and the full **Output**. The output is shown
inline, which is useful for diagnosing a failed publish. For a deployment that ran across several
hosts, the output is grouped per host.


Cloning

The Cloning tab is a read-only record of **account clones**. Cloning copies an application
account (its files and/or its database) from a source to a destination:

| Field | Meaning |
|---|---|
| Source Host / Source User | The account being copied from. |
| Destination User | The account being copied to. |
| Clone Files | Whether file data is copied. |
| Clone Database | Whether database data is copied. |

Select an entry to see its full **Parameters**. You start a new clone from the **Applications**
tab (the **Clone app** button in the footer), not from this tab - see
Applications.


Related

- Publishing changes
- Applications
- Hosts


Security

security turboshield firewall web application firewall waf virtual patching owasp top 10 waf notification email ip allow-list geoip

# Security

The host's **Security** tab is where you configure how incoming web traffic is protected. This page covers the practical configuration steps. For how the underlying protections work, see the Security overview.

> [!NOTE]
> Security settings can also be applied at the **group** level and inherited by every host in the group. See Groups.

This tab covers:

- TurboShield - traffic filtering, bot controls and attack detection
- IP allow-list - trusted IP addresses and ranges that bypass blocking
- GeoIP filtering - allow or block traffic by country
- Web Application Firewall - block requests matching known attack patterns
- Automatically managed protections - the firewall TurboStack manages for you


Security

TurboShield

TurboShield protects your applications against malicious web traffic and Distributed Denial of Service (DDoS) attacks - attempts to overwhelm your site with so many requests that it goes offline. It applies rate limits, a cap on how many requests one visitor can make. It adds bot controls, which tell good automated visitors from bad ones. It also detects attack behavior and temporarily bans the source. You can enable or disable it per host and choose a protection level. For everything it does and every setting, see What is TurboShield? and Configure TurboShield.

Throttled visitors receive a soft `429` (Too Many Requests) response rather than being banned at the firewall, so legitimate traffic recovers automatically once it slows down. This matters for you because it means search engines and real customers are not locked out when traffic spikes. Bans, which only follow clear attack behavior, always expire on their own.

| Level | Behavior |
| --- | --- |
| `low` | Lenient rate limits; minimal bot controls. |
| `medium` | Balanced protection. This is the default. |
| `high` | Stricter rate limits and tighter bot controls. |
| `attack` | Most aggressive limits, intended for active attacks. |

To configure TurboShield:

1. Open the host's **Security** tab.
2. Enable **TurboShield**.
3. Select a protection level. The default is `medium`.
4. Save your changes.

> [!TIP]
> Start with `medium` and only raise the level if you observe abusive traffic. Switch to `attack` temporarily while an attack is in progress, then return to your normal level.

For details on how TurboShield evaluates traffic, see the Security overview.


Security

IP allow-list

The IP allow-list (`firewall_whitelist`) lets you define trusted Internet Protocol (IP) addresses, and ranges of them, that bypass rate-limiting and blocking. An IP address is the network address of a device or office, such as `203.0.113.10`. A range is written in Classless Inter-Domain Routing (CIDR) notation, such as `203.0.113.0/24`, which means a block of addresses. This is useful for office networks, monitoring services, and integration partners that should never be throttled or blocked.

A trusted IP is also allowed through the host firewall, so it can reach ports that are otherwise closed to the public.

1. Open the host's **Security** tab.
2. Add each trusted IP address or CIDR range to the `firewall_whitelist`.
3. Save your changes.

> [!WARNING]
> Validate every source before adding it. Wide ranges grant unrestricted access and can expose your host to abuse. Add the narrowest range that meets your need.


Security

GeoIP filtering

GeoIP filtering lets you allow or block web traffic based on the visitor's country.

| Setting | Effect |
| --- | --- |
| `firewall_country_allow` | Allow traffic only from the listed countries. |
| `firewall_country_block` | Block traffic from the listed countries. |

> [!WARNING]
> Country-based filtering carries a high risk of false positives. Visitors using VPNs, mobile networks, or proxies may be misidentified by country. Test carefully before relying on GeoIP rules in production.


Security

Web Application Firewall

The Web Application Firewall (WAF) inspects each incoming web request against a managed set of rules and blocks ones that match known attack patterns. TurboStack uses Imunify for this, which also scans the files on the host for malware. It works at the application layer, which is layer 7 of the Open Systems Interconnection (OSI) network model, so it can inspect the content of a request. This is a deeper level than the network firewall, which filters traffic at the network layer (layer 3). Working at layer 7 lets the WAF stop application-level attacks from the OWASP Top 10. That is the Open Worldwide Application Security Project's industry list of the most common web application risks. The two most common patterns it stops are:

- **SQL injection** - an attacker tries to smuggle database commands through a form or URL to read or change your data.
- **Cross-site scripting (XSS)** - an attacker tries to inject malicious code into your pages so it runs in your visitors' browsers.

The WAF also applies virtual patches. A virtual patch closes a known, exploited vulnerability at the firewall before the application itself is patched. This means a newly disclosed leak can be blocked immediately, instead of waiting for an application update.

You do not write these rules yourself; TurboStack maintains them. You choose whether the WAF is on and where it sends alerts.

1. Open the host's **Security** tab.
2. Enable the **Web Application Firewall**.
3. Enter a **notification email** address. TurboStack sends WAF security alerts, such as malware detections, to this address.
4. Save your changes.

> [!TIP]
> Keep the WAF enabled. If a rule ever blocks a legitimate request in your application (a false positive), contact support to adjust it rather than turning the whole WAF off.


Security

Automatically managed protections

The Firewall is managed automatically by TurboStack and does not require manual configuration. See the Security overview for how they fit into the overall protection model.


Security

Related

- Security overview
- Groups
- Advanced settings
- Threat Center
- SSH access


Services

services web server nginx Apache MySQL PostgreSQL Redis Elasticsearch OpenSearch databases client only separate database server Kibana OpenSearch Dashboards SQL Server edition

# Services

The host's **Services** tab is where you choose the server-level services: the web server, the
databases, the caching layers, and the search engine. Enable a service and pick its version; the
left-hand menu lists each service.

This tab covers:

- Web server - Nginx or Apache
- Databases - MySQL, PostgreSQL, MongoDB, and SQL Server
- Caching and queues - Redis, Varnish, and RabbitMQ
- Search - Elasticsearch and OpenSearch

> [!TIP]
> Memory sizing (database buffers, cache size, search heap) is auto-tuned to the server. Only
> override it with measured evidence. Changing a service's **major version** can be disruptive -
> plan and test it.


Services

Web server

Each host runs one web server, selected with `webserver`:

| Value | Description |
|---|---|
| `nginx` | High-performance web server and reverse proxy. Recommended for most workloads. |
| `apache2` | Widely compatible; useful when an app needs `.htaccess` or Apache modules. |

> [!NOTE]
> PHP and other language runtimes are chosen **per application** on the Applications
> tab (a host can serve several PHP versions side by side).


Services

Databases

Enable and pick a version for each database you need:

| Service | Setting | Notes |
|---|---|---|
| MySQL (Percona) | `mysql_version` | e.g. 8.0-8.4. Buffer pool auto-sized (`mysql_innodb_size`). |
| PostgreSQL | `postgresql_version` | e.g. 16-18. Shared buffers auto-sized (`postgresql_shared_buffers`). |
| MongoDB (Percona) | enable + version | e.g. 7.0-8.0. |
| Microsoft SQL Server | enable + version | When required. |

> [!IMPORTANT]
> Network bind addresses (`mysql_bindaddress`, `postgresql_listen_addresses`, `mongodb_bindip`) are
> security-sensitive - keep them restricted to trusted networks. All three accept the keyword
> **`ANY`**, which listens on *every* interface the server has, including any public one. Prefer a
> specific private address, and restrict access with the firewall.

> [!WARNING]
> On a host that also runs **Kubernetes or Docker**, the databases listen on every interface unless
> you set the bind address yourself - the containers have to be able to reach them. MongoDB does
> this even when its bind address is set to `127.0.0.1`. Set the address explicitly on such a host
> if you need it narrower, and make sure the firewall is closed.

You can administer MySQL through **phpMyAdmin**, and enable **Advanced Database Monitoring**
(under the host's **Advanced** tab) for deep database monitoring - see Monitoring (concepts).


Services

Client-only mode

MySQL and PostgreSQL each have a **Client only** toggle. Turn it on when the database does not run
on this host but on another server. TurboStack then installs only the database client tools, and the
server settings (bind address, buffer sizes, extensions, extra access) disappear from the form.

Two fields replace them:

| Field | What to enter |
|---|---|
| **Client Host Name** | The host name of the server that runs the database (`mysql_client_host_name` / `postgresql_client_host_name`). |
| **Client Host IP** | The address of that same server (`mysql_client_host_ip` / `postgresql_client_host_ip`). |

This is the application-server half of a split setup: this host runs the web server and the
application, and a separate host runs the database engine. It keeps database load off the
application server, and lets several application servers share one database.

```yaml
# Application server: no local database engine, connect to db1 instead
mysql_version: "8.4"
mysql_server: false            # what the "Client only" toggle sets for MySQL
mysql_client_host_name: db1.example.com
mysql_client_host_ip: 10.0.0.5

# PostgreSQL uses its own key for the same thing
# postgresql_client_only: true
# postgresql_client_host_name: db1.example.com
# postgresql_client_host_ip: 10.0.0.5
```

> [!IMPORTANT]
> The database server must accept connections from this host. On the database server, open the
> bind address or listen addresses to the private network and grant the user access. Never open a
> database to the public internet.

The database server itself is a second host configuration - see
Application server plus a separate database server.


Services

Microsoft SQL Server edition

When you enable Microsoft SQL Server you also pick an **edition** (`mssql_edition`): `Developer`,
`Enterprise`, `Express`, `Standard` or `Web`. If you do not choose one, `Express` is installed.
The editions differ in features, in the limits they impose, and in licensing, so check what your
license allows before you pick one.


Services

Caching and queues

| Service | Notes |
|---|---|
| **Redis** | Enabled by default. Two instances by convention: port `6379` = **cache** (transient, safe to clear) and `6378` = **persistent** (durable sessions/critical state). |
| **Varnish** | HTTP reverse-proxy cache, enabled per application (`varnish_enabled`); size auto-tuned. Advanced users can supply custom VCL (expert feature - easy to break). |
| **RabbitMQ** | AMQP message broker for background/async job queues. |

> [!TIP]
> Use Redis `6379` for transient cache and `6378` for durable sessions and queues - never store
> data you cannot lose on the cache instance.


Services

Search

Enable **Elasticsearch** or **OpenSearch** and pick a version (Elasticsearch 8.x-9.x, OpenSearch
2.x-3.x). The JVM heap is auto-sized; plugins are configurable. OpenSearch supports nightly snapshots
of your indices.

Both engines offer the same three extras once you pick a type and a version:

| Setting | Description |
|---|---|
| **Install Kibana** / **Install OpenSearch Dashboards** | Installs the engine's web interface, so you can inspect indexes and run queries in a browser (`elasticsearch_kibana`, `opensearch_dashboards`). Off by default. |
| **Plugins** | A multi-select of extra engine plugins, for example language-specific analysis for better search results (`elasticsearch_plugins`, `opensearch_plugins`). |
| **Heap size** | The memory the engine may use. It is auto-scaled to the server by default; turn the toggle on to enter your own size and unit (`elasticsearch_heap_size`, `opensearch_heap_size`). |

```yaml
opensearch_version: "3.x"
opensearch_dashboards: true
opensearch_plugins: [analysis-icu]
```


Services

Reaching the web interface

Once installed, the interface is served by the host's own web server on a fixed path:

| Interface | Address |
|---|---|
| Kibana (Elasticsearch) | `https://<host>/kibana` |
| OpenSearch Dashboards | `https://<host>/dashboards` |

The web server asks for a user name and password before it lets you through, and it accepts the
host's **system user accounts** - the same credentials you use for SSH. The interface itself is
never exposed directly; the web server reaches it over localhost.

> [!NOTE]
> That login is the web server's, not the search engine's. OpenSearch Dashboards has no user
> accounts of its own unless you turn user management on, which is only available in the
> Source (YAML) view (`opensearch_dashboards_usermanagement`).
> Turn it on when you need per-user access inside the dashboards rather than one shared door.


Services

Related

- Applications - per-application PHP, runtimes and proxying.
- Advanced settings and Backups & restore.
- Configuration recipes - including a separate database server.
- Hosts


SSH access

ssh ssh keys ssh access key authentication host ssh

# SSH access

The host's **SSH** tab controls how you and your team connect to a host over SSH. From here you manage the public keys allowed to log in, the port SSH listens on, and whether password-based login is permitted.

> [!NOTE]
> SSH settings are hidden for Windows hosts.

This tab covers:

- SSH keys - manage the public keys allowed to log in
- SSH port - change the port SSH listens on
- Password authentication - allow or disable password-based login


SSH access

SSH keys

The `ssh_keys` list defines the public SSH keys allowed to access the server. Add, edit, or delete keys as your team changes.

Each key supports an optional name or label to help you identify its owner or purpose. Both `ed25519` and RSA (Rivest-Shamir-Adleman) keys are supported. For a step-by-step walkthrough of generating a keypair, see Add an SSH key.

To add a key:

1. Open the **SSH** tab for the host.
2. Select **Add SSH key**.
3. Paste the public key.
4. Optionally enter a name or label for the key.
5. Save your changes.


SSH access

Inherited group keys

SSH keys can also be defined at the **group** level. When a host belongs to a group, it inherits the group's SSH keys in addition to any keys defined directly on the host. This lets you grant a set of keys access across many hosts at once. See Groups for how inheritance works.


SSH access

SSH port

The `ssh_port` setting controls which port the SSH service listens on. Changing it from the default can reduce noise from automated scans.

> [!WARNING]
> If you change `ssh_port`, make sure your firewall rules allow the new port, otherwise you may lock yourself out. See Security to review firewall settings.


SSH access

Password authentication

The `ssh_passwords` toggle controls whether password-based SSH login is allowed. When disabled, users can connect only with an SSH key.

> [!TIP]
> Use key-based authentication and disable password authentication. Keys are far harder to guess or brute-force than passwords, so turning off password login significantly improves the security of your host.

Before disabling password authentication, confirm that every user who needs access has a working SSH key configured so that no one is locked out.


SSH access

Related

- TurboStack CLI - the `tscli` tool you run once connected over SSH
- Security
- Groups
- Applications
- Hosts overview


Threat Center

threat center TurboRadar vulnerabilities CVE CVSS EPSS KEV risk score malware IoC security scan runtime detections

# Threat Center

The **Threat Center** tab is the security inbox for a single host. It shows what TurboStack's
security scanning (TurboRadar) found on that server: known weaknesses in your software, confirmed
malware, and suspicious activity caught while the server is running.

You do not need to be a security specialist to use it. This page explains each finding type, what
the scores mean, and - most importantly - how to decide what to fix first and what to do about it.

> [!IMPORTANT]
> **Not every vulnerability is equally important - and most are not urgent.** A long list of CVEs is
> normal; what matters is the handful that are both severe and likely to be attacked. Focus on
> findings that combine a high CVSS (severe impact) with a high EPSS (likely to be exploited), plus
> anything carrying an **Exploited (KEV)** or **Likely exploited** badge. The list
> is already sorted by risk score, so these sit at the top - work down from there and do not get
> distracted by the low-risk, low-EPSS findings near the bottom. See
> How to decide what to fix first.

This tab covers:

- How scanning works - where the findings come from
- Reading the security scores - CVE, CVSS, EPSS, KEV and risk score
- How to decide what to fix first - a simple priority guide
- Vulnerabilities - known weaknesses in your software
- Indicators of compromise - confirmed malware
- Runtime detections - suspicious activity caught live
- Status and actions - heartbeat, rescan, export and clear


Threat Center

How scanning works

TurboRadar is TurboStack's security scanning. It runs on the host and reports its findings back to
the platform, where they appear in this tab. It looks at three different things:

- **Your software and its dependencies** - to find publicly known weaknesses (see
  Vulnerabilities).
- **Your files** - to find malware such as web shells, backdoors and payment-page skimmers (see
  Indicators of compromise).
- **The running system** - to catch suspicious behavior as it happens (see
  Runtime detections).

Scans run **automatically on a weekly schedule**. You can also start one yourself at any time with
**Rescan now** - do this after you apply a fix, to confirm the finding is gone. The
status header shows when the last scan ran and whether the host is currently
reporting.


Threat Center

Reading the security scores

A vulnerability finding can carry several scores. They answer different questions, and reading them
together is what tells you how urgent a finding really is. Here is what each one means in plain
language.


Threat Center

CVE - the identity of the weakness

A **Common Vulnerabilities and Exposures (CVE)** identifier is a public, unique name for one
specific security weakness in a piece of software, written as `CVE-2024-12345`. Anyone in the world
refers to that exact weakness by that ID, and the full description lives in a public database (the
National Vulnerability Database). In the Threat Center, the CVE links to that advisory.

A CVE is only an **identifier** - it says *which* weakness was found, not how dangerous or likely it
is. For that, read the scores below.

> [!NOTE]
> Some findings have no CVE (for example a malware signature). Those show a signature name instead of
> a CVE.


Threat Center

CVSS - how severe it is

The **Common Vulnerability Scoring System (CVSS)** is a severity score from **0.0 to 10.0**. It
rates how much damage the weakness could cause *if* an attacker exploits it - the technical impact.
Higher is worse.

| CVSS score | Severity | Plain meaning |
| --- | --- | --- |
| 9.0 - 10.0 | Critical | Could fully compromise the server or data. |
| 7.0 - 8.9 | High | Serious impact if exploited. |
| 4.0 - 6.9 | Medium | Limited or harder-to-reach impact. |
| 0.1 - 3.9 | Low | Minor impact. |

CVSS describes the worst case, not the chance it will happen. A weakness can score 9.8 and still
almost never be attacked in practice. That is why you also need EPSS and KEV.


Threat Center

EPSS - how likely it is to be attacked

The **Exploit Prediction Scoring System (EPSS)** is a percentage from **0% to 100%**. It estimates
the probability that this weakness will be **exploited by attackers in the next 30 days**, based on
real-world data. Higher means more likely.

- A high EPSS (for example 80% or more) means attackers are actively targeting this weakness right
  now, or are very likely to soon.
- A low EPSS means that, although the weakness exists, it is rarely attacked in practice.

When a finding is not yet confirmed as actively exploited but its EPSS is **80% or higher**, the
Threat Center shows a **Likely exploited** badge so you can spot it quickly.

> [!TIP]
> CVSS and EPSS answer different questions. CVSS = "how bad if it happens". EPSS = "how likely it is
> to happen". A weakness that is both severe (high CVSS) and likely (high EPSS) is the most urgent.


Threat Center

KEV - confirmed to be exploited right now

**Known Exploited Vulnerabilities (KEV)** is a public catalogue, maintained by the United States
cybersecurity agency (CISA), of weaknesses that are **confirmed to be under active attack in the real
world**. This is the strongest possible signal: it is no longer a prediction.

A finding on this list shows an **Exploited (KEV)** badge. Treat these as urgent regardless of their
other scores.


Threat Center

Risk score - the single number that ranks everything

Reading three scores for every finding is a lot of work. To save you that, TurboStack combines the
signals above - whether it is exploited (KEV), how likely it is (EPSS), and how severe it is (CVSS) -
into a single **risk score**, shown as a large number on the right of each finding. Higher means more
urgent.

The vulnerabilities list is **sorted by risk score**, most urgent first, so the findings that need
your attention are always at the top. The coloured **severity** label (Critical, High, Medium, Low,
Info) is the priority band that the risk assessment puts the finding in; use the severity filter to
focus on a band.


Threat Center

How to decide what to fix first

You rarely need to read every score. For each finding near the top of the list, ask three questions
in order, and act on the first one that applies.

| Look for | What it tells you | What to do |
| --- | --- | --- |
| **Exploited (KEV)** badge | Attackers are using this weakness right now. | Fix immediately. This is the top priority. |
| **Likely exploited** badge, or EPSS 80%+ | A real attack is likely very soon. | Fix within days. |
| **Critical / High** severity with a high risk score | Severe, and ranked near the top. | Schedule a fix promptly. |
| **Medium / Low**, low EPSS, no badges | The weakness exists but is unlikely to be attacked. | Fix during your normal maintenance. |

> [!TIP]
> The short version: work from the top of the list down. The list is already ordered by risk, so the
> first findings you see are the ones that matter most.


Threat Center

Fixing a vulnerability

Most vulnerabilities are fixed by **updating the affected software to a version that is no longer
vulnerable**. Each finding shows the **package** and its **installed version**, and - when a fix
exists - the **Fixed in** version (in green).

1. Note the **package** and the **Fixed in** version.
2. Update that package to the **Fixed in** version (or newer). How you do this depends on the
   component - for example through your application's dependency manager, or by updating the platform,
   theme or extension that includes it.
3. Publish the change if it is part of your host configuration.
4. Run **Rescan now** to confirm the finding is gone.

If there is **no fix available yet**, reduce your exposure in the meantime: keep the
Web Application Firewall and
TurboShield enabled, and restrict access to the affected area where you
can. Re-check after the next scan.

> [!NOTE]
> You can **dismiss** a finding you have reviewed and decided is not relevant to you (for example a
> weakness in a feature you do not use). Dismiss it from its dismiss action. Dismissing only hides
> it - it does not fix anything.


Threat Center

Understanding false positives (backported patches)

Some findings - often around system packages such as OpenSSH - are **false positives**. Linux
distributions like Debian fix security issues by **backporting** the patch into the existing version
without changing the version number. A scanner that only compares version numbers to a CVE database
then flags a package (for example `OpenSSH_8.0p1`) as vulnerable even though the specific CVE is
already fixed.

TurboStack applies security updates automatically (once a day), so these packages
are kept patched. To confirm a specific case over SSH:

```bash
dpkg -l | grep openssh     # the installed package (and its patched build)
ssh -V                     # the running OpenSSH version
```

You can then check whether the CVE is already patched in the distribution's security tracker. If it
is, dismiss the finding; if you are unsure, contact support.


Threat Center

Vulnerabilities

Known weaknesses found in your software and its dependencies. Filter by severity (Critical, High,
Medium, Low, Info). Each finding shows:

- The title and the **CVE** identifier, linked to the public advisory (or a signature name when
  there is no CVE).
- The affected **package** or application type, and the **installed version**.
- The **Fixed in** version, when a fix is available.
- The scores and badges described above: **CVSS**, **EPSS**, **Exploited (KEV)** or **Likely
  exploited**, and the combined **risk score**.
- When it was first and last detected, and which scanner found it.

See How to decide what to fix first for how to act on these.


Threat Center

Indicators of compromise

An **Indicator of Compromise (IoC)** is evidence that your host has already been breached - most
often a malicious file found on disk, such as a web shell, a backdoor, or a skimmer that steals
payment details. These are not predictions: the malicious file is present. Every IoC is treated as
**Critical**, and a red banner appears when any are found.

Each entry shows the detection, the affected application type, the scanner, and the **file path** of
the suspicious file.

> [!WARNING]
> A confirmed malware finding needs immediate action. Suggested steps:
> 1. Treat the site as compromised. Do not assume it is harmless.
> 2. Remove the malicious file, or restore the site from a known-clean
>    backup taken before the infection.
> 3. Change passwords and keys that the host can reach (database, application admin, API tokens).
> 4. Find and close the entry point - usually an out-of-date application or a vulnerable extension
>    (see Vulnerabilities).
> 5. Contact support if you need help with cleanup or investigation.

After cleaning up, run **Rescan now** to confirm the file is gone.


Threat Center

Runtime detections

Runtime detections are suspicious actions caught **while the server is running**, rather than found
by scanning files. Examples are a web process starting a command shell, or a program running from a
temporary folder - patterns that often indicate an intrusion in progress.

Each detection shows a severity (for example CRITICAL or WARNING), the rule that matched, the source
or container it came from, a timestamp, and the command or file path involved.

Unlike vulnerabilities, these are a live stream of events and can include occasional false alarms
(for example a maintenance script doing something unusual). Review each one:

- If you recognise it (for example it matches a deploy or a task you ran), it is expected.
- If it is unexpected, treat it like a possible compromise and follow the steps under
  Indicators of compromise.


Threat Center

Status and actions

The header shows the host's reporting status and the controls for the tab.

- **TurboStack Heartbeat** - whether the host is currently sending data. A fresh heartbeat (within a
  few minutes) confirms the scanning is connected. "No signal yet" means the host has not reported
  recently; if it persists, contact support.
- **Last scan** - when the most recent scan finished, or "never" if none has run yet.
- A findings summary: total vulnerabilities (with the Critical count), indicators of compromise, and
  runtime events.

Available actions:

- **Rescan now** - start a fresh scan immediately. Progress is shown as each scanner finishes. Use
  this after applying a fix to confirm the finding is resolved.
- **Export** - download the current list as a CSV (comma-separated values) file, for example to share
  with a developer or track in a spreadsheet.
- **Clear all** - clear the findings in the current list (asks for confirmation). You can also
  dismiss findings one at a time.

> [!TIP]
> For how these protections work across the whole platform, see the
> Security overview.


Threat Center

Related

- Security overview (how protection works)
- Security (configuration)
- Backups
- Glossary
- Hosts


TurboStack Platform

platform overview hosts groups templates monitoring

# TurboStack Platform

The TurboStack Platform is where you manage your hosting infrastructure. The sidebar gives you
access to its main areas, described below. If you manage many hosts - for example across several
clients - the Hosts, Groups and Templates areas let you operate them together rather than one by
one. You order servers, manage billing and open support tickets in the Customer Center.


TurboStack Platform

Ways to use it

You manage the TurboStack Platform in whichever way fits the task:

- **GUI** - the guided web interface this section describes.
- **Source (YAML)** - edit a host's configuration directly as YAML.
- **REST API** - read and manage the same objects from your own tooling.

The GUI, Source (YAML) and API all change the same *intended* configuration, which TurboStack then
deploys. In addition, the **TurboStack CLI (`tscli`)** runs on the server itself to
manage live services and run common admin tasks - restarting services, clearing caches, the
firewall, email checks and log searches.


TurboStack Platform

Areas

| Area | What you do there |
|---|---|
| Hosts | Manage your servers and their full configuration (Health, Applications, Services, Security, Backups, and more). |
| Groups | Apply shared settings (SSH keys, security) across many hosts at once. |
| Templates | Reuse pre-built configurations to set up new hosts quickly. |
| Search | Find hosts, groups and templates across the platform. |
| Monitoring | See alerts and health across all your hosts. |

Other entry points: **Support** (get help), **Platform updates**
(release notes), and your account settings under
Profile & preferences.


TurboStack Platform

Most of your work happens in Hosts

A **host** is one server and the configuration it should run. Opening a host gives you a
workspace organized into tabs - from live Health and
Threat Center to Applications,
Services, Security and
Backups - plus publishing changes to the server.
Start at Hosts.


TurboStack Platform

Next steps

- Hosts - manage your servers.
- Core concepts - the underlying model.
- Glossary - what the terms and abbreviations mean.


Monitoring

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

# Monitoring

The **Monitoring** area gives you a fleet-wide view of alerts across all your hosts, so you can
spot problems without opening each host individually. For teams running business-critical sites,
this helps you notice and react to problems quickly - for example during a busy campaign - before
they affect visitors.