Troubleshooting nopCommerce

Where to find the logs

nopCommerce is a managed systemd **user** service, so its console output goes to the journal rather than a flat file. Combine the journal with Nginx logs and the application's own logging.

| Component | Where |
| --- | --- |
| Application (.NET) | `journalctl --user -u application.service` (or `<app_name>-application.service`) - startup errors, crashes, stack traces |
| Service status | `systemctl --user status application.service` |
| Nginx access/error | The host's web server logs (Health tab, or under `/var/log/nginx/`) - proxy and 502 errors |
| nopCommerce log | **Admin > System > Log** (stored in SQL Server); plugin/runtime files under the app's `App_Data/Logs/` |
| Database connection | `App_Data/dataSettings.json` in the application directory (connection string, provider) |
| Environment | `conf/.env` in the app root (runtime environment variables) |

Also check the host's Health tab for CPU/memory/disk and service state, and recent deploys in History.

> [!TIP]
> Add `-f` to the journal command (`journalctl --user -u application.service -f`) to watch logs live while you reproduce a problem or restart the service.


Troubleshooting nopCommerce

Common issues

nopcommerce troubleshooting nopcommerce logs nopcommerce error nopcommerce turbostack nginx 502 dotnet service mssql connection datasettings.json

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Site down, Nginx returns 502 | The .NET application service is not running or not listening | `systemctl --user status application.service`; start/restart it and read the journal for the startup error |
| Service won't start, "framework not found" | `dotnet_version` does not match the build's target framework | Pin the correct `dotnet_version` and re-publish (Publishing) |
| "Cannot connect to database" / install screen reappears | Wrong or missing `App_Data/dataSettings.json`, SQL Server down, or bad credentials | Verify `dataSettings.json`, confirm the SQL Server service is reachable, and check the connection string |
| Plugins or theme changes don't appear | Plugins need to recompile and the app must reload | Restart the service so plugins compile against the runtime; clear the plugin cache if needed |
| Errors writing config/logs, install fails | `App_Data/` is not writable by the system user | Fix ownership/permissions on `App_Data/` so the system user can write |
| Scheduled tasks not running (emails stuck) | App not reachable or the task is disabled | Keep the service up; review and enable tasks in **Admin > System > Schedule Tasks** |
| Wrong scheme in links / HTTPS redirect loop | Forwarded headers not honored | The vhost forwards `X-Forwarded-Proto` and the service sets `ASPNETCORE_FORWARDEDHEADERS_ENABLED=true`; re-publish if the vhost was edited by hand |


Troubleshooting nopCommerce

A troubleshooting workflow

1. **Check Health** - confirm the host is up and the application service is running, and look for CPU/memory/disk pressure.
2. **Read the relevant log** - start with `journalctl --user -u application.service` for a 502 or a crash. Check the Nginx error log if the journal shows the app is healthy. Check **Admin > System > Log** for application-level errors.
3. **Check the last deploy in History** - if a recent change broke the store, revert and re-publish from Publishing.
4. **Verify services are running** - confirm the nopCommerce service is active (`systemctl --user status application.service`), Nginx is up, and SQL Server is reachable. Restart any service that is down.


Troubleshooting nopCommerce

Getting help

If you are still stuck, see the general platform troubleshooting guide or contact Support with the relevant journal and Nginx log excerpts.


Troubleshooting nopCommerce

Related

- Deploy nopCommerce
- nopCommerce best practices
- Health
- Support


How to install and upgrade Odoo add-ons

odoo addons odoo modules install odoo module upgrade odoo module odoo-bin custom addons staging server __manifest__.py

# How to install and upgrade Odoo add-ons


How to install and upgrade Odoo add-ons

Overview

Upgrade or install Odoo modules using command-line tools. TurboStack servers provide optimal system configurations, but managing Odoo itself remains your responsibility. For the file layout and service details, see Odoo reference.

> [!IMPORTANT]
> To safely test new modules or updates, use a separate staging server. Do not run staging environments locally on the same production host.
>
> Why separate servers?
>
> - Prevents production disruption.
> - Isolates tests and experiments.
> - Maintains better performance and security.
>
> TurboStack offers affordable and optimized staging environments. Contact support to request a staging clone of your production Odoo.


How to install and upgrade Odoo add-ons

Upgrade an add-on

```bash
systemctl --user stop application.service
~/application/odoo/odoo-bin -u <module_name> -c ~/conf/odoo.conf --stop-after-init
systemctl --user start application.service
```

Replace `<module_name>` with your actual add-on/module name.


How to install and upgrade Odoo add-ons

Install a new add-on

<!-- REVIEW: source says "Upload the module to ~/application/addons/". Corrected to ~/application/custom/ per awx-deploy (odoo.conf.j2 addons_path has a dedicated custom entry; there is no ~/application/addons/). -->

1. Upload the module to `~/application/custom/`.
2. Run:

```bash
systemctl --user stop application.service
~/application/odoo/odoo-bin -i <module_name> -c ~/conf/odoo.conf --stop-after-init
systemctl --user start application.service
```


How to install and upgrade Odoo add-ons

Notes

- Always stop the service before upgrades.
- Make sure your add-on contains a valid `__manifest__.py` file.
- Keep your structure modular by creating symbolic links inside `~/application/custom/` for large or custom add-on libraries, rather than copying whole trees in.
- Always keep your `.env` and `odoo.conf` safe and backed up before changing modules, so you can restore a known-good configuration if an upgrade goes wrong.


How to install and upgrade Odoo add-ons

Related

- Odoo reference
- How to install Python dependencies for Odoo
- Deploy Odoo on TurboStack
- Odoo best practices
- Troubleshooting Odoo
- How to manage user system services
- Connect over SSH


Odoo best practices

odoo performance odoo optimization odoo caching odoo turbostack odoo workers odoo postgresql odoo proxy_mode odoo filestore

# Odoo best practices

Odoo is a Python ERP that runs as its own long-lived service behind an Nginx reverse proxy. Getting good, stable performance is mostly about right-sizing the worker pool, keeping PostgreSQL healthy, and letting Nginx serve static and filestore content. This page covers what TurboStack already configures for you and the optimizations worth applying on top.


Odoo best practices

What TurboStack configures for you

When you set `app_type: odoo`, the platform provisions a complete, tuned Odoo stack:

- **A dedicated systemd service** that launches `odoo-bin` from your pyenv-managed Python and restarts automatically on failure (`Restart=on-failure`).
- **An Nginx reverse proxy** with `proxy_mode = True` set in Odoo, forwarding `X-Forwarded-*` and `X-Real-IP` headers so Odoo sees the correct client address and scheme.
- **Multiprocess workers**, auto-calculated from the server's CPUs, plus `max_cron_threads = 2` for scheduled jobs.
- **A separate websocket/longpolling endpoint** - Nginx routes `/websocket` (Odoo 16+) and `/longpolling` (Odoo 15 and earlier) to the gevent port (`8072` by default). Normal traffic goes to the main port (`8069`).
- **Per-worker resource limits**: `limit_memory_soft` (2 GB), `limit_memory_hard` (4 GB), `limit_time_cpu` (3600 s), `limit_time_real` (7200 s) and `limit_request` (8192).
- **Direct filestore delivery**: `x_sendfile = True` plus an Nginx `internal` `/web/filestore` location, so attachments are streamed by Nginx instead of through Python workers.
- **A PostgreSQL connection** with a dedicated role and database, plus a generated `admin_passwd` for the database manager.
- **A ready-made `odoo.conf.sample`** in your `conf/` directory with all of the above as a starting point.

> [!NOTE]
> An Odoo deployment uses PostgreSQL only. There is no PHP, no MySQL/MariaDB, and no Varnish layer.


Odoo best practices

Recommended optimizations

- **Tune the worker count to your workload.** The default scales with CPUs. Odoo's guideline is roughly `(2 x CPU) + 1` HTTP workers, or about one worker per 6 concurrent users - use the lower of the two. More workers serve more concurrent users but cost RAM - see Sizing and scaling.
- **Keep filestore on disk, not in the database.** The platform already serves it via Nginx; avoid storing attachments in PostgreSQL, which bloats the database and backups.
- **Run Odoo in production mode.** Do not enable `dev_mode` or `demo` data on a live site; the defaults already disable them (`without_demo = True`).
- **Pre-compile and cache assets.** Let Odoo bundle and minify JS/CSS (the default), and serve them through Nginx with long cache headers.
- **Right-size cron threads.** Heavy scheduled actions (mailings, accounting, inventory valuation) run under `max_cron_threads`; keep them modest so cron jobs do not starve HTTP workers.
- **Tighten timeouts for long operations.** Imports and reports may need higher `limit_time_real`/`limit_time_cpu`; raise them deliberately rather than disabling them.
- **Front it with HTTP caching/Content Delivery Network (CDN) where safe.** Static assets and public application pages cache well; never cache authenticated `/web` session traffic.
- **Install Python dependencies in the virtual environment.** Use the project's pip, never system-wide: `pip install -r odoo/requirements.txt` for core, and `pip install -r custom-addons/<addon>/requirements.txt` per add-on.
- **Leave `db_maxconn` at its default (64).** The platform's PostgreSQL is tuned for high concurrency; raising it rarely helps and can exhaust connections.

Manage the Odoo and PostgreSQL services from the host Services tab.


Odoo best practices

Sizing and scaling

The worker pool and memory limits are auto-tuned from the server's resources, and PostgreSQL is sized by the platform. Override defaults only with measured evidence:

| Variable | Tune when |
| --- | --- |
| `workers` | CPUs are consistently busy and requests queue - but ensure RAM covers `workers × limit_memory_soft`. |
| `limit_memory_soft` / `limit_memory_hard` | Workers are recycled too aggressively under legitimate load. |
| PostgreSQL memory and connections | The database becomes the bottleneck rather than the app. |

> [!TIP]
> Each Odoo worker can consume up to ~2-4 GB. Add workers only if free memory comfortably absorbs the extra processes, or you risk swapping and Out Of Memory (OOM) kills.

See Performance tuning for the general approach to changing auto-tuned values.


Odoo best practices

Stability

- **Back up regularly.** Ensure both PostgreSQL and the filestore are covered - see Backups. A database backup without the matching filestore loses attachments.
- **Watch the Health tab** for CPU, memory, and service status; rising memory or worker restarts are early warnings.
- **Keep Odoo and modules current.** Apply security and point releases, and review third-party modules before upgrading major versions.
- **Test on a staging clone.** Validate module installs/upgrades (`-u`) and configuration changes on a copy before touching production.


Odoo best practices

Related

- Deploy Odoo on TurboStack
- Odoo reference
- Troubleshooting Odoo
- Services
- Performance tuning


Deploy Odoo on TurboStack

odoo python erp postgresql nginx reverse proxy app_type odoo business apps turbostack letsencrypt

# Deploy Odoo on TurboStack

Odoo is a Python-based suite of open-source business applications covering enterprise resource planning (ERP), customer relationship management (CRM), accounting, inventory and e-commerce. TurboStack runs Odoo as its own service and places an Nginx reverse proxy in front of it, so you only have to declare the application in your host YAML.


Deploy Odoo on TurboStack

Requirements

| Component | Value |
| --- | --- |
| App type | `odoo` |
| Runtime | Python 3 (managed for you, no version key needed) |
| Database | PostgreSQL |
| Web server | Nginx (reverse proxy) |

> [!NOTE]
> Odoo requires PostgreSQL. There is no PHP and no Varnish in an Odoo deployment.


Deploy Odoo on TurboStack

Configure it

1. Set `webserver: nginx` at the host level so TurboStack provisions the reverse proxy.
2. Set `postgresql_version` to the PostgreSQL release Odoo should use (for example `"17"`).
3. Add a system user, then define a vhost with `app_type: odoo`. TurboStack starts the Odoo service and proxies traffic to it.
4. Request a certificate with `cert_type: letsencrypt` for automatic HTTPS.
5. (Optional) Override the Odoo ports under an `odoo:` block only if you do not use the defaults.

See Applications for the full list of supported app types and Publish for how to apply your host configuration.


Deploy Odoo on TurboStack

Example configuration

```yaml
webserver: nginx
postgresql_version: "17"      # Odoo requires PostgreSQL
system_users:
  - username: prod
    vhosts:
      - server_name: odoo.example.com
        app_type: odoo          # TurboStack runs Odoo behind nginx for you
        cert_type: letsencrypt
        # Optional - only if you run Odoo on non-default ports:
        # odoo:
        #   main_port: 8069
        #   websocket_port: 8072
```


Deploy Odoo on TurboStack

Why these choices

- `app_type: odoo` tells TurboStack to run the Odoo service and configure the Nginx reverse proxy for it automatically.
- `postgresql_version` is mandatory because Odoo stores all of its data in PostgreSQL.
- `webserver: nginx` provides the reverse proxy layer that fronts the Odoo process.
- `cert_type: letsencrypt` issues and renews Transport Layer Security (TLS) certificates without manual steps.
- The `odoo.main_port` (default 8069) and `odoo.websocket_port` (default 8072) settings are advanced overrides; leave them out unless you have a specific reason to change the ports.


Deploy Odoo on TurboStack

Related

- Technologies used: Python, PostgreSQL, Reverse proxy.

- Best practices - performance & stability.
- Troubleshooting - logs & common fixes.
- Applications overview
- Services
- Applications
- The Source (YAML) view


odoo python dependencies pip install requirements.txt odoo custom module dependencies pyenv odoo pip odoo core requirements

# How to install Python dependencies for Odoo

Install dependencies required by Odoo and your custom modules using `pip`. On TurboStack, Python is platform-managed through pyenv, and the `pip` on your `PATH` installs into the environment that runs Odoo. There is no virtual environment to create or activate by hand. For the file layout and service details, see Odoo reference.


Odoo core requirements

```bash
cd ~/application
pip install -r odoo/requirements.txt
```


Custom modules

<!-- REVIEW: source says "pip install -r custom-addons/*/requirements.txt". Corrected to per-module install under ~/application/custom/ (grounded addons_path custom entry); the source glob is also invalid because pip -r accepts a single requirements file. -->

If your custom modules include their own `requirements.txt`, install it:

```bash
pip install -r ~/application/custom/<module_name>/requirements.txt
```

Replace `<module_name>` with the module's directory name. Repeat for each module that has its own `requirements.txt`.


Apply the changes

Restart Odoo so it loads the newly installed packages:

```bash
systemctl --user restart application.service
```


Best practices

<!-- REVIEW: source says "Use the correct pip from your virtual environment." Corrected: TurboStack has no virtualenv to activate - Python is pyenv-managed and pip is the pyenv shim (~/.pyenv/shims/pip). -->

- Use the `pip` that is already on your `PATH` (the pyenv-managed pip).
- Avoid installing system-wide.


Related

- How to install and upgrade Odoo add-ons
- Odoo reference
- Deploy Odoo on TurboStack
- Odoo best practices
- Troubleshooting Odoo
- How to manage user system services
- Connect over SSH


Odoo reference

odoo reference odoo.conf odoo file layout odoo systemd service odoo ports odoo workers odoo configuration keys

# Odoo reference

Reference for running Odoo on TurboStack: where the files live, how the service runs, the default ports, and the `odoo.conf` configuration keys. For setup see Deploy Odoo on TurboStack; for tuning see Odoo best practices.


Odoo reference

File layout

Everything lives under your system user's home directory. `~` is that home directory (for example `/var/www/prod/`).

| Path | What it is |
| --- | --- |
| `~/application/odoo/` | Odoo source code and working directory |
| `~/application/odoo/addons/` | Custom modules (add-ons) |
| `~/conf/odoo.conf` | Main configuration file |
| `~/conf/.env` | Environment variables |
| `~/logs/odoo.log` | Application log |

For ownership and permissions, see Application file layout and permissions.


Odoo reference

The Odoo service

Odoo runs as a systemd user service, so it needs no root access. The unit lives at `~/.config/systemd/user/application.service`. It starts `odoo-bin` from your pyenv-managed Python and loads its environment from `~/conf/.env`:

```ini
[Unit]
Description=Odoo application (main) for %u
Wants=network-online.target
After=network-online.target
Requires=dbus.socket
StartLimitIntervalSec=0

[Service]
LimitNOFILE=819200
LimitNPROC=819200
LimitMEMLOCK=infinity

TimeoutStartSec=900
Type=simple
WorkingDirectory=%h/application/odoo
EnvironmentFile=%h/conf/.env

ExecStart=%h/.pyenv/shims/python %h/application/odoo/odoo-bin -c %h/conf/odoo.conf
ExecStop=/bin/kill -s TERM $MAINPID
Restart=on-failure
RestartSec=10s
KillSignal=SIGQUIT
StandardOutput=append:%h/logs/odoo.log

[Install]
WantedBy=default.target
```

The high file-descriptor and process limits (`LimitNOFILE`, `LimitNPROC`, `LimitMEMLOCK`) keep Odoo from hitting kernel resource caps under load. `TimeoutStartSec=900` gives module upgrades enough time to finish before systemd considers the start failed. The service restarts on failure after 10 seconds and appends its output to `~/logs/odoo.log`. Manage it with `systemctl --user` - see How to manage user system services.


Odoo reference

Default ports

TurboStack fronts Odoo with an Nginx reverse proxy and sets these ports for you. They are advanced overrides; leave them at the defaults unless you have a specific reason to change them.

| Key | Default | What it is |
| --- | --- | --- |
| `odoo.main_port` | `8069` | Main Hypertext Transfer Protocol (HTTP) port |
| `odoo.websocket_port` | `8072` | Websocket / longpolling port |


Odoo reference

Configuration keys

The `workers` count is derived from the server's vCPUs; the other limits are fixed platform defaults. This table is a scannable reference; for when and how to change each value, see Odoo best practices.

| Key | Typical value | What it controls |
| --- | --- | --- |
| `workers` | About 3x the vCPU count | Number of Hypertext Transfer Protocol (HTTP) worker processes |
| `max_cron_threads` | `2` | Threads reserved for scheduled (cron) jobs |
| `limit_memory_soft` | Per-worker soft cap | Memory at which a worker is recycled after the current request |
| `limit_memory_hard` | Per-worker hard cap | Memory at which a worker is killed immediately |
| `limit_request` | `8192` | Requests a worker serves before it is recycled |
| `limit_time_cpu` | `3600` | Central Processing Unit (CPU) seconds allowed per request |
| `limit_time_real` | `7200` | Wall-clock seconds allowed per request |
| `limit_time_real_cron` | `86400` | Wall-clock seconds per cron job (24 hours) |
| `db_maxconn` | `64` | Maximum PostgreSQL connections per worker |
| `proxy_mode` | `True` | Required behind the Nginx reverse proxy so Odoo trusts forwarded headers |


Odoo reference

Sizing heuristics

When you do tune `odoo.conf` by hand, size the limits from the server's resources:

- `limit_memory_hard` - about half of total RAM.
- `limit_memory_soft` - about a quarter of total RAM.
- `max_cron_threads` - about one third of the CPU cores (up to half in large setups).
- `limit_time_real_cron` - `0` means unlimited; set it to `86400` (24 hours) to cap long cron jobs.


Odoo reference

Tuning by server size

Copy-pasteable starting points for two common server sizes. Adjust from the heuristics above and measure before changing further.

8 GB RAM / 4 CPU cores:

```ini
workers = 8
limit_memory_hard = 4294967296        ; 4 GB
limit_memory_soft = 2147483648        ; 2 GB
limit_request = 8192
limit_time_cpu = 3600
limit_time_real = 7200
limit_time_real_cron = 0
max_cron_threads = 2
proxy_mode = True
```

48 GB RAM / 12 CPU cores:

```ini
workers = 36
limit_memory_hard = 6442450944        ; 6 GB
limit_memory_soft = 4294967296        ; 4 GB
limit_request = 8192
limit_time_cpu = 3600
limit_time_real = 7200
limit_time_real_cron = 0
max_cron_threads = 4
proxy_mode = True
```


Odoo reference

Related

- Deploy Odoo on TurboStack
- Odoo best practices
- Troubleshooting Odoo
- Application file layout and permissions
- How to manage user system services


Troubleshooting Odoo

odoo troubleshooting odoo logs odoo error odoo turbostack odoo service not starting odoo postgresql odoo websocket odoo workers

# Troubleshooting Odoo

When Odoo is not working correctly, the cause is almost always in one of three places. These are the Odoo service itself, the Nginx reverse proxy in front of it, or the PostgreSQL database behind it. This page shows where the logs live and how to work through the most common issues.


Troubleshooting Odoo

Where to find the logs

Paths below use `<user>` for the system user and `[app/]` for the optional `app_name` subfolder (omit it for a single Odoo on the account).

| Component | Where |
| --- | --- |
| Odoo application log | `/var/www/<user>/[app/]logs/odoo.log` |
| Odoo service (systemd) | `journalctl --user -u [app-]application.service` |
| Odoo config in use | `/var/www/<user>/[app/]conf/odoo.conf` |
| Nginx access/error | `/var/log/nginx/` (host-level access and error logs) |
| PostgreSQL | system PostgreSQL log (e.g. `/var/log/postgresql/`) |

> [!NOTE]
> The Odoo service is a **systemd user service**, so use `systemctl --user` and `journalctl --user`. Its stdout is appended to `logs/odoo.log`, which is the first file to check.

Also use the host Health tab for live CPU/memory/service status, and review recent deploys in History to see whether a change coincided with the problem.


Troubleshooting Odoo

Common issues

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Service won't start | No real `odoo.conf` (only the `.sample`), bad `addons_path`, or Python/env error | Copy `odoo.conf.sample` to `odoo.conf`, verify `addons_path` points to existing folders, then check `journalctl --user` and `logs/odoo.log` for the traceback. |
| "database connection failed" / role errors | PostgreSQL down, wrong `db_user`/`db_password`, or `db_host`/`db_port` mismatch | Confirm PostgreSQL is running on the Services tab; verify the role, database name (`<user>_db`) and port `5432` in `odoo.conf`. |
| 502 Bad Gateway from Nginx | Odoo process not listening on the main port (`8069`) | Check the service is running and started cleanly; confirm `xmlrpc_port`/`main_port` matches the Nginx upstream. |
| Live chat / notifications don't update | Websocket traffic not reaching the gevent port (`8072`) | Ensure the `odoo.websocket_port` and Nginx `/websocket` (or `/longpolling` on Odoo 15 and earlier) routing are consistent; restart the service. |
| Workers crash or restart under load | `limit_memory_soft`/`limit_memory_hard` exceeded, or too many workers for available RAM | Reduce `workers` or raise the memory limits with evidence; watch Health. See Best practices. |
| Module changes don't take effect | Module not installed/upgraded | Restart with `-u <module>` (or `-u all`) once, on a staging clone first, then remove the flag. |
| Attachments / images 404 | Filestore path or `x_sendfile` mismatch | Confirm `data_dir`/filestore folder exists and the Nginx `/web/filestore` location points to it. |


Troubleshooting Odoo

A troubleshooting workflow

1. **Check Health** for CPU, memory, and whether the Odoo and PostgreSQL services are up.
2. **Read the relevant log** - start with `logs/odoo.log` and `journalctl --user -u [app-]application.service`, then Nginx and PostgreSQL logs as needed.
3. **Check the last deploy in History.** If a recent change broke things, revert and re-apply via Publish.
4. **Verify services are running** from the host Services tab. Restart the Odoo service and PostgreSQL if needed.


Troubleshooting Odoo

Getting help

If you are still stuck, reach out via Support with the relevant log excerpts, and review the general Troubleshooting guide for platform-wide checks.


Troubleshooting Odoo

Related

- Deploy Odoo on TurboStack
- Odoo best practices
- Health
- Support


OroCommerce best practices

orocommerce performance orocommerce optimization orocommerce caching orocommerce turbostack oro message queue RabbitMQ consumers symfony opcache Redis

# OroCommerce best practices

OroCommerce is a Symfony-based B2B commerce platform that depends heavily on caching, a message queue, and search indexing to perform well. This page covers the practices that keep an OroCommerce storefront fast and stable on TurboStack. OroCommerce is configuration-only: you bring your own code with Git deployment, and TurboStack provisions the runtime and services around it.


OroCommerce best practices

What TurboStack configures for you

When you set a vhost to `app_type: orocommerce`, the platform provisions the OroCommerce runtime profile:

- An **Nginx vhost** tuned for OroCommerce, with the document root at `public_html` under your system user's home (`/var/www/<username>/[<app_name>/]public_html`).
- A **PHP-FPM backend** wired to Nginx, with a long `fastcgi_read_timeout` (1200s) so long-running install and admin requests do not time out, plus `fastcgi_intercept_errors` for clean error handling.
- **Static asset caching** at the web server: images, CSS, JS, PDF and similar files are served with a 1-hour browser cache and access logging disabled.
- The **MySQL/Percona** database service (PostgreSQL is also supported).
- Optional **Redis**, **RabbitMQ** (the message queue Oro relies on), and **Varnish**, enabled per host.

> [!NOTE]
> TurboStack provisions the infrastructure; OroCommerce's own application configuration (cache adapters, queue, search) lives in your code and `.env`/`config` and is deployed with your repository.


OroCommerce best practices

Recommended optimizations

Combine OroCommerce's own recommendations with the TurboStack services you enable on the Services tab:

- **Run the application in `prod` mode** and compile assets/DI container during deploy; never serve `index_dev.php` in production.
- **Enable OPcache** for PHP and keep it warm; it is the single biggest PHP performance win for Symfony.
- **Use Redis** for the Symfony cache, doctrine result cache, and sessions to offload the database.
- **Run RabbitMQ message-queue consumers** as persistent workers - Oro offloads emails, search indexing, price recalculation and imports to the queue. Without running consumers these jobs stall. Run each consumer as a user system service so it restarts on failure. Add more consumers in parallel to clear a backlog, but keep the total within the host's processor budget (see Scale throughput with more instances).
- **Keep the search index healthy**: run application search reindexing after catalog changes and on a schedule.
- **Put Varnish in front of Nginx** for full-page caching of anonymous catalog traffic on high-volume storefronts.
- **Optimize images and assets**: compress product images and enable an HTTP cache/Content Delivery Network (CDN) in front of static content.
- **Schedule Oro's cron** (`oro:cron`) so recurring maintenance, cleanup and queued tasks run reliably.

> [!TIP]
> Message-queue consumers and the Oro cron are the two things most often forgotten. If emails, search updates or imports "do nothing," check these first.


OroCommerce best practices

Sizing and scaling

TurboStack auto-tunes service defaults from the host's resources. Override sizing variables only when you have measured evidence of a bottleneck:

| Variable | Tune when |
| --- | --- |
| `mysql_innodb_size` | The working set exceeds the buffer pool. |
| `redis_memory` | Redis is evicting keys under load. |
| `varnish_cache_size` | The full-page cache hit ratio is low. |

Scale message-queue consumers and PHP-FPM workers to match traffic before scaling the database. See Performance tuning.


OroCommerce best practices

Stability

- Keep **Backups** enabled and verify restores periodically - Oro holds catalog, order and customer data.
- Watch the host **Health** tab for CPU, memory, queue depth and service status.
- Keep OroCommerce, PHP and the database versions current within supported ranges.
- Test upgrades, schema migrations and config changes on a **staging clone** before publishing to production.

> [!WARNING]
> Database schema migrations and reindexing are heavy operations. Run them in a maintenance window and ensure consumers are running so queued post-migration jobs complete.


OroCommerce best practices

Related

- Deploy OroCommerce
- Troubleshooting OroCommerce
- How to manage user system services
- Services
- Performance tuning


Deploy OroCommerce on TurboStack

deploy orocommerce orocommerce hosting orocommerce turbostack symfony b2b commerce RabbitMQ message queue php 8.4 Redis Varnish

# Deploy OroCommerce on TurboStack

OroCommerce is a Symfony-based B2B commerce platform. TurboStack provisions the runtime and supporting services, including the message queue OroCommerce relies on for asynchronous processing.


Deploy OroCommerce on TurboStack

Requirements

| Requirement | Recommended |
| --- | --- |
| App type | `orocommerce` |
| Runtime | PHP 8.4 |
| Database | MySQL 8.4 (or PostgreSQL) |
| Cache | Redis |
| Message queue | RabbitMQ (recommended for async jobs) |
| Web server | Nginx (Varnish optional) |

> [!NOTE]
> OroCommerce is configuration-only: bring your own application code and deploy it with Git deployment.


Deploy OroCommerce on TurboStack

Configure it

1. Open your host and go to the Applications tab.
2. Select **Add app or database** and set **App Type** to `orocommerce`.
3. Choose PHP 8.4 as the runtime and set the server name for your storefront.
4. Enable MySQL, Redis, and RabbitMQ for the async message queue.
5. Publish the host, then deploy your code.


Deploy OroCommerce on TurboStack

Example configuration

```yaml
webserver: nginx
mysql_version: "8.4"
redis_enabled: true
system_users:
  - username: prod
    vhosts:
      - server_name: oro.example.com
        app_type: orocommerce
        php_version: "8.4"
        cert_type: letsencrypt
        rabbitmq_enabled: true   # Oro uses a message queue for async jobs
```

> [!TIP]
> Add Varnish in front of Nginx if you need full-page caching for high-traffic catalogs.


Deploy OroCommerce on TurboStack

Why these choices

- `app_type: orocommerce` applies the OroCommerce runtime profile to the vhost.
- RabbitMQ is strongly recommended because Oro offloads async jobs to a message queue.
- MySQL 8.4 stores commerce data; PostgreSQL is supported as an alternative.
- Redis provides caching and session storage for the Symfony application.
- PHP 8.4 and Nginx match OroCommerce's supported stack.
- Let's Encrypt provides automatic Transport Layer Security (TLS) for the storefront hostname.


Deploy OroCommerce on TurboStack

Related

- Technologies used: PHP, MySQL, Redis, RabbitMQ.

- Best practices - performance & stability.
- Troubleshooting - logs & common fixes.
- Applications overview
- Services
- Applications (host tab)
- The Source (YAML) view


Troubleshooting OroCommerce

orocommerce troubleshooting orocommerce logs orocommerce error orocommerce turbostack RabbitMQ consumers oro cache clear website search reindex

# Troubleshooting OroCommerce

Most OroCommerce problems involve a few key components: the message queue and its consumers, the Symfony cache, the search index, and the runtime/database configuration. This page shows where to look and how to resolve the most common issues on TurboStack.


Troubleshooting OroCommerce

Where to find the logs

OroCommerce runs under your system user, with the document root at `public_html` and the application code in the same vhost directory. Start with these:

| Component | Where |
| --- | --- |
| Nginx access/error | Host Nginx logs (see Health); the OroCommerce vhost serves from `/var/www/<username>/[<app_name>/]public_html` |
| PHP-FPM | The PHP-FPM pool log for the vhost's user |
| OroCommerce application | The app's own `var/logs/` directory (e.g. `prod.log`) under the application root |
| Message queue | RabbitMQ service status and consumer output (see Services) |
| Database | MySQL/Percona (or PostgreSQL) service logs |
| Platform | Host Health tab; recent deploys in History |

> [!TIP]
> Set OroCommerce to `prod` mode and watch `var/logs/prod.log` while you reproduce an issue - it usually names the failing service or class.


Troubleshooting OroCommerce

Common issues

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Emails, imports or price updates never happen | Message-queue consumers not running | Start/restart the RabbitMQ consumers (`oro:message-queue:consume`) and ensure they run as persistent workers; check RabbitMQ on Services |
| Storefront/admin shows stale data after a change | Symfony cache not cleared/warmed | Run `cache:clear` (and warmup) for `prod`; confirm Redis is up if used for cache |
| Search returns nothing or stale results | Website search index out of date | Run website search reindex (`oro:website-search:reindex`); ensure consumers process the indexing jobs |
| Real-time UI (notifications, sync) not updating | WebSocket server not running | Verify the Oro WebSocket (Gos) server process is running and reachable |
| 500 error or "service unavailable" after deploy | Schema migration not run, or bad `.env`/`database_url` | Check `var/logs/prod.log`; run pending migrations; verify `database_url`/Redis config and clear the cache |
| Requests time out on long admin/import actions | PHP and PHP-FPM limits | Nginx already allows a 1200s `fastcgi_read_timeout`; offload heavy work to the message queue instead of synchronous requests |
| Scheduled tasks not running | Oro cron not scheduled | Ensure `oro:cron` runs on a schedule; confirm consumers are alive to process queued cron jobs |


Troubleshooting OroCommerce

A troubleshooting workflow

1. Check Health - confirm CPU, memory and that Nginx, PHP-FPM, the database, Redis and RabbitMQ are running.
2. Read the relevant log - start with `var/logs/prod.log`, then the Nginx error log and PHP-FPM log for the vhost.
3. Check the last deploy in History - if a recent change broke the site, revert or re-Publish a known-good revision.
4. Verify services are running - on Services, confirm RabbitMQ and its consumers, Redis, and the WebSocket server are up. Restart any that are down and re-run cache clear/reindex if needed.

> [!WARNING]
> A site that "loads but does nothing" (no emails, no search updates, no imports) almost always means the message-queue consumers are stopped. Check them before anything else.


Troubleshooting OroCommerce

Getting help

If you are stuck, gather the relevant log excerpts and the failing revision, then reach out via Support. For platform-wide issues, see the general Troubleshooting guide.


Troubleshooting OroCommerce

Related

- Deploy OroCommerce
- OroCommerce best practices
- Health
- Support


gitlab advanced database monitoring database monitoring Kubernetes app_type gitlab app_type pmm turbostack

# Self-hosted platforms: GitLab and Advanced Database Monitoring

TurboStack can also run two Kubernetes-based platforms: **GitLab** (`app_type: gitlab`) and **Advanced Database Monitoring** (`app_type: pmm`). Both run on a Kubernetes cluster with several supporting components. They are set up by Hosted Power through Support rather than self-service.

> [!NOTE]
> GitLab and Advanced Database Monitoring require a Kubernetes cluster and are set up by Hosted Power. Contact Support to have them enabled.


GitLab

GitLab runs on a Kubernetes cluster alongside the components it depends on: PostgreSQL, Redis, MinIO object storage, cert-manager, and an ingress controller. You select the major version, the edition, the domain, and how much persistent storage the deployment gets.

```yaml
app_type: gitlab
gitlab:
  major_version: 18
  edition: ce          # Community Edition
  domain: gitlab.example.com
  persistent_data_size: 60Gi
```


Advanced Database Monitoring

Advanced Database Monitoring is deployed with `app_type: pmm`. It is installed via Helm and includes Grafana for dashboards along with a large persistent volume for its time-series metrics data. Size the volume with `pmm_volume_size` according to how much monitoring history you need to retain.


Related

- Applications overview
- Networking
- Support


Shopware best practices

shopware performance shopware optimization shopware caching shopware turbostack shopware Redis shopware Varnish OpenSearch opcache

# Shopware best practices

This page collects practical recommendations for running a fast, stable Shopware 6 store on TurboStack. The platform already applies a tuned baseline when you deploy; the optimizations below build on it so your storefront stays responsive under load.


Shopware best practices

What TurboStack configures for you

When you deploy a `shopware` app, the platform provisions and tunes the following automatically:

- **Nginx vhost** tuned for Shopware, with long static-asset expiry, the `recovery`/installer routes, and PHP-FPM via a dedicated FastCGI backend (`/var/www/<user>/<app>/nginx/50main.conf`).
- **Document root** is `public_html`, symlinked to the Shopware `public/` directory so the application root stays outside the web root.
- **Redis** for both the object/HTTP cache and PHP sessions, configured through `config/packages/hostedpower.yaml` (cache app + object, HTTP, and tags pools; sessions on a persistent Redis socket).
- **Message queue transport** on Redis, set via `MESSENGER_TRANSPORT_DSN` in `.env.local` (`symfony/redis-messenger` is installed during provisioning).
- **Varnish full-page cache** with a Shopware-aware VCL (`/etc/varnish/conf.d/50_main.vcl`) using xkey-based tag invalidation and BAN/PURGE support, when `varnish_enabled` is set.
- **HTTP cache** enabled in `.env.local` (`SHOPWARE_HTTP_CACHE_ENABLED=1`, default Time to Live (TTL) `7200`).
- **MySQL tuning** for Shopware, including `group_concat_max_len` raised to handle large product datasets (`/etc/mysql/after.conf.d/shopware.cnf`).
- **Log rotation** for everything under `shopware/var/log/`, plus the `shopware-cli` tool for maintenance and build tasks.
- **OpenSearch wiring** in `.env.local` (`OPENSEARCH_URL`), ready to enable when you need search at scale.

> [!NOTE]
> Settings live in `.env.local` and `config/packages/hostedpower.yaml` in your app directory. Run `bin/console cache:clear` after changing them.


Shopware best practices

Recommended optimizations

- **Run in production mode** - keep `APP_ENV=prod` so Shopware uses compiled, cached containers and assets.
- **Keep Redis for cache and sessions** - already configured; verify both services are enabled under Services.
- **Run the message queue** - process the queue and scheduled tasks continuously so emails, indexing and background jobs do not accumulate. See Message-queue consumers below.
- **Enable Varnish** - set `varnish_enabled` for the storefront; it reduces PHP load on catalog and CMS pages.
- **Enable OpenSearch for large catalogs** - set `SHOPWARE_ES_ENABLED=1` and `SHOPWARE_ES_INDEXING_ENABLED=1`, then run `bin/console es:index` to offload product search from MySQL.
- **OPcache** - keep it on for the PHP runtime; it is part of the platform's PHP-FPM tuning.
- **Optimize media** - generate thumbnails ahead of traffic with `bin/console media:generate-thumbnails`; serve images via a Content Delivery Network (CDN) using the configured CDN strategy.
- **Warm the cache** - after deploys, run `bin/console cache:warmup` (the platform also crawls the storefront to prime Varnish).


Shopware best practices

Message-queue consumers

Shopware offloads emails, search indexing and other background work to a message queue, which TurboStack routes through Redis. In production you run the consumer from the command line instead of the browser-based admin worker.

Disable the admin worker in `config/packages/shopware.yaml` so the queue does not depend on an open Administration tab:

```yaml
shopware:
    admin_worker:
        enable_admin_worker: false
```

Then run the consumer and the scheduled-task runner. The `--time-limit` and `--memory-limit` flags stop a worker cleanly so a process manager can restart it fresh:

```bash
bin/console messenger:consume async low_priority --time-limit=60 --memory-limit=512M
bin/console scheduled-task:run
```

Run these as persistent user system services so they restart on failure and survive logout. To clear a backlog faster, run several consumers in parallel, but keep the total within the host's processor budget (see Scale throughput with more instances).


Shopware best practices

Sizing and scaling

Defaults are auto-tuned to the host's resources, so start there and scale on evidence, not guesswork. Override these only with measured data from real traffic:

| Variable | Tune when |
| --- | --- |
| `mysql_innodb_size` | InnoDB buffer pool for the Shopware database |
| `redis_memory` | Redis memory ceiling for cache and sessions |
| `varnish_cache_size` | Varnish full-page cache size |
| `elasticsearch_heap_size` | OpenSearch heap when search is enabled |

See Performance tuning for the methodology. Scale vertically first (CPU, RAM, faster storage) before adding complexity.

> [!TIP]
> Large catalogs benefit most from more InnoDB buffer pool and OpenSearch. Heavy storefront traffic benefits most from Varnish and Redis. Tune the one that matches your bottleneck.


Shopware best practices

Stability

- **Back up before changes** - verify scheduled backups cover both the database and the `shopware/` files; see Backups.
- **Watch the host** - monitor the Health tab for CPU, memory, and disk pressure.
- **Stay current** - keep Shopware, plugins, and the PHP runtime patched for security and performance fixes; pin `shopware_version` deliberately.
- **Test on a staging clone** - try plugin and version upgrades on a copy first, then publish to production.


Shopware best practices

Related

- Deploy Shopware
- Shopware reference
- Troubleshooting Shopware
- How to manage user system services
- Services
- Performance tuning


Deploy Shopware on TurboStack

deploy shopware shopware hosting shopware turbostack shopware 6 php 8.4 mysql Redis Varnish

# Deploy Shopware on TurboStack

Shopware 6 is an API-first e-commerce platform built on Symfony. On TurboStack the platform provisions the PHP runtime, MySQL database, and caching services from your host configuration, and you deploy by publishing.


Deploy Shopware on TurboStack

Requirements

| Requirement | Recommended |
| --- | --- |
| App type | `shopware` |
| Runtime | PHP 8.4 (or newer) |
| Database | MySQL 8.4 |
| Cache (Redis) | Enabled (cache + sessions) |
| Page cache (Varnish) | Enabled (recommended) |
| Web server | Nginx |

> [!NOTE]
> TurboStack can install Shopware automatically with `shopware_version`. Shopware also relies on scheduled tasks and cron, which the platform runs for you.


Deploy Shopware on TurboStack

Configure it

1. Open the host's Applications tab.
2. Click **Add app or database**.
3. Set **App Type** to `shopware` and choose the PHP runtime under **Technologies**.
4. Enable MySQL, Redis, and Varnish as services.
5. Publish to apply the configuration.


Deploy Shopware on TurboStack

Example configuration

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


Deploy Shopware on TurboStack

Why these choices

- **MySQL 8.4** is the Shopware core database for products, orders, and configuration.
- **Redis** is used for cache and session storage, which keeps the storefront responsive and offloads the database.
- **Varnish full-page cache** is recommended; Shopware integrates with reverse-proxy caching to serve storefront pages quickly.
- **Scheduled tasks and cron** are required by Shopware. Schedule the task runner and run the message-queue consumer for your system user (see the reference), so background jobs run reliably.
- **Nginx** is the supported web server and pairs with PHP-FPM for Shopware workloads.


Deploy Shopware on TurboStack

Related

- Technologies used: PHP, MySQL, Redis, Varnish, OpenSearch.

- Best practices - performance & stability.
- Troubleshooting - logs & common fixes.
- Applications overview
- Services
- Applications (host tab)
- The Source (YAML) view


Shopware reference

shopware cli bin/console shopware file layout shopware cron shopware commands message queue consumer shopware reference

# Shopware reference

Reference for running Shopware 6 on TurboStack: where the files live, the command-line tool, and the scheduled jobs. For setup see Deploy Shopware on TurboStack; for tuning see Shopware best practices.


Shopware reference

File layout

Everything lives under your system user's home directory. `~` is that home directory (for example `/var/www/prod/`). The base directory is `~/shopware/`, which can be symlinked for release-based deployments.

| Path | What it is |
| --- | --- |
| `~/public_html` | Web document root; must point to `~/shopware/public/` (direct or via symlink) |
| `~/shopware/` | Shopware base directory; run the command-line tool from here |
| `~/shopware/public/` | Served files, including the `index.php` front controller |
| `~/shopware/vendor/` | Composer dependencies |
| `~/shopware/custom/` | Plugins and themes |
| `~/shopware/config/` | Configuration: `.env`, `packages/` and `services.yaml` |
| `~/shopware/var/log/` | Logs |

For ownership and permissions, see Application file layout and permissions.


Shopware reference

Command-line reference

Shopware ships a command-line interface (CLI) at `bin/console`. Run every command from the Shopware base directory `~/shopware/`. The common commands are below.

| Command | What it does |
| --- | --- |
| `cache:clear` | Clear the application cache |
| `cache:warmup` | Warm the cache after a deploy |
| `dal:refresh:index` | Rebuild the Data Abstraction Layer (DAL) index |
| `es:index` | Build the Elasticsearch or OpenSearch index |
| `media:generate-thumbnails` | Generate media thumbnails |
| `scheduled-task:run` | Run due scheduled tasks |
| `messenger:consume` | Process the message queue |
| `system:update:finish` | Finish an update |

To clear all caches, run the application cache and the shared caches together:

```bash
cd ~/shopware && bin/console cache:clear
tscli redis clear
tscli varnish clear
```

`tscli redis clear` and `tscli varnish clear` use the TurboStack CLI.

To update Shopware, update the dependencies and then finish the update:

```bash
cd ~/shopware && composer update && bin/console system:update:finish
```


Shopware reference

Cron and background workers

Shopware needs its scheduled tasks run regularly. Add a cron entry for your system user - for example every 5 minutes:

```bash
*/5 * * * * cd ~/shopware && bin/console scheduled-task:run >> ~/logs/scheduled-task.log 2>&1
```

The message queue is processed with `bin/console messenger:consume`. On a busy store, run the consumer as a persistent user system service so it restarts on failure. See How to manage user system services.


Shopware reference

Cart storage in Redis (optional)

By default Shopware stores the cart in the database. On a high-traffic store you can move the cart to Redis to reduce database writes during checkout. Point it at the persistent Redis instance (port `6378`) so carts are not lost when the cache is flushed, and give it its own database index. The configuration key changed in Shopware 6.6.8.0.

On Shopware 6.6.8.0 and later, define a named connection and point the cart storage at it in `config/packages/shopware.yaml`:

```yaml
shopware:
    redis:
        connections:
            persistent:
                dsn: 'redis://localhost:6378/3'
    cart:
        storage:
            type: 'redis'
            config:
                connection: 'persistent'
```

On Shopware 6.5 and early 6.6 releases, use the single `redis_url` key instead:

```yaml
shopware:
    cart:
        redis_url: 'redis://localhost:6378/3'
```

Cart lifetime is controlled by `shopware.cart.expire_days` (default `120`). After switching the storage backend, migrate existing carts out of the database:

```bash
bin/console cart:migrate sql
```


Shopware reference

Related

- Deploy Shopware on TurboStack
- Shopware best practices
- Troubleshooting Shopware
- Application file layout and permissions
- How to manage user system services


Troubleshooting Shopware

shopware troubleshooting shopware logs shopware error shopware turbostack shopware 500 error messenger consume OpenSearch indexing

# Troubleshooting Shopware

When a Shopware store is not working correctly, the cause is usually a stale cache, a stalled message queue, an indexing issue, or a configuration mismatch. This page shows where to look and how to fix the most common problems on TurboStack.


Troubleshooting Shopware

Where to find the logs

Most answers are in the application log or the web server log. Your app directory is `/var/www/<user>/<app>/shopware/` (the `<app>/` segment is only present when an app name is set).

| Component | Where |
| --- | --- |
| Shopware application | `/var/www/<user>/<app>/shopware/var/log/*.log` (e.g. `prod-*.log`) |
| Nginx access/error | host log directory for the vhost (web server logs) |
| PHP-FPM | the PHP-FPM pool log for the runtime |
| Database (MySQL) | the MySQL error/slow-query log on the host |
| Varnish | Varnish runs in front of the storefront when `varnish_enabled` is set |

Also check the host's Health tab for resource pressure and service status. Check recent deploys in History to see whether a change coincides with the problem.

> [!TIP]
> Logs under `var/log/` are rotated automatically. To watch live errors, tail the current `prod-*.log` while reproducing the issue.


Troubleshooting Shopware

Common issues

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Stale prices, content, or layout | Outdated application/HTTP cache | Run `bin/console cache:clear`; if Varnish is on, also invalidate it (purge / `cache:clear:http`) |
| Emails, exports, or jobs never run | Message-queue worker or scheduled tasks not running | Ensure `messenger:consume` and `scheduled-task:run` are running; check the Redis transport in `.env.local` |
| Search empty or outdated | OpenSearch not indexed / disabled | With `SHOPWARE_ES_ENABLED=1`, run `bin/console es:index`; otherwise run `bin/console dal:refresh:index` |
| Missing or broken product images | Thumbnails not generated | Run `bin/console media:generate-thumbnails` |
| HTTP 500 / white screen | App error or bad config | Read the latest `var/log/prod-*.log`; verify `DATABASE_URL` and `APP_URL` in `.env.local`, then `cache:clear` |
| "Sales channel could not be found" / wrong URLs | Sales-channel domain mismatch | Make sure the storefront sales-channel URL matches the host's `server_name`/domain |
| Redis errors on every page | Redis service down or wrong socket | Confirm Redis is enabled in Services; check the sockets in `config/packages/hostedpower.yaml` |

> [!WARNING]
> Always run `bin/console` commands as the site's system user from the `shopware/` directory. Running them as root can leave cache and log files unwritable by PHP-FPM, producing fresh 500 errors.


Troubleshooting Shopware

A troubleshooting workflow

1. **Check Health** - check for CPU, memory, or disk exhaustion and confirm services are up.
2. **Read the relevant log** - start with `var/log/prod-*.log`, then the Nginx and PHP-FPM logs for HTTP 500s.
3. **Review the last deploy** - open History; if a recent change broke the site, revert and re-publish from Publishing.
4. **Verify services** - confirm MySQL, Redis, the message-queue worker, and Varnish are running in Services; clear the cache and warm it after any fix.


Troubleshooting Shopware

Getting help

If you are still stuck, gather the exact error from the logs, the time it started, and any recent deploy, then reach out via Support. The general platform troubleshooting guide covers host-level issues that affect every application.


Troubleshooting Shopware

Related

- Deploy Shopware
- Shopware best practices
- Health
- Support


WordPress best practices

wordpress performance wordpress optimization wordpress caching wordpress turbostack Varnish wordpress Redis object cache wp-cli woocommerce performance

# WordPress best practices

A fast, stable WordPress site comes from layered caching, a tuned runtime and disciplined change
management. On TurboStack, much of this is already configured for you when you deploy a `wordpress`
app. Most of your work is enabling the right plugins and avoiding conflicts. This page covers what
the platform configures and the optimizations worth adding on top.


WordPress best practices

What TurboStack configures for you

When you deploy WordPress, TurboStack provisions a working, production-shaped stack:

- **Nginx vhost tuned for WordPress** - the document root is `public_html`. Pretty-permalink
  rewrites (`try_files $uri $uri/ /index.php?$args`) are in place. Static assets (`js`, `css`,
  images, `ico`) are served with `expires max`. `xmlrpc.php` is denied to reduce the attack surface.
- **PHP-FPM backend per site** - PHP requests are passed to a dedicated FastCGI pool with a generous
  `fastcgi_read_timeout` (1200s) so long imports and updates do not time out.
- **Varnish full-page cache (optional)** - when `varnish_enabled` is set, a WordPress-aware VCL is
  installed. It bypasses the cache for `wp-admin`, logged-in users, the WooCommerce
  cart/checkout/my-account flows, and `wp-cron.php`. It caches static files for a day, normalises
  query strings, and strips tracking parameters (`utm_*`, `fbclid`, `gclid`). It supports `PURGE`
  from the Proxy Cache Purge plugin.
- **wp-config.php** - generated with your database credentials (`localhost`, dedicated DB and user),
  fresh secret-key salts and `WP_DEBUG` off for production.
- **Optional auto-install** - with `app_install: true`, wp-cli installs core and sets permalinks to
  `/%postname%/`. It removes the default themes and the Akismet/Hello plugins, then installs and
  activates WP Super Cache.


WordPress best practices

Recommended optimizations

- **Enable Redis object cache** - turn on Redis as a service and
  install a Redis object-cache plugin (for example `wp-redis`). Repeated queries (options,
  transients, sessions) then hit memory instead of MySQL, which cuts database load - especially for
  WooCommerce and logged-in traffic. Point the plugin at the Redis socket in `wp-config.php`, then
  enable it:
  ```php
  $redis_server = array( 'host' => '/var/run/redis/redis.sock', 'port' => null, 'database' => 1 );
  ```
  ```bash
  wp redis enable
  wp transient delete-all
  ```
  When several sites share one Redis server, give each a different `database` id so they do not
  overwrite each other's cache.
- **Use the Varnish full-page cache** - enable `varnish_enabled` for content-heavy and marketing
  sites; install the Proxy Cache Purge plugin so edits purge the cache automatically. Validate
  compatibility before enabling on stores with heavy logged-in flows.
- **Keep one full-page cache** - run a single full-page caching layer. If Varnish is on, prefer it
  and avoid a second page-cache plugin writing conflicting headers. Without Varnish, a plugin such as
  WP Rocket gives good defaults for mostly-static sites. On an Nginx (non-Varnish) setup, pair WP
  Rocket with the Rocket-Nginx configuration so Nginx
  serves WP Rocket's cached pages directly, bypassing PHP.
- **Consider a few extra speed plugins** - on large sites,
  Index WP Users for Speed keeps the admin
  fast when there are many users, and Speed Up Menu
  reduces the query overhead of large navigation menus.
- **Index the database** - a plugin such as Index WP MySQL for Speed adds indexes to the core tables
  (`wp_options`, `wp_postmeta`, `wp_posts`, and others), which speeds up slow queries on large sites.
  Install it, add the indexes, then you can remove the plugin again - the indexes stay:
  ```bash
  wp plugin install index-wp-mysql-for-speed
  wp plugin activate index-wp-mysql-for-speed
  wp index-mysql enable wp_commentmeta wp_comments wp_options wp_postmeta wp_posts wp_termmeta wp_usermeta wp_users
  wp plugin deactivate index-wp-mysql-for-speed
  wp plugin uninstall index-wp-mysql-for-speed
  ```
  If it reports that the tables are not found, use your site's actual table prefix instead of `wp_`
  (for example `SsW6eC_commentmeta`, `SsW6eC_options`, and so on).
- **OPcache** - the PHP runtime ships with OPcache; keep it enabled so compiled PHP is reused across
  requests.
- **Optimize assets and images** - use a modern image plugin (WebP, lazy-load) and minify/combine
  CSS and JS to cut requests.
- **Offload heavy media to a Content Delivery Network (CDN)** - front static assets with an HTTP
  cache/CDN to reduce origin load and improve global latency.
- **Speed up Elementor** - if you build pages with Elementor, enable **Element Caching** under
  `Elementor > Settings > Features`. Elementor assembles pages from many queries and template parts
  on every request; caching those lookups cuts database load and speeds up dynamic and logged-in
  views.
- **Raise memory in both places** - if you increase WordPress memory, raise the PHP limit too, or
  the change has no effect: set `WP_MEMORY_LIMIT` / `WP_MAX_MEMORY_LIMIT` in `wp-config.php` *and*
  `memory_limit` in `.user.ini`.


WordPress best practices

Set a default TTL for the Redis object cache

By default the Redis object cache does not expire keys that were stored without an explicit
time-to-live (TTL), so the cache can keep growing until it evicts entries or fills memory. The
object-cache drop-in reads a fallback TTL from a constant in `object-cache.php` (in `wp-content`):

```php
if ( ! defined( 'WP_REDIS_DEFAULT_EXPIRE_SECONDS' ) ) {
  define( 'WP_REDIS_DEFAULT_EXPIRE_SECONDS', 0 );
}
```

A value of `0` means "never expire". Set a real fallback - for example `28800` (8 hours) - so keys
stored without their own TTL still age out:

```php
if ( ! defined( 'WP_REDIS_DEFAULT_EXPIRE_SECONDS' ) ) {
  define( 'WP_REDIS_DEFAULT_EXPIRE_SECONDS', 28800 );
}
```

The drop-in talks to the TurboStack Redis cache instance - the socket configured above, or
`localhost` port `6379` with no password. After editing the drop-in, flush the object cache
(`wp cache flush`) so old entries pick up the new default.

This fallback only applies to keys stored without their own lifetime. Code that calls
`wp_cache_set()` with an explicit lifetime keeps that lifetime, and some plugins deliberately store
keys that never expire (for example `posts` keys). To find where such keys are created, search the
codebase for the calls and filter for the group you are chasing:

```bash
grep -Ri "wp_cache_set(" wp-content/plugins | grep 'posts'
```

Then give each of those calls a sensible lifetime instead of leaving it unbounded.


WordPress best practices

Run a real cron job

WordPress's built-in `wp-cron.php` runs on page loads, so scheduled tasks fire late on quiet sites
and too often on busy ones, wasting PHP processes. Replace it with a system cron job.

1. Disable the web trigger in `wp-config.php`:
   ```php
   define( 'DISABLE_WP_CRON', true );
   ```
2. Add a cron entry (every 5 minutes) that runs the due events. Wrap the command in `cronlock` so a
   slow run cannot overlap with the next one and pile up PHP processes:
   ```bash
   */5 * * * * cronlock wp cron event run --due-now --path=/var/www/prod/public_html > /dev/null 2>&1
   ```
3. Test it once by hand - it should report the events it executed:
   ```bash
   wp cron event run --due-now --path=/var/www/prod/public_html
   ```

For a multisite network, run the events for every site, not just once:

```bash
wp site list --field=url --path=/var/www/prod/public_html \
  | xargs -n1 -I{} wp cron event run --due-now --path=/var/www/prod/public_html --url="{}"
```


WordPress best practices

Plugin hygiene

- **Do not bulk-update every plugin at once.** Blind "update all" is a common cause of broken sites.
  Update selectively, test, and use Blackfire to find what actually slows the
  site before changing it.
- **Remove the redundant HTTPS plugin.** TurboStack handles HTTPS and redirects at the web-server
  layer, so the `really-simple-ssl` plugin is not needed:
  ```bash
  wp plugin deactivate really-simple-ssl
  wp plugin uninstall really-simple-ssl
  ```


WordPress best practices

Sizing and scaling

Defaults are auto-tuned to the host, so do not pre-emptively raise them. Override sizing variables
only with measured evidence (slow queries, cache evictions, swap):

| Variable | Tune when |
| --- | --- |
| `mysql_innodb_size` | MySQL working set no longer fits in the buffer pool |
| `redis_memory` | The object cache evicts keys under normal load |
| `varnish_cache_size` | Hot pages are being pushed out of the page cache |

See Performance tuning for how to measure before you change
anything.


WordPress best practices

Stability

- **Back up before every change.** Confirm backups are running so
  you can restore the database and uploads after a bad plugin or update.
- **Watch Health** for CPU, memory, PHP-FPM and database pressure,
  and act on sustained trends.
- **Keep WordPress, plugins, themes and PHP current** - most outages and exploits trace back to
  stale code; apply security updates promptly.
- **Test on a staging clone first.** Trial core upgrades, major plugin changes and theme switches on
  a copy before publishing to production.


WordPress best practices

Related

- Deploy WordPress
- WordPress reference
- Troubleshooting WordPress
- Services
- Performance tuning


Deploy WordPress on TurboStack

deploy wordpress wordpress hosting wordpress turbostack php 8.4 mysql Redis object cache woocommerce wp-cli

# Deploy WordPress on TurboStack

WordPress is a PHP content management system for blogs, marketing sites, and WooCommerce stores. On TurboStack, the platform provisions the PHP runtime, MySQL database, and caching services from your host configuration. You deploy by publishing.


Deploy WordPress on TurboStack

Requirements

| Requirement | Recommended |
| --- | --- |
| App type | `wordpress` |
| Runtime | PHP 8.4 (or newer) |
| Database | MySQL 8.4 |
| Cache (Redis) | Enabled (object cache, recommended) |
| Page cache (Varnish) | Optional (validate plugin compatibility) |
| Web server | Nginx |

> [!NOTE]
> TurboStack can auto-install WordPress for you. Set `app_install: true` and the platform uses wp-cli to scaffold the site, so you skip the manual installer.


Deploy WordPress on TurboStack

Configure it

1. Open the host's Applications tab.
2. Click **Add app or database**.
3. Set **App Type** to `wordpress` and choose the PHP runtime under **Technologies**.
4. Enable MySQL and Redis as services, and optionally enable Varnish.
5. Publish to apply the configuration.


Deploy WordPress on TurboStack

Example configuration

```yaml
webserver: nginx
mysql_version: "8.4"        # WordPress stores its data in MySQL
redis_enabled: true         # object cache (recommended, esp. WooCommerce)
system_users:
  - username: prod
    vhosts:
      - server_name: example.com www.example.com
        app_type: wordpress
        php_version: "8.4"
        cert_type: letsencrypt   # automatic HTTPS
        varnish_enabled: false   # optional full-page cache; verify plugin compatibility
```


Deploy WordPress on TurboStack

Why these choices

- **MySQL 8.4** is WordPress's canonical datastore; all posts, options, and metadata live there.
- **Redis** provides a persistent object cache that reduces repeated database queries. The gain is highest for WooCommerce and high-traffic sites.
- Varnish is left off by default because full-page caching can conflict with logged-in sessions and some plugins. Enable it only after validating compatibility.
- **Nginx** serves static assets efficiently and pairs well with PHP-FPM for WordPress workloads.
- **Let's Encrypt** gives automatic, renewing HTTPS with no manual certificate handling.


Deploy WordPress on TurboStack

Related

- Technologies used: PHP, MySQL, Redis, Varnish.

- Best practices - performance & stability.
- WP-CLI command reference - manage WordPress over SSH.
- Troubleshooting - logs & common fixes.
- Applications overview
- Services
- Applications (host tab)
- The Source (YAML) view


WordPress reference

wordpress cli wp-cli wp command wordpress file layout wordpress cron wp-cron wordpress reference

# WordPress reference

Reference for running WordPress on TurboStack: where the files live, the command-line tool, and the scheduled jobs. For setup see Deploy WordPress on TurboStack; for tuning see WordPress best practices.


WordPress reference

File layout

Everything lives under your system user's home directory. `~` is that home directory (for example `/var/www/prod/`). `~/public_html` is both the WordPress root and the web document root.

| Path | What it is |
| --- | --- |
| `~/public_html/` | WordPress root and web document root (the served files) |
| `~/public_html/wp-admin/` | Admin interface |
| `~/public_html/wp-content/` | Themes, plugins and uploads |
| `~/public_html/wp-includes/` | Core functions |
| `~/public_html/wp-config.php` | Site configuration |
| `~/nginx/` | Custom Nginx configuration |

For ownership and permissions, see Application file layout and permissions.


WordPress reference

Command-line reference

WordPress ships a command-line interface (CLI) called WP-CLI. Run its commands with the `wp` tool from `~/public_html`. The common command groups are below.

| Command | What it does |
| --- | --- |
| `wp core download` / `install` / `update` / `version` / `check-update` | Download, install, update or report the WordPress core |
| `wp plugin install` / `activate` / `deactivate` / `delete` / `update` / `list` | Manage plugins |
| `wp theme install` / `activate` / `delete` / `update` / `list` | Manage themes |
| `wp user create` / `delete` / `list` / `update` / `get` | Manage users |
| `wp db export` / `import` / `reset` / `check` / `optimize` | Manage the database |
| `wp media import` / `regenerate` | Import media or regenerate thumbnails |
| `wp option get` / `update` / `delete` | Read or change a site option |
| `wp config create` / `set` / `get` | Manage `wp-config.php` values |
| `wp cron event list` / `run` / `delete` | Inspect or run scheduled events |
| `wp cache flush` | Flush the object cache |
| `wp transient get` / `set` / `delete` | Manage transients |
| `wp search-replace <old> <new>` | Replace strings across the database (add `--dry-run` first) |
| `wp site url` | Show or set site URLs |
| `wp rewrite flush` | Flush permalink rewrite rules |
| `wp eval` / `wp shell` | Run PHP code or open an interactive shell |

Caching runs in front of WordPress with Redis and Varnish. Page-cache plugins include W3 Total Cache, WP Super Cache and LiteSpeed Cache. Clear the platform caches with the TurboStack command-line tool (`tscli`):

> [!WARNING]
> `tscli redis clear` and `tscli varnish clear` flush the whole cache. Traffic hits the origin until the cache refills. See TurboStack CLI.


WordPress reference

Cron

WordPress schedules tasks with `wp-cron`, which runs only on page visits. On quiet sites jobs fire late; on busy sites they fire too often and waste PHP processes. For reliability, disable the web trigger and run a real cron that calls WP-CLI.

1. Disable the web trigger in `wp-config.php`:
   ```php
   define( 'DISABLE_WP_CRON', true );
   ```
2. Add a cron entry (every 5 minutes) that runs the due events:
   ```bash
   */5 * * * * wp cron event run --due-now --path=/var/www/prod/public_html > /dev/null 2>&1
   ```

For the multisite variant and full guidance, see WordPress best practices. To run a real cron as a persistent user service, see How to manage user system services.


WordPress reference

Related

- Deploy WordPress on TurboStack
- WordPress best practices
- Troubleshooting WordPress
- Application file layout and permissions
- How to manage user system services


Troubleshooting WordPress

wordpress troubleshooting wordpress logs wordpress error wordpress turbostack white screen of death wordpress 404 permalinks Varnish cache wp-config database error

# Troubleshooting WordPress

Most WordPress problems on TurboStack come from a single change: a plugin or theme update, a caching layer, or a configuration edit. This page shows where the logs live, the issues you are most likely to hit, and a repeatable workflow to isolate the cause quickly.


Troubleshooting WordPress

Where to find the logs

Read logs in the order a request travels: web server, then PHP, then WordPress, then the database.

| Component | Where |
| --- | --- |
| Nginx access/error | The host's Nginx log directory (per-vhost access and error logs) |
| PHP-FPM | The PHP-FPM pool log for the site's system user |
| WordPress (PHP) | `wp-content/debug.log` in the site's `public_html` (only when debug logging is enabled) |
| Varnish | The Varnish service log on the host (when `varnish_enabled`) |
| MySQL | The MySQL error/slow-query log on the host |
| Nginx vhost config | `/var/www/<user>/<app>/nginx/50main.conf` |
| wp-config.php | In the site's `public_html` (DB credentials, salts, `WP_DEBUG`) |

To capture PHP errors temporarily, set `WP_DEBUG` and `WP_DEBUG_LOG` to `true` in `wp-config.php`; this writes to `wp-content/debug.log`. Turn it off again on production. You can also see resource and service status on the host's Health tab and recent deploys in History.


Troubleshooting WordPress

Common issues

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| White screen / HTTP 500 | PHP fatal error from a plugin, theme or update | Enable `WP_DEBUG_LOG` and read `wp-content/debug.log`; deactivate the offending plugin/theme via wp-cli (`wp plugin deactivate <name>`) or by renaming its folder |
| "Error establishing a database connection" | Wrong credentials, or MySQL down/overloaded | Verify the `DB_*` values in `wp-config.php`, confirm MySQL is running in Services, check the MySQL log |
| Pages 404 except the home page | Rewrite/permalink rules lost | Re-flush permalinks: `wp rewrite flush --hard` (the platform sets `/%postname%/`); confirm the Nginx `try_files ... /index.php?$args` block |
| Stale content after editing | Full-page cache not purged | Install/configure the Proxy Cache Purge plugin so edits purge Varnish; check the `X-Cacheable` response header to see hits vs passes |
| Logged-in or cart pages caching wrongly | Page cache caching session traffic | Varnish already bypasses `wp-admin`/cart/`my-account`; avoid stacking a second page-cache plugin and verify custom URLs are in the bypass list |
| Redis object cache not connecting | Plugin misconfigured or Redis disabled | Enable Redis in Services and reconnect the object-cache plugin; remove a stale `object-cache.php` drop-in if Redis is off |
| Media upload "exceeds the maximum" | PHP/nginx upload limits too low | Raise `upload_max_filesize`/`post_max_size` and the Nginx `client_max_body_size` for the site |
| Mixed-content warnings after HTTPS | URLs still stored as `http://` | Run `wp search-replace 'http://example.com' 'https://example.com'` and set the site/home URL to `https://` |


Troubleshooting WordPress

A troubleshooting workflow

1. **Check Health** - rule out CPU, memory, PHP-FPM or database saturation before chasing application bugs.
2. **Read the relevant log** - start with the Nginx error log and PHP-FPM/`debug.log` for 500s and white screens; the MySQL log for connection errors.
3. **Check the last deploy in History** - if a recent change broke the site, revert and Publish the previous working revision.
4. **Verify services are running** - confirm Nginx, PHP-FPM, MySQL and (if used) Redis and Varnish are up in Services; reload after config changes.


Troubleshooting WordPress

Getting help

If the issue persists after these steps, reach out via Support. For platform-wide problems beyond WordPress itself, see the general Troubleshooting guide. Include the relevant log excerpts and the revision where the problem started.


Troubleshooting WordPress

Related

- Deploy WordPress
- WordPress best practices
- Health
- Support


WP-CLI command reference

wp-cli wp command wordpress cli wp plugin wp db export wp search-replace wp cron manage wordpress ssh

# WP-CLI command reference

WP-CLI is the command-line interface (CLI) for WordPress. It is installed on every TurboStack host as `wp`, so you can manage a site over SSH instead of clicking through the admin. This makes it fast for updates, bulk changes and scripting across many sites. This page groups the common commands by task. For where the files live and the cron setup, see WordPress reference.


WP-CLI command reference

How to run it

Connect over SSH, change into the WordPress root, then run `wp`:

```bash
cd ~/public_html
wp <command>
```

Here `~` is your system user's home directory (for example `/var/www/prod/`), and `~/public_html` is the WordPress root. WP-CLI reads `wp-config.php` from this directory, so always run it from there (or pass `--path=/var/www/prod/public_html`).

Run `wp help` for the full command list, or `wp help <command>` for the options and examples of a single command.


WP-CLI command reference

Core

| Command | What it does |
| --- | --- |
| `wp core download` | Downloads WordPress core files. |
| `wp core install` | Runs the WordPress installation. |
| `wp core update` | Updates WordPress core to the latest version. |
| `wp core version` | Displays the current WordPress version. |
| `wp core check-update` | Checks for available core updates. |


WP-CLI command reference

Plugins

| Command | What it does |
| --- | --- |
| `wp plugin install <plugin>` | Installs a plugin by slug or URL. |
| `wp plugin activate <plugin>` / `deactivate <plugin>` | Activates or deactivates a plugin. |
| `wp plugin update <plugin>` | Updates a specific plugin. |
| `wp plugin delete <plugin>` | Deletes a plugin. |
| `wp plugin list` | Lists installed plugins with status. |


WP-CLI command reference

Themes

| Command | What it does |
| --- | --- |
| `wp theme install <theme>` | Installs a theme by slug or URL. |
| `wp theme activate <theme>` | Activates a theme. |
| `wp theme update <theme>` | Updates a specific theme. |
| `wp theme delete <theme>` | Deletes a theme. |
| `wp theme list` | Lists installed themes. |


WP-CLI command reference

Users

| Command | What it does |
| --- | --- |
| `wp user create <username> <email>` | Creates a new user. |
| `wp user list` | Lists all users. |
| `wp user update <user>` | Updates user information. |
| `wp user get <user>` | Displays user data. |
| `wp user delete <user>` | Deletes a user. |


WP-CLI command reference

Database

| Command | What it does |
| --- | --- |
| `wp db export` | Exports the database to an SQL file. |
| `wp db import <file>` | Imports an SQL file into the database. |
| `wp db check` | Checks database for errors. |
| `wp db optimize` | Optimizes the database. |
| `wp db reset` | Drops all tables and reinitializes the DB. |


WP-CLI command reference

Content and options

| Command | What it does |
| --- | --- |
| `wp post create` / `update <id>` / `delete <id>` / `list` | Creates, updates, deletes, or lists posts. |
| `wp media import <file>` | Imports media files into the Media Library. |
| `wp media regenerate` | Regenerates image sizes for Media Library. |
| `wp option get <name>` / `update <name> <value>` / `delete <name>` | Gets, updates, or deletes an option value. |
| `wp config create` / `set <key> <value>` / `get <key>` | Creates a `wp-config.php` file, or sets and gets config values. |


WP-CLI command reference

Cron

| Command | What it does |
| --- | --- |
| `wp cron event list` | Lists scheduled cron events. |
| `wp cron event run <hook>` | Executes a cron event immediately. |
| `wp cron event run --due-now` | Run all events that are due |
| `wp cron event delete <hook>` | Deletes a cron event. |

For reliable scheduling, replace the default web-triggered `wp-cron` with a real cron job that calls WP-CLI - see WordPress reference.


WP-CLI command reference

Cache and search-replace

| Command | What it does |
| --- | --- |
| `wp cache flush` | Clears the object cache. |
| `wp transient get <name>` / `set` / `delete` | Gets, sets, or deletes a transient value. |
| `wp search-replace <old> <new>` | Replaces strings in DB. |
| `wp rewrite flush` | Flushes rewrite rules. |

> [!WARNING]
> Always test `wp search-replace` with `--dry-run` first. It reports how many rows would change without writing anything. This matters most when moving a site between domains (for example `dev.example.com` to `example.com`).

> [!NOTE]
> `wp cache flush` clears WordPress's own object cache. The platform caches (Redis and Varnish) are separate - clear those with the TurboStack command-line tool (`tscli redis clear`, `tscli varnish clear`). See TurboStack CLI.


WP-CLI command reference

WP-CLI itself

| Command | What it does |
| --- | --- |
| `wp cli update` | Updates WP-CLI itself to the latest release. |


WP-CLI command reference

Related

- WordPress reference
- Deploy WordPress on TurboStack
- WordPress best practices
- Troubleshooting WordPress
- Connect over SSH


Glossary

# Glossary

A quick reference to the terms you will encounter across TurboStack, grouped by topic. Where a
term has a dedicated page, follow the link for the full details.


Glossary

Core objects

| Term | Definition |
|---|---|
| **Host** | A single server and the configuration it should run. It is the central object you work with. See Hosts. |
| **System user** | An operating-system account on a host that owns files and runs applications. Applications are configured beneath a system user. See Applications. |
| **Application (vhost)** | An individual site or application running under a system user, with its own domain, application type, PHP version and TLS certificate. See Applications. |
| **Group** | A reusable set of settings, such as SSH keys or security rules, applied to many hosts at once. See Groups. |
| **Template** | A pre-built host configuration you can apply to new hosts to save setup time. See Templates. |
| **System type** | How a host's server is managed (`customstack`, `cpanel`, `directadmin` or `windows`), which determines the tabs and options available. See System types. |
| **Client** | A customer account that owns hosts, groups and templates. You only ever see the resources of the account you are signed in to. See Accounts and access. |


Glossary

Platform, tools and features

| Term | Definition |
|---|---|
| **TurboStack Platform** | Hosted Power's platform for managing your hosting infrastructure, usable through the GUI, YAML (Source view) or the REST API. See TurboStack Platform. |
| **Customer Center** | Hosted Power's customer portal for your account, services, domains, billing, contacts and support tickets. See Customer Center. |
| **TurboStack CLI (`tscli`)** | The command-line tool on every TurboStack server for managing live services and common admin tasks (caches, firewall, email, logs) over SSH. See TurboStack CLI. |
| **Backups** | Scheduled and on-demand backups of a host's files and databases, with restore to a chosen target. See Backups. |
| **Monitoring** | Fleet-wide health and alerting across your hosts, plus per-application uptime checks. See Monitoring. |
| **Migration Hero** | A tool that pulls an existing site from an external host into TurboStack. See Migration Hero. |
| **Cloning** | Copying an account's files and database to another system user, for example to make a staging copy. See History. |
| **Staging** | A non-production copy of a site used to test changes before applying them to the live site. |
| **User system service** | A long-lived application process (queue worker, message-queue consumer or background job) run as a per-user systemd service that restarts on failure and survives logout. See System services. |


Glossary

Configuration and deployment

| Term | Definition |
|---|---|
| **Publish / Deploy** | Saving and applying a host's configuration to the server so the server matches your intended state. See Publishing changes. |
| **Full Publish** | A complete deployment that re-applies the whole configuration (**Save & Full Publish**), used after larger changes or to be thorough. See Publishing changes. |
| **Full & Reset Deploy** | A full deployment that also permanently removes anything you deleted from the configuration (**Save, Delete & Full Publish**), destroying the associated data. See Publishing changes. |
| **Revision** | A saved snapshot of a configuration, recorded each time you save, that you can review and restore. See History. |
| **Source (YAML) view** | The raw-YAML editor for a configuration, kept in sync with the GUI editor. See The Source (YAML) view. |
| **Credentials** | The server and per-account access details for a host. See Credentials. |
| **Desired state** | The configuration you define for a host as the intended end result; TurboStack deploys the server to match it. See Introduction. |
| **Wildcard certificate** | A TLS certificate covering all subdomains of a domain (`*.example.com`); it requires the DNS validation challenge. See TLS certificates. |


Glossary

Health and security

| Term | Definition |
|---|---|
| **Health** | Live monitoring for a host: top issues plus CPU, memory, disk and service checks. See Health. |
| **Threat Center** | The host tab that surfaces security findings and vulnerabilities detected on that host. See Threat Center. |
| **TurboShield** | TurboStack's web-traffic protection: rate limiting, bot classification, search-bot verification, known-exploit blocking, attack detection with auto-expiring bans, and an optional bot challenge. Enabled by default. See What is TurboShield?. |
| **TurboRadar** | Runtime security detection and scanning that runs after deployment, reporting findings to the Threat Center. Enabled on every host. See Security overview. |
| **Firewall** | A managed, stateful firewall that automatically blocks malicious IP addresses from brute-force attempts and web attacks, with auto-expiring bans, while honouring your allow-list. See Security overview. |
| **PrivateNet** | A secure, encrypted private overlay network (a mesh Virtual Private Network, or VPN) connecting your managed servers. See Networking. |


Glossary

Security findings and scores

These terms appear in the Threat Center, where you read and act
on a host's security findings. See that page for how to interpret and prioritise them.

| Term | Definition |
|---|---|
| **CVE** (Common Vulnerabilities and Exposures) | A public, unique identifier for one specific known security weakness in software, written `CVE-2024-12345`. It names the weakness; the scores below say how urgent it is. |
| **CVSS** (Common Vulnerability Scoring System) | A severity score from 0.0 to 10.0 for how much damage a weakness could cause *if* exploited (9.0+ Critical, 7.0-8.9 High, 4.0-6.9 Medium, 0.1-3.9 Low). It rates impact, not likelihood. |
| **EPSS** (Exploit Prediction Scoring System) | A percentage (0-100%) estimating how *likely* a weakness is to be exploited within 30 days. 80% or more is shown as "Likely exploited". It rates likelihood, not severity. |
| **KEV** (Known Exploited Vulnerabilities) | A public catalogue of weaknesses confirmed to be under active attack in the real world. An "Exploited (KEV)" badge is the strongest signal to fix immediately. |
| **Risk score** | A single number TurboStack calculates by combining KEV, EPSS and CVSS, so you can prioritise without weighing each score yourself. The vulnerabilities list is sorted by it, most urgent first. |
| **IoC** (Indicator of Compromise) | Evidence that a host has *already* been breached, most often a malicious file (web shell, backdoor, skimmer) found on disk. Always treated as Critical. |
| **Vulnerability** | A known weakness in your software or its dependencies that an attacker could exploit. Usually fixed by updating to the "Fixed in" version. |


Glossary

Applications

Application types you can deploy. Each has a deploy guide with example YAML - see Deploying applications.

| Application | What it is |
|---|---|
| **Magento 2 / Adobe Commerce** | A PHP e-commerce platform (MySQL, Elasticsearch/OpenSearch, Redis, Varnish). See Magento. |
| **WordPress** | A PHP content management system (CMS) for applications and blogs (MySQL, Redis). See WordPress. |
| **Shopware** | A PHP e-commerce platform (MySQL, Redis, Varnish). See Shopware. |
| **Drupal** | A PHP content management system (MySQL, Redis). See Drupal. |
| **Laravel** | A PHP web-application framework (MySQL, Redis), with your code deployed via Git. See Laravel. |
| **Akeneo** | A PHP Product Information Management (PIM) system (MySQL, Elasticsearch, Redis). See Akeneo. |
| **OroCommerce** | A PHP B2B e-commerce platform (MySQL, Redis, RabbitMQ). See OroCommerce. |
| **Craft CMS** | A PHP content management system (MySQL, Redis). See Craft CMS. |
| **Nextcloud** | A PHP self-hosted file-sync and collaboration suite (MySQL or PostgreSQL, Redis). See Nextcloud. |
| **Odoo** | A Python Enterprise Resource Planning (ERP) and business suite (PostgreSQL), run behind Nginx. See Odoo. |
| **Medusa** | A Node.js headless commerce platform (PostgreSQL), run behind the Nginx reverse proxy. See Medusa. |
| **nopCommerce** | A .NET e-commerce platform (Microsoft SQL Server), run behind the Nginx reverse proxy. See nopCommerce. |
| **GitLab** | A self-hosted DevOps platform, run on Kubernetes and set up by Hosted Power through Support. See Self-hosted platforms. |
| **Advanced Database Monitoring** | TurboStack's database query-performance and metrics monitoring, run on Kubernetes via a monitoring master server. See Self-hosted platforms. |


Glossary

Technologies

The open-source building blocks TurboStack provisions and manages. Each has a "what is" and a "configure" page - see Technologies.

| Technology | What it is |
|---|---|
| **Nginx** | The default web server and reverse proxy. See Nginx. |
| **Apache** | An alternative web server (`apache2`) for apps that need `.htaccess` or Apache modules. See Apache. |
| **PHP** | The server-side language behind most applications; multiple versions per application. See PHP. |
| **PHP-FPM** | The FastCGI Process Manager that runs PHP behind the web server; its worker pool handles requests. |
| **Node.js** | A server-side JavaScript runtime, run as a process behind the reverse proxy. See Node.js. |
| **Python** | A general-purpose language, run as a per-application process behind the reverse proxy. See Python. |
| **Ruby** | A dynamic language, run as an isolated per-user process. See Ruby. |
| **.NET** | Microsoft's open-source runtime for web apps and services, run behind the reverse proxy. See .NET. |
| **MySQL** | A widely used open-source relational database (TurboStack runs Percona Server for MySQL). See MySQL. |
| **MariaDB** | A MySQL-compatible open-source relational database. |
| **Percona Server** | The performance-tuned MySQL and MongoDB distributions TurboStack runs. |
| **PostgreSQL** | A standards-compliant open-source relational database. See PostgreSQL. |
| **MongoDB** | A document-oriented NoSQL database (Percona Server for MongoDB). See MongoDB. |
| **Microsoft SQL Server** | A relational database used by .NET applications. See Microsoft SQL Server. |
| **Redis** | An in-memory data store for object cache, sessions and queues. See Redis. |
| **Varnish** | An HTTP full-page cache that accelerates PHP storefronts, configured with VCL. See Varnish. |
| **Elasticsearch** | A distributed full-text search and analytics engine. See Elasticsearch. |
| **OpenSearch** | An open-source, Elasticsearch-compatible search engine. See OpenSearch. |
| **RabbitMQ** | An Advanced Message Queuing Protocol (AMQP) message broker for asynchronous task and job queues. See RabbitMQ. |
| **Docker** | Runs a containerized application on an application, with Nginx proxying to the container. See Docker. |
| **Kubernetes** | A lightweight container orchestrator for running containerized workloads. See Kubernetes. |
| **Reverse proxy** | Nginx forwarding public traffic to a backend application process or container. See Reverse proxy. |
| **Process manager** | A supervisor (such as Supervisor or PM2) that keeps long-running app processes and queue workers alive. |
| **Buffer pool** | The in-memory area MySQL/InnoDB uses to cache data and indexes; the main database performance tuning knob. |
| **Swap** | Disk space used as overflow when a server runs out of RAM; heavy swapping slows the server. |


Glossary

Web serving and performance

Words that appear throughout the technology and troubleshooting pages.

| Term | Definition |
|---|---|
| **Backend** | The application process behind the web server that actually builds a response: a PHP-FPM pool, a Node.js or Python process, or a container. Nginx takes the visitor's request and passes it to the backend. |
| **Upstream** | The backend address Nginx forwards a request to, declared as an `upstream` block in the Nginx configuration. "The upstream is down" means the application behind Nginx did not answer. See Reverse proxy. |
| **Document root (docroot)** | The directory the web server serves a site's files from, usually `public_html`. See Change your Nginx docroot. |
| **Worker** | One process that handles one unit of work at a time. A PHP-FPM worker is a single PHP process handling one request at a time, so the number of workers is how many requests a site can process at once. A queue worker does the same for background jobs. |
| **Consumer** | A long-running process that takes messages off a queue and handles them, for example an OroCommerce message-queue consumer. See RabbitMQ. |
| **Cache hit ratio** | The share of requests answered from the cache instead of the application or database. A low ratio means requests are missing the cache, so PHP and the database do the full work. See Why is my site slow?. |


Glossary

Email terms

Terms used on the Email deliverability and
SMTP error codes pages.

| Term | Definition |
|---|---|
| **Hard fail (`-all`)** | An SPF record that ends in `-all` tells receiving servers to reject mail from any server it does not list. A soft fail (`~all`) only asks them to treat it as suspicious. |
| **Alignment** | The DMARC check that the domain a reader sees in the From address belongs to the same domain that passed SPF or DKIM. Strict alignment wants an exact match; relaxed alignment also accepts a parent domain or a subdomain. |
| **MailFROM domain** | The domain the sending server gives in the SMTP `MAIL FROM` command (the envelope sender). SPF checks this domain, and the reader never sees it. |
| **Header From domain** | The domain in the `From:` address shown in the reader's mail client. DMARC alignment compares it with the MailFROM domain or the DKIM signing domain. |