Hosting
This section covers where your site runs. It's for the lead or DevOps engineer who hosts a project built from Vortex, and for anyone choosing where to host it. Each provider page explains what the integration does and how Vortex detects the environment. It also covers the routine operations on that platform: fetching and copying databases, purging caches and running custom commands.
Vortex integrates with 2 hosting providers:
For any other provider, choose Other or None at the installer's
Hosting provider prompt. With either answer, the installer leaves out
the Acquia and Lagoon integration files, such as their settings files, the
Acquia hooks and .lagoon.yml. The deployment type then defaults to
webhook. The roadmap lists the hosting
integrations under consideration.
The Deployment section covers how code gets to a provider: deployment types, triggers and skip rules.
Hosting providers vs environments
Hosting providers are the platforms where your environments run. They can be cloud-based or on-premises. They provide the infrastructure for the web server, the database and the other services your site needs.
Environments are the contained bundles of those services that run your website. Each one is a stage of your deployment and release lifecycle, from local development to production. A single hosting provider can run several of them.
Hosting providers typically offer DEV, STAGE and PROD environments. Some also run short-lived environments for a single change, called "preview", "on-demand" or "feature" environments. They let you test a change in isolation before you merge it into the main codebase.
Vortex detects the environment type at runtime and stores it in
$settings['environment'], so your settings can change the site's behavior
for each type.