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.
Vortex integrates with 2 hosting providers:
For any other provider, choose Other or None at the Hosting
provider prompt of the Vortex CLI. The 2 answers give
the same result: Vortex leaves out the Acquia and Lagoon integration
files, such as the Acquia hooks/ directory, .lagoon.yml, and the Lagoon
Drush alias. 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.