A hosting decision record
This page is for project managers, architects and IT leads in public bodies who must write down how a site is hosted and why, for a change advisory board, an audit, a procurement file or the team that takes over later. It gives a decision record template with every choice Exponential asks for, the options the sources support and where each is explained. Fill it in once per site and keep it with the site's documentation. The hosting companies' version is in Choosing a web server and Choosing a hosting model.
Contents
- How to use the template
- The template
- Facts to collect from the running site
- Keeping it current
- Checklist
How to use the template
- One record per site (or per installation serving several sites).
- Each row: the decision, the reason, and the risk you accept. "We chose X because our database team runs X" is a perfectly good reason.
- Write team names, not people's names, so the record does not age with staff changes.
- Name figures only when you measured or decided them; mark assumptions as "example assumption".
The template
| Decision | Options in the sources | Our choice | Reason | Accepted risk | Read |
|---|---|---|---|---|---|
| Hosting location and model | own data center; government or sovereign cloud; virtual machine; containers; Kubernetes (tier 3); managed hosting | On-premise hosting, Government and sovereign cloud hosting | |||
| Operating system | tier 1 or 2 recommended | Operating system support | |||
| PHP version | 8.0 or later, Velocity included | PHP versions and extensions | |||
| Database | 1. SQLite 3 · 2. PostgreSQL · 3. MongoDB · 4. MariaDB · 5. Oracle · 6. MySQL | Choosing a database in the official order | |||
| Web server or engine | Velocity (recommended); FrankenPHP; Apache or nginx with PHP-FPM | Web server choices | |||
| TLS termination | the engine; the web server; a central proxy | TLS and HTTPS | |||
| Administration access | own host name; network restriction; VPN | Separating the administration from the public site | |||
| Environments | development, test, production with EXP_ENV | Environments for development, test and production | |||
| Configuration control | version control; ManagedByDeployment | Configuration under version control | |||
| Number of web servers | one; several behind a load balancer | High availability overview | |||
| Caches in front of PHP | Velocity response cache; HTTP cache; static cache (ships off) | Velocity response cache and HTTP cache | |||
| Backups | what, how often, where, how long | What to back up | |||
| Recovery objectives | RPO and RTO as decided by the organization | RPO and RTO as decisions | |||
| sendmail, SMTP, file (test) | Mail delivery | ||||
| Search | built-in; Solr through ezfind | Search backends | |||
| Data location | inventory of every place data is kept | Data location and what is stored where | |||
| Active extensions contacting third parties | none, or listed and justified | Privacy standards | |||
| Monitoring | external uptime check; internal status commands | Health checks and uptime |
Facts to collect from the running site
Attach these outputs to the record; they show what really runs, not what was planned:
php -v | head -1
./console exp:velocity ext check --allow-root-user
./console exp:system:info --json --allow-root-user > system-info.json
grep -rn "DatabaseImplementation" settings/override settings/siteaccess/*/site.ini.append.php
./console exp:cache status --allow-root-userexp:system:info prints the facts and health checks of Setup > System information
(Sizing memory, CPU and disk). Review the JSON before you file
it outside the IT team; it describes your server in detail. The page's support report is built to leave out what
should not be shared (System information).
Keeping it current
Update the record with every change that touches a row: a new PHP version, a database move, a second web server, a new extension that contacts a third party. A change request that does not mention the record is a hint that the record is out of date. Review it at least once a year, together with the recovery decisions and a restore test.
Checklist
- To do: Every row has a choice, a reason and an accepted risk.
- To do: The facts from the running site are attached and match the choices.
- To do: The record names teams, not people.
- To do: It is filed where the change board and auditors find it.
- To do: A review date is set.
Related pages
- Hosting index of this folder
- Designing hosting plans for a provider's view of the same choices
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.