Deploying applications on TurboStack

TurboStack runs your applications on a host (a server). You describe what the application needs - a runtime (PHP, Node.js, Python or .NET), a database, and optional services like Redis, Elasticsearch or Varnish - and TurboStack provisions and configures everything for you when you publish. This page explains how that works and gives a configuration pattern you can reuse for any application.

Everything runs on a standard open-source stack (Nginx, PHP, MySQL, Redis, Elasticsearch and similar), so your application stays portable and is not tied to a proprietary platform.

How deployment works (3 steps)

1. Open a host and go to its Applications tab. Click Add app or database.

2. Choose the application under Technologies (the App Type) and enable what it needs - PHP/Node/Python version, database, caching, search. TurboStack wires the services together.

3. Publish the host. TurboStack installs and configures the stack so the running server matches your configuration.

You can do all of this in the GUI editor or directly as YAML in the Source view - both describe the same configuration.

What every application needs

The base configuration pattern

Almost every application follows the same skeleton - global services on the host, and one or more applications (vhosts) under a system user:

# ── Host-level services ───────────────────────────────
webserver: nginx               # web server for all sites on this host
mysql_version: "8.4"           # a database engine (or postgresql_version)
redis_enabled: true            # in-memory cache (sessions/objects) - on by default

# ── Accounts and their applications ───────────────────
system_users:
  - username: prod              # the OS account that owns the files
    vhosts:
      - server_name: example.com www.example.com   # the domain(s)
        app_type: wordpress    # which application TurboStack provisions
        php_version: "8.4"     # the runtime version for this site
        cert_type: letsencrypt # automatic HTTPS certificate

How to choose services

These rules let you (or an AI assistant) build a correct configuration for any application:

• The database follows the application. PHP CMS/shop apps (WordPress, Drupal, Magento, Shopware, Craft CMS) use MySQL (mysql_version). Odoo and Medusa use PostgreSQL (postgresql_version). Akeneo, Craft CMS and Nextcloud support either.

• The runtime follows the application. PHP apps set php_version; Medusa (Node) sets nodejs_version; Odoo (Python) needs no version key; nopCommerce (.NET) sets dotnet_version.

• Redis (redis_enabled: true) is recommended for almost everything - sessions and object cache - and is on by default.

• Elasticsearch/OpenSearch (elasticsearch_version) is required by Magento 2 and used by Akeneo; most other apps don't need it.

• Varnish (varnish_enabled: true, per application) is full-page caching for PHP storefronts (Magento, Shopware, optionally WordPress). Don't use it for Node apps or Odoo.

• Node and Odoo run as their own process behind nginx. For Medusa (and other Node apps) set proxy_enabled: true and proxy_upstream_port. Odoo uses app_type: odoo (proxying is handled for you).

• Transport Layer Security (TLS) is almost always cert_type: letsencrypt (automatic HTTPS).

Application performance monitoring

New Relic and Tideways are set per application, not per host. Open the application's Configure application > Monitoring tab, turn on New Relic APM or Tideways, and paste the key from your own account. TurboStack installs and configures the agent for that application only; the subscription and the data stay with your monitoring account. Turning the toggle off again removes the keys.

system_users:
  - username: prod
    vhosts:
      - server_name: example.com
        app_type: magento2
        php_version: "8.4"
        # New Relic: reports this application under its own name
        newrelic_appname: "Example production"
        newrelic_license: "nr_xxxxxxxxxxxx"
        # Tideways: instead of, or next to, New Relic
        tideways_apikey: "tw_xxxxxxxxxxxx"
        tideways_service: web
        tideways_sample_rate: 25

Blackfire works differently: it is available on the host and you start a profiling session yourself, from the browser extension or with tscli blackfire enable. The server-level agent that reports the machine's own metrics to your New Relic account is set on the host's Advanced tab. See Monitoring for what each product is good at.

Application catalog

File layout and permissions

Once an application is deployed, its files live under your system user's home directory, and you work with them over Secure Shell (SSH). ~ below is that home directory, for example /var/www/prod/ for the system user prod.

Ownership and permissions

Your system user must own all application files, so updates and package installs do not fail on permission errors. Files should be readable and directories listable, without being world-writable. Run these from your application root, replacing prod with your system user:

find ~/public_html -type f -exec chmod 644 {} \;   # files: readable
find ~/public_html -type d -exec chmod 755 {} \;   # directories: listable
chown -R prod:prod ~/public_html                   # your user owns everything

Composer and caches

Applications that use Composer (the PHP dependency manager) install from the application root; after a change, clear the relevant caches with the TurboStack CLI:

cd ~/public_html && composer install   # or: composer update (test on staging first)
tscli redis clear                       # clear the Redis cache
tscli varnish clear                     # clear the Varnish full-page cache

Related

• Applications (host tab) - the GUI where you configure this.
• Services - the databases, caching and search engines.
• The Source (YAML) view - edit the configuration as YAML.
• Monitoring - New Relic, Tideways, Blackfire and database monitoring.
• Publishing changes - deploy it to the server.
• Glossary - what the terms and abbreviations mean.
• Sales - help sizing the platform for your application.