We're moving on from legacy.
Important Information On Legacy Images
The Reaper Sharpens Up 
Important Information On Legacy Images 
Your Account, All In One Place 
Last Updated: November 6, 2026
If your .probo.yaml file has an image: line in it, this post is for you. The legacy build images that tag points to will be unsupported after December 31, 2026, and the image tag itself will stop working after February 27, 2027. In between, the tag will still be honored, but enhancements to Probo.CI may break builds that depend on it at any time. The change you need to make is small, usually three lines, and you can make it today.
For most of Probo.CI’s history, you chose your build environment by naming a Docker image directly in your .probo.yaml file:
1 | image: proboci/ubuntu:22.04-php8.1 |
Each of these images was a complete, pre-baked environment: one Ubuntu release, one PHP version, Apache, and whatever versions of MariaDB, Solr, Node.js, Varnish, Redis and Memcached were current when the image was built. The only legacy images still available today are the Ubuntu 22.04 series:
proboci/ubuntu:22.04-php7.4 through proboci/ubuntu:22.04-php8.5The older proboci/ubuntu:18.04 and proboci/ubuntu:20.04 series, the proboci/alpine images, and the proboci/ubuntu-16.04-lamp and proboci/ubuntu-14.04-lamp tags have already been removed. If your configuration still names one of those, the migration below applies to you just the same.
This approach served us for a long time, but it had a real cost. You had to know an arcane image name to get the PHP version you wanted, and you got whatever database and Solr version happened to ship with it. Needed PHP 8.1 with MySQL 5.7? There was no image for that. Every new combination meant another image for us to build, publish and keep patched, and the matrix only grew.
As we announced in March, we replaced this with configurable environments. Every build now starts from a current Ubuntu 24.04 image matched to your PHP, .NET, Node.js or Python version, and the database, Solr and Node.js you ask for are installed at build time. The legacy images have not been updated since then and will not be updated again.
Here is the timeline:
image tag is still honored, but the legacy images are unsupported. Enhancements to Probo.CI during this period may break builds that depend on them.image tag is ignored. Builds that still rely on it will be configured as if the line were not there.There is an important wrinkle in how the image tag works that makes waiting risky. Today, when image is present, it overrides every other root level tag except assets. Most configurations that use image therefore have no type, php or database tags at all, because those were never read. When the image tag is ignored, such a file has no environment definition left. Probo.CI will fall back to its static site image: no PHP, no database. Your builds will not degrade gracefully. They will fail.
Migrating now means your configuration is already correct before support ends, and you have weeks to confirm your builds pass on the new environment rather than discovering a problem when an update lands in the new year.
Open the .probo.yaml file at the root of your repository and look for a root level image: key. It is almost always the first line. Make note of the Ubuntu release and PHP version in the tag. In proboci/ubuntu:22.04-php8.1, that is Ubuntu 22.04 and PHP 8.1.
Delete the image line and add three tags in its place. The type tag tells Probo.CI what kind of application you are building, php sets the PHP version, and database sets the database engine and version.
The 22.04 legacy images shipped MariaDB 10.6, the server from that release’s package archive. That exact version is not offered under the new format, so pick the closest supported one. For most sites that is mariadb:10.11, the nearest release in the same 10.x line:
| Legacy image | Replace with |
|---|---|
proboci/ubuntu:22.04-phpX.Y | type: lamp, php: X.Y, database: mariadb:10.11 |
The same replacement applies if your file still names one of the removed 18.04, 20.04 or Alpine images. Those shipped older MariaDB releases, and mariadb:10.11 is the closest match for them too.
Even if your application and your dump files call it “MySQL”, a build on a legacy image was talking to MariaDB, and mariadb:10.11 is the drop-in choice. You are not locked into it, though. If production runs MySQL 8.0 or 8.4, or a newer MariaDB such as 11.4, this is a good moment to match production instead.
Here is a typical before and after for a Drupal site that was on the 22.04 PHP 8.1 image:
Before
1 2 3 4 5 6 7 8 9 10 | image: proboci/ubuntu:22.04-php8.1 assets: - dev.sql.gz steps: - name: Site Setup plugin: Drupal database: dev.sql.gz databaseGzipped: true |
After
1 2 3 4 5 6 7 8 9 10 11 12 | type: lamp php: 8.1 database: mariadb:10.11 assets: - dev.sql.gz steps: - name: Site Setup plugin: Drupal database: dev.sql.gz databaseGzipped: true |
Your assets and steps do not change. Only the environment definition at the top of the file does.
Legacy images came with a Solr server pre-installed and some builds simply started it in a step. Solr is now installed on request, so if your site searches with Solr you need to say so. Upload your core configuration as an asset and add a solr block:
1 2 3 4 5 6 7 8 9 10 11 12 13 | type: lamp php: 8.1 database: mariadb:10.11 solr: version: 9 name: my-core core_archive: solr9.tar.gz core_folder: solr9 compression: gzip assets: - dev.sql.gz - solr9.tar.gz |
Solr 5 through 9 are available. See Solr Configuration for how to package your core.
Each legacy image shipped a single, fixed Node.js version, and theme builds quietly depended on it. The new images ship a current Node.js plus nvm. If your SASS or JavaScript build needs a specific version, set it at the root of the file:
1 | nodejs: 18 |
You can also switch versions inside an individual step with nvm install <version>. The Node.js documentation covers both approaches.
Composer, Drush, WP-CLI, Redis, Memcached and ImageMagick are all still present in the PHP images, along with the full set of common PHP extensions. Two things are worth a look:
apt install -y varnish in a Script step.apt install behaves as it always has.Paste your updated file into the YAML checker to catch indentation and syntax mistakes before you commit. Then push the change on a branch and open a pull request. Watch the Environment status on the build. If it reports “Environment ready”, your new configuration is working. If a later step fails, the build log in the Portal will show you exactly what happened.
If you set type: lamp and leave out php, you get PHP 8.3. If you leave out database, you get MariaDB 11.4. The database default is at least in the same family your legacy image used, but PHP 8.3 is very likely not the version it ran. Set both tags explicitly so the environment is exactly what you intend, and so it stays that way if the defaults change later.
nodejs or nvmOne note on MySQL 5.7. It is end of life upstream and we provide it for applications that genuinely depend on it. It is a custom build that works on current Ubuntu and it consumes roughly 2 GB of quota per build, so if you can move to 8.0 or 8.4, you should.
The full list, including .NET, Python and Node.js application types, lives on the Environment Setup page.
Complete working examples for Drupal, Drupal 7, WordPress, Backdrop, Joomla, Laravel, Symfony and more are in our demonstration repositories on GitHub, GitLab and Bitbucket. Each one is a real .probo.yaml in the new format that you can copy from.
If your build does something unusual and you are not sure how to express it without the image tag, contact support with your current .probo.yaml file and we will help you translate it. Please do not wait until the last week of December to ask.
Your first month is on us. When you sign up for a Probo.CI, every new account starts with a full month free on any of our plans. For more information on how to get started, click here.
LEARN MORE ABOUT PROBO.CI'S PRICING