Configuration recipes

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

A simple website (WordPress)

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

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.

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.

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.

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.

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

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.

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.

# 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
• The Source (YAML) view
• Publishing changes