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 a host for one. Each provider page explains what the integration does and how Vortex detects the environment. It also covers the routine operations on that platform, from fetching and copying databases to 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. The 2 answers give the same result: Vortex
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.
How code gets to a provider (deployment types, triggers, and skip rules) lives in the Deployment section.
Hosting providers vs environments
Hosting providers are the platforms where your environments run. They can be cloud-based or on-premises, and they provide the infrastructure to run the webserver, database, and other services your site needs.
Environments are the contained bundles of those infrastructure services that run your website. Each one represents a logical stage of your deployment and release lifecycle, from local development to production, and a single hosting provider can run several of them.
Hosting providers typically offer DEV, STAGE, and PROD environments. Some also support short-lived ephemeral environments, called "preview", "on-demand", or "feature" environments. They let you test new features or changes in isolation before merging them 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.