Software stacks

A stack is the set of services an environment runs. Some of it arrives with your project type and some of it you pick.

#What arrives with the project type

You choose a project type — Drupal, Laravel, WordPress, PHP, Go or Node.js — and the web bundle comes with it, whole:

• the runtime for that language: PHP-FPM, a Node.js server, or your Go binary
• Nginx, serving static files and passing requests to PHP — PHP projects only, because a Node or Go application is its own web server
• a queue worker container — Laravel only, where the framework has one
• OpenSMTPD, so the application can send mail

The schedule comes with it too, but not as a container. Your framework's cron runs on the machine itself, against the application that is already running there — see vallic.yaml for declaring your own jobs.

These are not tick-boxes. A stack missing any of them is not a working site, and asking somebody to tick five boxes that must all be ticked is asking them to get it wrong. They run on the machines you already pay for, at no extra charge.

Every PHP project — Drupal, Laravel, WordPress or plain PHP — runs on the same PHP-FPM image. What differs between them is not the image but what the platform sets around it: the Nginx configuration, the document root, the default cron and the directories kept between releases.

#What you choose

For Drupal, Laravel and WordPress two are required, because there is no sensible default:

• A database. MariaDB, MySQL or PostgreSQL. Some applications want one, some another, and guessing wrong is a migration. Choosing MySQL or PostgreSQL replaces MariaDB rather than adding to it — you never run two.
• A cache. Redis, Valkey or Memcached — one of them.

A PHP, Go or Node.js project needs neither, and gets either only by asking.

Your database, its user and its password are created for that environment alone, and your application is handed them in its environment file. You never set them and you never need to know them.

The rest are optional and cost a machine or a container each:

• Search — Solr or Meilisearch, one at a time
• Queue — RabbitMQ, when jobs need a real broker rather than the database
• Proxy — Varnish, in front of the web servers
• Build tools — Node.js for builds, for a PHP site whose theme or assets need npm. It runs only during a build, never beside the site

#Everything, with versions

The version in bold is what you get if you do not choose one. This table is built from the same catalogue the configurator reads, so it is never out of date.

Each has its own page with the full version list, which of them are on their way out, and the variables you may set on it. They are the pages under Software in the sidebar.

#Changing a version

Versions are per environment, so a runtime or database upgrade is something you try on staging first. Staging is an environment you add to a project, on either plan — see Environments. Without one, the first environment to run a new version is production.

Data on disk survives a container image changing — the database keeps its files outside the container precisely so that upgrading the image is not a restore from backup. Downgrading is a different matter: a database that has opened its files with a newer version will usually refuse an older one, so treat a major version change as one-way unless you have checked otherwise.

#Next

Environments covers where these versions are set.