Deprecated build runtimes and what the warnings mean
If you arrived here from a banner in your build log, this page explains what the message means and what (if anything) you need to do. The short version: your builds will continue to run, and no removals have been scheduled. We've started flagging a number of runtime series that are past upstream end-of-life so you have time to plan a move before anything changes.
What the banner means
There are three different banners you might see at the top of a build log. Each one is described below.
Deprecation notice
You'll see this banner when your project is pinned to a runtime series (for example, PHP 7.4 or Node 16) that is past upstream end-of-life but is still installed in our build image.
Build outcome: runs exactly as before. Nothing has changed about the runtime itself.
What to do: plan a move to a supported series when it's convenient. There is no removal date for these runtimes today; we've simply started warning so the upgrade isn't a surprise later. If you're already on the newest series for that runtime and still seeing this message, please get in touch -- we'd like to know.
Runtime version not installed
You'll see this banner when an environment variable in your build configuration points to a runtime path that doesn't exist in the build image -- usually a typo (PHP8.2 instead of PHP_8_2, for example), or a patch version we never bundled.
Build outcome: the build continues using the default version for that runtime. Whatever your build command actually invoked may not be the version you meant.
What to do: check the environment variable name and value against the language versions API reference. If you want to pin a specific series, the project configuration UI is the cleanest way to do it (see below).
Runtime version not available
You'll see this banner when your project configuration selects a runtime series that the build image's manifest no longer includes. This is the banner you'd see if a series were ever removed from the build image -- it doesn't apply to anything that's currently shipping.
Build outcome: the build continues using the default version for that runtime. Behaviour may differ from your previous builds.
What to do: update your project configuration to a supported series. If a series your project relies on has been removed and the default isn't a workable substitute, contact our support team and we'll help you find a path forward.
How to change the runtime version your project uses
Runtime versions are set per-project under Build Pipeline -> Build Configuration in the DeployHQ dashboard. Each of the supported runtimes (Ruby, PHP, Node.js, Python, Go, Java, .NET, Composer) has its own dropdown listing the available series. Save the page and the next build will use the versions you've selected. For a full walkthrough, see Configure custom build environments.
If you can't find the configuration screen, or you'd like help choosing a target version for an existing project, contact our support team and we'll walk you through it.
A few specifics worth knowing:
- Node.js -- the version is set through the UI dropdown or a
NODE_VERSIONenvironment variable in your build configuration..nvmrcfiles in your repository are not read by the build pipeline -- DeployHQ temporarily renames them during a build so they cannot conflict with the configured version. See Using .nvmrc files with Build Pipeline for the full explanation and the supported alternatives. - .NET -- if your repository contains a
global.jsonat the root, the matching series is selected automatically. See Building .NET applications for details. - PHP and Composer -- these are configured independently. The Composer binary you pick runs against the PHP series you've selected.
Runtime series that have been flagged
These series are past their upstream end-of-life dates. They are still installed and still work today. They are flagged so you can plan ahead.
| Runtime | Series flagged as past end-of-life |
|---|---|
| Ruby | 2.4, 2.5, 2.6, 2.7, 3.0 |
| PHP | 7.0, 7.1, 7.2, 7.3, 7.4, 8.0 |
| Node.js | 8, 9, 10, 12, 14, 15, 16, 17, 19, 21, 23 |
| Python | 2.7, 3.5, 3.6, 3.7, 3.8, 3.9 |
| Go | 1.10 through 1.21 |
| Java | 10, 22, 23, 24 |
| .NET | 3.1, 5.0, 6.0, 7.0 |
| Composer | 1.x |
| PhantomJS | 2.1 |
Java 8 is intentionally kept on the supported list -- Oracle's commercial LTS for Java 8 is still active and a meaningful number of projects rely on it.
Frequently asked questions
Will my build break?
No. Every series in the table above is still installed in the build image and behaves exactly as it did before. The banners are informational -- your build runs, and the runtime version is unchanged.
When will these versions be removed?
No removal is scheduled. Every series in the table above is still installed in the build image and will keep running as it did before. The banners are informational so you have time to plan a move before anything changes.
If a removal is ever scheduled, your project configuration would fall back to the default version for that runtime -- you'd see the Runtime version not available banner described above. We will update this article ahead of any scheduled removal.
Why are some non-EOL versions on the list?
A couple of things to flag:
- Node.js odd-numbered majors (9, 11, 13, 15, 17, 19, 21, 23) are not LTS releases. They each had roughly a six-month support window from the Node project even while they were current. For anything beyond throwaway experimentation, an LTS major (the even numbers) is the safer choice, so the EOL'd odds appear on this list too.
- Java non-LTS feature releases (10, 22, 23, 24) are six-month-cycle releases that don't receive long-term updates from the upstream OpenJDK project. Java 8, 11, 17, and 21 are the LTS lines.
How do I know which version my project is currently using?
Two places to check:
- The build log -- the first lines of build output for each runtime print the version that was selected.
- Build Pipeline -> Build Configuration in the dashboard -- the dropdowns show what's currently set for the project.
I'm pinning via environment variables in my build commands. Does that change anything?
No. Environment variables that select runtime versions (for example PHP_VERSION, NODE_VERSION) still work the same way. If the environment variable points to a series that's been flagged, you'll see the Deprecation notice banner just as you would with the UI selector.
Need help?
If you're unsure which version to move to, or your project needs a specific patch release that isn't in the dropdown, please get in touch -- we'd rather help you plan an upgrade than have you discover a problem during a deployment.