Each site can now have its own PHP, Python, SQLite and MariaDB
We can now turn PHP, Python, SQLite and MariaDB on or off for each site we host, one at a time. The server sets up whatever a site needs, your app is given its database details, and a database that is turned off is archived first instead of deleted. This release also covers new site names with a certificate right away, keeps a live site online when a settings change fails, and fixes DNS text records that could not be published.
Site features
-
New
PHP or Python, chosen per site
Each site runs either PHP or Python as its app engine, one or the other. A PHP site runs in its own pool, as the site's own user, on the PHP version you choose. A Python site runs a standard web app, such as Flask or Django, from its own private environment, with the packages listed in your requirements file installed for you. Tell us which your site needs and we switch it on.
Your site -
New
A database when your site needs one
A site can have SQLite, MariaDB, both or neither. SQLite gets a private data folder outside the public part of your site. MariaDB gets a database of the site's own, with its own database user. Sites that already have a database keep it.
Databases -
New
The server sets up what your site switches on
When something is turned on for your site, the server installs and configures it the next time it updates your site -- there is nothing for you to install. If a server cannot run what one site asks for, that site keeps running as it is and every other site on the server keeps updating.
Your site -
New
Your app is handed its database details
When a database is on, your app receives its connection details as environment variables, in PHP and Python alike: DATABASE_URL, DB_HOST, DB_NAME, DB_USER and DB_PASSWORD for MariaDB, and SQLITE_PATH for SQLite. There is no password to copy into a settings file.
Databases -
New
Turning a database off archives it first
Before a database is removed from a site, the server saves a copy of its data and keeps it for a year. If that copy cannot be made, nothing is removed.
Databases -
New
Python sites rebuild themselves after a server upgrade
When the server moves to a newer Python, a Python site's environment no longer matches it. The server now notices, rebuilds the environment and reinstalls your packages the next time it updates your site, instead of leaving the app broken.
Your site -
Improved
PHP 8.4 on our newest servers
A site can now choose PHP 8.4, the version our newest servers carry. If you ask for a version the site's server cannot run, it is caught before anything on your site changes.
Your site
Certificates, DNS & reliability
-
Fixed
A name added to a live site is covered by its certificate right away
When a live site gained another name, such as an alias or a redirect, its security certificate was not updated until its next renewal, so visitors to the new name could see a browser warning for up to two months. The certificate is now reissued as soon as the site has a name it does not cover.
Certificates -
Fixed
A settings change that fails no longer takes a live site offline
If new web server settings for a live site failed their check, the site could be switched off and go dark at the next reload. The site's previous settings are now put back and it stays online. The web server is also only restarted once its new settings pass the same check.
Your site -
Fixed
Long DNS text records are published correctly
A TXT record, such as an email signing key, could be written out wrong if it was long and had a quote or backslash in an unlucky spot, was pasted with a line break in it, or used characters outside plain English. One such record could hold up other DNS changes until it was corrected. These records are now published as entered.
DNS