Services
The host's Services tab is where you choose the server-level services: the web server, the databases, the caching layers, and the search engine. Enable a service and pick its version; the left-hand menu lists each service.
This tab covers:
Web server - Nginx or ApacheDatabases - MySQL, PostgreSQL, MongoDB, and SQL ServerCaching and queues - Redis, Varnish, and RabbitMQSearch - Elasticsearch and OpenSearch
Tip
Memory sizing (database buffers, cache size, search heap) is auto-tuned to the server. Only override it with measured evidence. Changing a service's major version can be disruptive - plan and test it.
Web server
Each host runs one web server, selected with webserver:
Note
PHP and other language runtimes are chosen per application on the Applications tab (a host can serve several PHP versions side by side).
Databases
Enable and pick a version for each database you need:
Important
Network bind addresses (mysql_bindaddress, postgresql_listen_addresses, mongodb_bindip) are
security-sensitive - keep them restricted to trusted networks. All three accept the keyword
ANY, which listens on every interface the server has, including any public one. Prefer a
specific private address, and restrict access with the firewall.
Warning
On a host that also runs Kubernetes or Docker, the databases listen on every interface unless
you set the bind address yourself - the containers have to be able to reach them. MongoDB does
this even when its bind address is set to 127.0.0.1. Set the address explicitly on such a host
if you need it narrower, and make sure the firewall is closed.
You can administer MySQL through phpMyAdmin, and enable Advanced Database Monitoring (under the host's Advanced tab) for deep database monitoring - see Monitoring (concepts).
Client-only mode
MySQL and PostgreSQL each have a Client only toggle. Turn it on when the database does not run on this host but on another server. TurboStack then installs only the database client tools, and the server settings (bind address, buffer sizes, extensions, extra access) disappear from the form.
Two fields replace them:
This is the application-server half of a split setup: this host runs the web server and the application, and a separate host runs the database engine. It keeps database load off the application server, and lets several application servers share one database.
# Application server: no local database engine, connect to db1 instead
mysql_version: "8.4"
mysql_server: false # what the "Client only" toggle sets for MySQL
mysql_client_host_name: db1.example.com
mysql_client_host_ip: 10.0.0.5
# PostgreSQL uses its own key for the same thing
# postgresql_client_only: true
# postgresql_client_host_name: db1.example.com
# postgresql_client_host_ip: 10.0.0.5Important
The database server must accept connections from this host. On the database server, open the bind address or listen addresses to the private network and grant the user access. Never open a database to the public internet.
The database server itself is a second host configuration - see Application server plus a separate database server.
Microsoft SQL Server edition
When you enable Microsoft SQL Server you also pick an edition (mssql_edition): Developer,
Enterprise, Express, Standard or Web. If you do not choose one, Express is installed.
The editions differ in features, in the limits they impose, and in licensing, so check what your
license allows before you pick one.
Caching and queues
Tip
Use Redis 6379 for transient cache and 6378 for durable sessions and queues - never store
data you cannot lose on the cache instance.
Search
Enable Elasticsearch or OpenSearch and pick a version (Elasticsearch 8.x-9.x, OpenSearch 2.x-3.x). The JVM heap is auto-sized; plugins are configurable. OpenSearch supports nightly snapshots of your indices.
Both engines offer the same three extras once you pick a type and a version:
opensearch_version: "3.x"
opensearch_dashboards: true
opensearch_plugins: [analysis-icu]Reaching the web interface
Once installed, the interface is served by the host's own web server on a fixed path:
The web server asks for a user name and password before it lets you through, and it accepts the host's system user accounts - the same credentials you use for SSH. The interface itself is never exposed directly; the web server reaches it over localhost.
Note
That login is the web server's, not the search engine's. OpenSearch Dashboards has no user
accounts of its own unless you turn user management on, which is only available in the
Source (YAML) view (opensearch_dashboards_usermanagement).
Turn it on when you need per-user access inside the dashboards rather than one shared door.
Related
- Applications - per-application PHP, runtimes and proxying.
- Advanced settings and Backups & restore.
- Configuration recipes - including a separate database server.
- Hosts