# Configuration recipes

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

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

## A simple website (WordPress)

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

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

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

## A busy online store (Magento 2)

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

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

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

## A Shopware store

A Shopware 6 storefront with caching.

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

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

## Odoo (business software)

Move an Odoo installation onto TurboStack.

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

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

## A Laravel application

A PHP application built on Laravel, with background queues.

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

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

## A Node.js application

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

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

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

## Several applications on one host

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

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

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

## Application server plus a separate database server

Keep the database on its own server for larger workloads.

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

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

## Dependencies and rules

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

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

## Related

- [YAML configuration reference](index.md)
- [The Source (YAML) view](../../concepts/yaml-view.md)
- [Publishing changes](../../platform/hosts/publishing.md)