For years, developers have relied on JPEG, PNG, WebP, and more recently AVIF to balance image quality, file size, and browser compatibility.
With JPEG XL decoding support introduced in Chrome 155, another modern image format becomes a realistic option for web development. Google announced the integration on October 6, 2026, highlighting improved compression, lossless capabilities, high dynamic range support, and a new Rust-based decoder.
However, the arrival of another image format does not mean developers should immediately replace their existing image pipelines. The practical question is where JPEG XL provides measurable benefits and how it can be introduced without compromising compatibility.
JPEG XL is an image format standardized as ISO/IEC 18181. It was designed to address limitations of older image formats while supporting both lossy and lossless compression.
Unlike traditional JPEG, JPEG XL supports transparency, animation, high bit depths, wide color gamuts, and high dynamic range images.
One particularly interesting capability is lossless JPEG transcoding. Existing JPEG images can be converted into a JPEG XL representation while preserving the information needed to reconstruct the original JPEG file exactly.
For organizations maintaining large photographic archives, this can provide a migration path that preserves existing image assets while potentially reducing storage requirements.
It is important to distinguish this capability from ordinary lossy re-encoding. Lossless JPEG transcoding preserves the original JPEG bitstream, while re-encoding an image with different quality settings may alter its visual content.
Browser support is one of the main factors determining whether a new image format becomes practical for general websites.
Google’s addition of JPEG XL decoding in Chrome 155 substantially broadens its potential audience. The Chrome team reports that JPEG XL can offer compression improvements of roughly 30% to 50% compared with JPEG in relevant scenarios.
That figure should not be treated as a universal performance guarantee. Compression efficiency depends on the image content, encoding settings, quality targets, and comparison methodology.
Google also recommends evaluating JPEG XL alongside AVIF rather than assuming one format will consistently outperform the other.
JPEG XL may be particularly interesting for high-fidelity photographic content, lossless compression, and use cases benefiting from progressive decoding.
The simplest adoption strategy is progressive enhancement. Instead of replacing an existing JPEG or AVIF image, developers can provide multiple formats and allow the browser to select a supported version.
The HTML <picture> element provides this capability without JavaScript.
<picture>
<source
srcset="/images/article.jxl"
type="image/jxl"
>
<source
srcset="/images/article.avif"
type="image/avif"
>
<img
src="/images/article.jpg"
alt="A detailed architectural photograph"
width="1200"
height="800"
decoding="async"
>
</picture>In this example, a browser supporting JPEG XL can select the first source. Other browsers may select AVIF or fall back to the JPEG image.
The type attribute helps the browser determine whether it supports the format before requesting the corresponding image.
The fallback image also ensures that browsers without support for the newer formats can still display the content.
Developers should retain appropriate width and height attributes to reserve layout space and reduce unexpected content movement during loading.
Both JPEG XL and AVIF support features that traditional JPEG lacks. These include high-quality compression, transparency, and support for modern image characteristics.
However, their underlying technologies and practical tradeoffs differ.
AVIF is based on the AV1 video codec. It is already widely used for modern web images and can provide excellent compression, particularly at lower bitrates.
JPEG XL was designed specifically for image coding and includes features such as fine-grained progressive decoding and lossless JPEG transcoding.
For a photography website maintaining a large collection of existing JPEG images, JPEG XL’s transcoding capabilities may be attractive.
For an application already generating AVIF images with satisfactory quality and file sizes, the additional complexity of another format may not immediately justify the change.
The appropriate choice depends on real content and measured results rather than theoretical compression ratios alone.
Another notable aspect of Chrome’s implementation is the choice of decoder.
Instead of integrating the existing C++ reference implementation directly, the Chrome team adopted jxl-rs, a JPEG XL decoder implemented in Rust.
Image decoders process complex binary files that may originate from untrusted sources. Vulnerabilities in this area can expose browsers to memory corruption and other security problems.
Rust provides memory-safety guarantees that help reduce entire classes of vulnerabilities. The Chrome team also invested in SIMD optimizations to improve decoding performance across different hardware platforms.
This does not mean every JPEG XL decoder is automatically secure, or that Rust eliminates all possible implementation bugs.
It does, however, illustrate how browser vendors increasingly consider memory safety a fundamental requirement when introducing code that processes untrusted data.
For websites using WordPress or another content management system, browser support is only one part of the implementation.
The server must also be capable of accepting or generating JPEG XL files, storing them, and serving them with the correct MIME type: image/jxl.
Image libraries, thumbnail generators, content delivery networks, and media optimization plugins may require updates before JPEG XL can be integrated into an existing workflow.
Developers should verify the capabilities of their actual hosting environment rather than assuming that new browser support automatically means the entire publishing stack supports the format.
For smaller websites, generating JPEG XL alternatives only for selected high-resolution images may be more practical than converting the entire media library.
Before introducing JPEG XL widely, developers should compare representative images across JPEG, AVIF, WebP, and JPEG XL at equivalent perceptual quality.
Useful measurements include final file size, encoding time, decoding behavior, visual quality, and actual page-loading performance.
For large websites, a format that produces slightly smaller files but significantly complicates image generation or caching may not provide an attractive operational tradeoff.
Similarly, saving bandwidth does not automatically guarantee an improvement in Largest Contentful Paint. Network conditions, image dimensions, preload behavior, decoding time, and rendering priorities all influence the final result.
A controlled experiment using real website images and representative devices provides considerably more useful information than relying on compression benchmarks alone.
JPEG XL’s arrival in Chrome represents a meaningful development for modern web image delivery.
It expands the options available to developers, particularly for high-quality photographic content, lossless workflows, and applications that can benefit from progressive image decoding.
Nevertheless, adopting a new image format requires more than browser support. Compatibility, content-generation tools, hosting infrastructure, and actual performance gains all need to be evaluated.
For most web applications, the sensible approach is to experiment with JPEG XL as an additional format while retaining reliable alternatives. The format offers interesting capabilities, but the decision to adopt it should ultimately be based on measurable benefits.
Traditionally, this involves private properties, constructors, getters, setters, and sometimes additional validation classes. These approaches remain useful, but they can introduce considerable repetitive code for relatively simple objects.
PHP 8.4 introduced property hooks and asymmetric property visibility, two language features that offer another way to organize data objects. Together, they allow developers to define how a property accepts values while controlling who can modify it.
Let’s examine how these features work through a practical contact-profile example, including situations where they should not replace conventional methods or immutable objects.
Consider a class representing a contact profile. Its name must not be empty, its email address must be valid, and its age must fall within an accepted range.
A conventional implementation might declare private properties and expose a separate setter for each field. The setters then normalize or validate the incoming values before storing them.
Nothing is fundamentally wrong with this design. It protects the object’s internal state and provides an explicit interface. However, for a class with many fields, maintaining matching getter and setter methods can become tedious.
Property hooks address part of this problem by letting the property declaration itself define custom read and write behavior.
PHP 8.4 supports two property hooks: get and set. A getter hook customizes how the value is read, while a setter hook intercepts assignments.
For example, the following property automatically trims whitespace before storing a contact name:
<?php
class Contact
{
public string $name {
set(string $value) {
$this->name = trim($value);
}
}
}
$contact = new Contact();
$contact->name = ' Ada Lovelace ';
echo $contact->name;
// Ada LovelaceThe property remains backed by an actual stored value. Referencing $this->name inside its own setter does not recursively invoke the same hook.
This makes it possible to implement normalization and validation without introducing a separate setter method.
Let’s build a more complete example. Our profile contains a name, an email address, and an age. Once constructed, these fields should remain readable from outside the class but should not be directly writable.
We can combine property hooks with PHP 8.4’s asymmetric visibility syntax, public private(set):
<?php
declare(strict_types=1);
final class ContactProfile
{
public private(set) string $name {
set(string $value) {
$value = trim($value);
if ($value === '') {
throw new InvalidArgumentException(
'Name is required'
);
}
$this->name = $value;
}
}
public private(set) string $email {
set(string $value) {
$value = strtolower(trim($value));
if (
filter_var(
$value,
FILTER_VALIDATE_EMAIL
) === false
) {
throw new InvalidArgumentException(
'Invalid email'
);
}
$this->email = $value;
}
}
public private(set) int $age {
set(int $value) {
if ($value < 18 || $value > 120) {
throw new InvalidArgumentException(
'Age out of range'
);
}
$this->age = $value;
}
}
public string $label {
get => $this->name
. ' <'
. $this->email
. '>';
}
public function __construct(
string $name,
string $email,
int $age
) {
$this->name = $name;
$this->email = $email;
$this->age = $age;
}
}
$contact = new ContactProfile(
' Ada Lovelace ',
' ADA@EXAMPLE.COM ',
28
);
echo $contact->name . PHP_EOL;
echo $contact->email . PHP_EOL;
echo $contact->label . PHP_EOL;The output is:
Ada Lovelace
ada@example.com
Ada Lovelace <ada@example.com>The name and email address are normalized during assignment. Invalid input causes an exception before the corresponding property receives the new value.
The email normalization shown here is deliberately simple. Applications dealing with internationalized addresses or more complex email requirements may need more specialized handling.
Notice the public private(set) declarations. These allow the properties to be read publicly while restricting assignments to the defining class.
As a result, this operation is allowed:
echo $contact->email;But this assignment is prohibited:
$contact->email = 'other@example.com';
// Error: property cannot be modified hereImportantly, setter hooks do not replace access-control rules. PHP checks whether a write is permitted, and an external assignment cannot bypass a private setter simply because the property declares a hook.
With a final class and no public mutation methods, this design provides a straightforward way to expose a stable, read-only interface after construction.
The label property in our example introduces another useful capability: virtual properties.
Unlike name or email, the label does not have its own stored value. Instead, its getter calculates the result from existing properties whenever it is accessed.
Before property hooks, developers would normally expose this behavior through a method such as getLabel(). With PHP 8.4, a computed value can be represented directly as a typed property.
This can be convenient for derived information such as formatted names, display labels, calculated totals, or read-only projections of an object’s existing state.
However, virtual properties should remain inexpensive and predictable. Hiding database queries, network requests, or other significant side effects behind an apparently simple property read can make application behavior difficult to understand.
One important limitation is that property hooks are not compatible with readonly properties.
Developers designing immutable domain objects should therefore distinguish between the two approaches. A readonly object provides language-enforced restrictions on property modification, while property hooks allow custom access behavior.
Asymmetric visibility can restrict writes from outside a class, but it does not automatically create the same guarantees as a readonly class. Internal methods can still modify writable properties.
Another consideration involves arrays. Indirect modifications such as changing an individual array element may not behave as expected with hooked properties, because the operation involves references that can bypass normal setter semantics.
Property hooks are most useful when a class needs predictable property-level normalization, simple validation, or derived values that naturally belong to the object.
They are less appropriate when validation depends on several fields at once, requires external services, or involves complex business workflows. Those responsibilities are often clearer in constructors, factories, or dedicated domain services.
For existing applications, there is little reason to replace every getter and setter immediately. Introducing hooks in small, well-tested classes is a more reasonable approach.
Property hooks are available starting with PHP 8.4. Applications that still support PHP 8.3 or earlier must retain conventional methods or another compatible implementation.
PHP 8.4 property hooks offer a useful improvement to object-oriented programming by moving straightforward property behavior closer to its declaration.
Combined with asymmetric visibility, they can reduce repetitive code while preserving clear rules about how data is accepted and exposed.
The important design question is not whether getters and setters should disappear, but which responsibilities genuinely belong to a property. Used selectively, property hooks can make PHP data models smaller and easier to maintain without sacrificing clarity.
The difference is the agreement. A good maintenance plan tells the client what is being protected, what the developer will do, and what happens when something falls outside the plan. It gives both sides a practical way to manage the application after launch.
“Basic,” “Pro,” and “Premium” packages are easy to put on a sales page, but the names alone do not explain the work. A small marketing site and a customer portal may both use PHP, yet their maintenance needs can be very different.
Before proposing a plan, review the application’s components: its framework or content management system, dependencies, hosting, database, integrations, backup process, traffic patterns, and business importance. Ask who has access and whether anyone currently monitors failures.
That assessment may reveal work that needs to happen before a recurring plan begins. An unsupported dependency, missing backup, or undocumented deployment process should not quietly become an unlimited obligation inside a monthly fee. Offer a separate initial remediation project where appropriate.
Clients need to know what they are buying. Instead of promising “complete maintenance,” list the activities you will perform and how often. Depending on the application, a plan might include:
Be precise about the limits. An uptime monitor can alert you to a failure, but it does not guarantee that every problem will be detected. A backup is useful only if it can be restored, so explain who tests recovery and how frequently. If the client controls hosting or another vendor manages part of the system, identify those responsibilities too.
A common source of disagreement is the phrase “24-hour support.” Does it mean the developer will acknowledge a message within 24 hours, begin investigating, or completely fix the problem? Those are three different promises.
Define the support channel, business hours, and expected response time for each priority level. For example, a critical production outage might receive an initial response within four business hours, while a minor content request might be reviewed within two business days. These are examples, not universal targets: choose commitments you can actually meet.
A response target is not a guarantee of resolution. A third-party outage, a difficult data recovery, or an issue in unsupported code may take longer and require a separate estimate. Explain how the client will be kept informed when that happens.
A maintenance fee must cover more than the visible minutes spent installing updates. It should account for monitoring, administration, client communication, routine checks, tools, and the capacity reserved to respond when something goes wrong.
As an illustrative starting point, imagine a plan that requires two hours of routine work per month, plus half an hour for reporting and administration. At an internal target rate of $100 per hour, that is $250 before software costs, contingency, taxes, and profit. The final price should reflect the application’s complexity and the obligations in the agreement.
Track actual time and incidents for the first few months. If one application consistently consumes more effort than expected, discuss a revised plan or a separate project to reduce its maintenance burden. A low monthly fee is not a bargain if it prevents the developer from responding reliably.
New features, redesigns, content production, migrations, and major upgrades often belong outside routine maintenance. State that explicitly and explain how they will be quoted. You might offer an hourly rate, a prepaid block of hours, or a separate fixed-price proposal after assessing the request.
A useful plan also explains what happens when the relationship ends: how access is transferred, what documentation is supplied, and when monitoring stops. The goal is a clean handoff rather than uncertainty over who is responsible for a live application.
Recurring revenue is attractive, but reliability is the real product. A clear maintenance plan gives the client confidence in what happens after launch and gives the freelancer a service that can be delivered sustainably.
]]>But open source is not, by itself, a business model.
This distinction matters for PHP developers, web agencies, and small software companies that create frameworks, libraries, developer tools, or self-hosted applications. Publishing code can create attention. It does not automatically create recurring revenue, support capacity, or a sustainable team.
The most common commercial mistake is trying to charge for the same thing that made the project attractive in the first place: access to the source code. In many open-source communities, that approach creates friction without solving the underlying problem.
A stronger question is: what do organisations pay for once they decide this software matters to them?
They may pay for reduced operational risk, managed hosting, reliable upgrades, security assurance, compliance controls, priority support, integrations, deployment guidance, training, or a service-level commitment. These are not artificial limitations added to punish self-hosters. They are real business needs with real operating costs.
Small teams often try to monetise through everything at once: donations, consulting, paid plugins, training, hosting, enterprise licensing, sponsorship, and merchandise. Diversification can help later, but too many paths at the start usually create confusion.
Choose one primary promise that matches the product and the buyer. A developer analytics tool might lead with hosted reliability. A self-hosted PHP application might lead with enterprise support and regulated deployment. A framework-adjacent product might lead with training and implementation services.
The commercial offer must be easy to explain in one sentence. If a prospective customer cannot tell why they should pay, they will delay the decision indefinitely.
For many web applications, a hosted offering is the most natural commercial layer. The open-source edition gives technical teams control and confidence. The hosted edition gives organisations time back.
That value includes more than server space. It includes backups, monitoring, upgrades, secure defaults, incident response, performance tuning, and someone who is accountable when the service matters at 2 a.m.
A hosted offer works best when it is genuinely better for the buyer’s situation, not when it is merely the only version that receives care. Self-hosting should remain viable for the audience the project claims to support. The hosted product should win through convenience, reliability, and operational maturity.
Support is valuable, but unlimited support is a quiet way to destroy a small company. Define response targets, supported versions, communication channels, and what qualifies as an incident. Publish the boundaries before the first enterprise customer arrives.
Community support and commercial support can coexist. Community spaces are ideal for shared questions, implementation ideas, and collaboration. Paid support should provide accountable help for organisations with deadlines, production systems, and internal stakeholders.
Downloads, GitHub stars, newsletter subscribers, and social engagement are useful signals. They are not revenue forecasts. A project can be widely admired by individual developers and still have no clear economic buyer.
Before investing heavily in a commercial layer, speak with organisations that use the software in production. Ask what costs them time, where they face risk, what prevents adoption, and who owns the budget. Their answers should shape the offer more than online applause does.
Open source succeeds when users believe the project’s intentions are coherent. A sudden licence change, an artificial feature wall, or promises that cannot be maintained can damage that trust quickly.
The sustainable approach is simpler: keep the open project useful, state what the company sells, and make the paid offer valuable enough that the right customers are happy to buy it.
Open source can be the foundation of an excellent software business. It just cannot be the entire plan.
]]>A client sees a website, an application, or a redesign as a living business asset. Once the project begins, they learn more. A new stakeholder appears. A competitor launches something unexpected. A marketing campaign changes direction. A feature that looked optional becomes essential.
None of this is unusual. The mistake is treating change as a failure of planning rather than a normal cost of building digital products.
Small requests rarely remain small in a web project. A new field in a form can affect validation, database structure, emails, analytics, privacy documentation, mobile layouts, translations, tests, and support material. A new user role can affect permissions throughout an application.
When an agency accepts these requests informally, it creates two problems at once. The agency absorbs unplanned work, while the client never sees the real trade-off behind the decision. Over time, both sides become frustrated: the client feels that delivery is slow, and the agency feels that every project is becoming unprofitable.
The answer is not to say no to every change. It is to make change visible, budgeted, and easy to discuss.
A change budget is a defined amount of time or money reserved for decisions that cannot reasonably be made before work begins. It is not a vague contingency hidden inside the estimate. It is a named part of the commercial agreement.
For example, a fixed-price project might include a 10% change reserve. A €40,000 project would therefore identify €4,000 specifically for approved adjustments. A time-and-materials engagement can set aside a defined number of hours per month. A retained client might receive a quarterly improvement budget that is separate from routine support.
The client should understand three things from day one:
The operational part matters as much as the contract. Every requested change needs a short decision record. It does not need legal language or a long document. It needs clarity.
A useful record answers five questions: What is changing? Why does it matter now? What will it affect? What will it cost in time or money? What will be delayed, removed, or funded as a result?
That final question is the one agencies often skip. If everything is “important,” then nothing is being prioritised. A change budget forces the client and agency to make the trade-off together, while there is still time to act on it.
Many agency owners worry that discussing change will make the relationship feel transactional. In practice, the opposite is usually true. Clients lose trust when surprises appear late, or when they discover that “included” work was quietly paid for through rushed delivery and exhausted teams.
A visible change budget gives the client a legitimate path to adapt. It also lets the agency respond constructively: “Yes, we can do that. Here is what it uses, and here are the options.”
This is a more mature conversation than either automatic acceptance or automatic refusal.
After several projects, review where change budgets were spent. If most of the reserve goes to integrations, your discovery process may be underestimating third-party systems. If it repeatedly goes to content and approvals, your project plan may need earlier stakeholder workshops. If the same feature requests return across clients, you may have discovered a productised service opportunity.
Change is not merely a cost to control. It is information about what clients actually need.
The agencies that protect their margins best are not the ones that predict every detail perfectly. They are the ones that give inevitable uncertainty a price, a process, and a place in the relationship.
]]>The new schedule begins its transition in October 2026, with the Node.js 27 Alpha cycle scheduled to start on October 28. The first stable Node.js 27 release is planned for April 2027, followed by Long-Term Support later that year.
This is more than a change in version numbering. It reflects how the JavaScript server ecosystem has evolved, how developers adopt new releases, and how a largely volunteer-maintained project manages its long-term support responsibilities.
For approximately a decade, Node.js followed a predictable pattern: two major versions each year, with an even-numbered release in the spring and an odd-numbered release in the autumn.
Even-numbered releases eventually entered Long-Term Support, while odd-numbered releases had comparatively short lifetimes.
This arrangement gave developers early access to new functionality while providing production environments with a stable release line.
However, the Node.js Release Working Group has acknowledged that adoption patterns have changed.
Many organizations avoid odd-numbered releases entirely, preferring to wait for LTS versions. As a result, the project has been maintaining release lines that receive relatively limited production adoption.
Maintaining multiple active versions also creates substantial work for the project’s contributors, particularly when security vulnerabilities require patches across several branches.
The revised schedule attempts to simplify this situation without sacrificing the predictability that enterprise users expect.
Starting with Node.js 27, the project will publish one major stable release each April.
Every major version will eventually enter Long-Term Support. The previous distinction between odd-numbered and even-numbered releases will disappear.
Under the new model, each release line moves through three principal phases:
The project plans approximately 36 months of support from the first stable major release to end of life.
For production users who already wait for LTS releases, the practical upgrade rhythm remains broadly similar. The main difference is that every annual major version will now follow the path to LTS.
The most significant addition is the new Alpha channel.
Unlike traditional nightly builds, Alpha releases are intended to be signed, tagged, and tested through the project’s established compatibility-testing infrastructure.
They are designed primarily for library maintainers, framework developers, and teams responsible for compatibility testing.
During the Alpha phase, the project may introduce semver-major changes. APIs and binary interfaces may therefore change between Alpha releases.
This flexibility gives maintainers an opportunity to identify compatibility problems before the stable major release.
It also creates a clearer distinction between experimental compatibility testing and production deployment.
The Release Working Group explicitly states that Alpha builds are not intended for production use.
According to the project’s published release schedule, the principal milestones for Node.js 27 are:
These dates represent the project’s current schedule and may change.
Importantly, the start of a scheduled Alpha phase should not be confused with confirmation that a particular Alpha binary is available for download. Developers should consult the official release channels before installing a prerelease build.
Node.js 26 remains the final release line under the previous schedule.
Its LTS transition is scheduled for October 28, 2026. The project’s release-status page still identifies the latest published Node.js 26.12.1 build, released on October 21, as a Current release.
Node.js 26 is expected to enter maintenance in October 2027 and reach end of life in April 2029.
Teams using Node.js 24 LTS should not interpret the arrival of Node.js 27’s Alpha cycle as a requirement to upgrade immediately.
Production upgrade decisions should continue to follow supported release status, dependency compatibility, application requirements, and operational testing.
The new Alpha phase is especially relevant for maintainers of npm packages, web frameworks, native addons, and development tools.
Under the previous model, many projects tested compatibility against Current and LTS versions, while odd-numbered releases provided an additional opportunity to identify upcoming changes.
With the new annual schedule, maintainers who test only against LTS releases may discover compatibility problems much later in the development cycle.
The Node.js project therefore encourages library authors to incorporate Alpha releases into their continuous integration workflows as early as practical.
Such tests should generally be treated as experimental compatibility checks rather than mandatory production release gates.
A failure against an Alpha build may reveal an upcoming breaking change, but it may also reflect behavior that will change again before the stable release.
For application teams, the new schedule creates an opportunity to simplify version-management policies.
Instead of tracking alternating short-lived and long-lived major releases, organizations can plan around a yearly stable release followed by a predictable LTS transition.
A practical strategy is to maintain production environments on supported LTS versions, test upcoming stable versions before their LTS promotion, and use Alpha builds only in isolated compatibility-testing environments.
Teams should also review their package engine constraints, CI matrices, container base images, and native dependencies whenever a new major release approaches.
For applications using native addons, binary compatibility deserves particular attention because a new major Node.js version can introduce changes that require updated dependencies or rebuilt binaries.
The release schedule also reflects an important reality of open-source infrastructure: maintenance capacity is finite.
Node.js is a widely deployed runtime, but much of its maintenance work is performed by volunteers.
Supporting fewer concurrent release lines can reduce the complexity of backporting security fixes, testing compatibility, and preparing releases.
The objective is not simply to release software less frequently. It is to allocate development and maintenance effort more effectively while preserving the reliability expected by production users.
The move to annual major releases represents a meaningful evolution in how Node.js balances innovation, compatibility, and long-term maintenance.
For production application developers, the transition should preserve much of the familiar LTS upgrade rhythm.
For library maintainers, the new Alpha channel creates an earlier opportunity to test compatibility and report problems before they reach stable releases.
Node.js 27 will be the first major release to follow this model. Its success will depend not only on the release process itself, but also on how effectively the broader JavaScript ecosystem uses the additional testing window.
Announced on October 14, 2026, the feature allows repositories to record the exact commits used by their workflow dependencies, including transitive dependencies. It provides a more systematic alternative to manually pinning every action to a commit SHA.
The change is particularly relevant for teams that depend on third-party GitHub Actions to build, test, package, and deploy their applications.
Most GitHub Actions workflows reference external actions using version tags:
name: CI
on:
push:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: echo "Running tests"The syntax is convenient and readable. However, Git tags are references, not immutable guarantees.
If a tag is moved to another commit, a subsequent workflow execution can run different code without any modification to the consuming repository.
In ordinary circumstances, maintainers may move tags as part of their release process. In a compromised repository, the same mechanism can become a software supply-chain attack vector.
Historically, GitHub has recommended pinning third-party actions to complete commit SHAs. That approach provides stronger reproducibility, but it can make workflow files harder to read and does not automatically solve the problem of dependencies used internally by composite actions.
The new feature introduces a repository-level file named:
.github/workflows/actions.lockThis file records the dependencies used by onboarded workflows and the exact commits to which those dependencies resolve.
When an onboarded workflow runs, GitHub Actions uses the commits recorded in the lockfile rather than resolving a potentially changed tag or branch reference.
The lockfile also records repository identity information, helping distinguish a trusted repository from another repository that might later appear under the same name.
This is an important improvement because securing CI/CD dependencies involves more than selecting a version number. It also requires knowing which repository supplied the code and whether the executed content matches what was reviewed.
GitHub provides a CLI extension named gh-actions-lock for creating and maintaining workflow lockfiles.
After installing the GitHub CLI and authenticating, install the extension:
gh extension install github/gh-actions-lockFrom the root of a repository, run:
gh actions-lockThe extension scans the repository’s workflows, resolves supported dependencies, and generates the lockfile.
It may also update action references in workflow files to more specific versions. Developers should therefore review the entire Git diff rather than examining only the generated lockfile.
Teams can also introduce locking gradually. To onboard one workflow:
gh actions-lock .github/workflows/ci.ymlThis is useful for organizations with many repositories or complex workflows. A pilot can establish whether the generated dependencies are correct before the approach is adopted more widely.
A lockfile provides little protection if developers can modify workflows without updating or reviewing the corresponding dependency records.
GitHub’s documentation recommends integrating verification into the development process.
For example:
gh actions-lock --verifyThis command checks whether the lockfile remains consistent with the workflow dependencies.
For a lightweight local check, developers can use:
gh actions-lock --verify-local --no-fixThe local verification operates without network access. It checks dependency coverage but does not revalidate every pinned commit against GitHub.
These checks can be integrated into pre-commit hooks and pull-request workflows to detect stale lockfiles before changes are merged.
One of the more interesting aspects of workflow lockfiles is their support for transitive dependencies.
A composite action may invoke other actions internally. Pinning only the top-level action does not necessarily make every dependency visible to the consuming repository.
The new lockfile mechanism can record these nested dependencies, improving the visibility of code executed during workflow runs.
There is an important exception: dependencies inside a reusable workflow are governed by the lockfile in the repository where that reusable workflow is defined.
Organizations maintaining shared reusable workflows should therefore consider onboarding those repositories before introducing lockfile enforcement across consuming applications.
Locking dependencies creates a new maintenance responsibility. Once a dependency is pinned, it will not automatically move to a newer commit simply because an upstream tag changes.
This is desirable from a reproducibility perspective, but it means security updates must be managed deliberately.
GitHub has integrated the feature with Dependabot. When Dependabot updates an action reference in a workflow already using lockfiles, it can regenerate the corresponding lockfile entry in the same pull request.
That allows reviewers to examine both the version change and the exact commit that will execute.
GitHub also recommends protecting the lockfile through CODEOWNERS and requiring appropriate reviews when dependency records change.
A lockfile guarantees neither the quality nor the security of the dependency it records.
If a malicious or vulnerable action is already present when the lockfile is generated, locking it simply preserves that exact version.
Teams still need dependency reviews, appropriate workflow permissions, secure handling of credentials, and a process for responding to security advisories.
Lockfiles also do not automatically make every build reproducible. Package managers, external downloads, container images, and build tools can introduce additional mutable dependencies.
The feature should therefore be viewed as one component of a broader software supply-chain security strategy.
Workflow dependency lockfiles entered public preview on October 14, 2026. GitHub announced access for Free, Team, GitHub Enterprise Cloud, and Enterprise Cloud with data residency.
As a preview feature, its behavior and tooling may change before general availability.
Organizations should evaluate compatibility with existing action allowlists, repository policies, and reusable workflows before making lockfile enforcement mandatory.
GitHub Actions workflow lockfiles address a practical security problem that has existed for years: the difference between reviewing a workflow configuration and knowing exactly which code will execute.
By recording direct and transitive dependencies, the feature makes workflow execution more predictable and dependency changes easier to audit.
It is not a complete supply-chain security solution, but it provides a useful foundation for teams that want stronger control over their CI/CD environments.
For organizations already using GitHub Actions extensively, a small pilot with a non-critical repository is a reasonable place to begin.
This time, however, the problem is different. The vulnerability does not originate in PHP’s source code. It affects a third-party library included in the official Windows distributions.
The distinction is important because developers relying exclusively on PHP_VERSION or the output of php -v may not be able to determine whether their installation contains the updated dependency.
The PHP team has published four updated Windows package versions:
These packages include Brotli 1.2.1, which addresses CVE-2026-111497, an out-of-bounds write vulnerability in the Brotli decoder.
The -1 suffix identifies a Windows package rebuild. It does not represent a new PHP language release, and the underlying PHP source versions remain unchanged.
Consequently, an installation using PHP 8.5.12-1 still reports PHP 8.5.12 as its runtime version.
For organizations maintaining inventories of PHP installations, this creates an important distinction between the language version and the actual binary distribution deployed on a server.
Brotli is a compression algorithm commonly used to reduce the size of web resources transferred over HTTP. Browsers and HTTP clients can request Brotli-compressed responses, reducing network traffic when servers support the format.
The vulnerability identified as CVE-2026-111497 affects the decoder responsible for decompressing Brotli data.
According to the published security advisory, a specially crafted compressed stream can trigger memory corruption. Depending on the affected software and execution context, the consequences may include process crashes, information disclosure, or potentially arbitrary code execution.
These are potential impacts of the underlying decoder vulnerability, not a claim that every PHP installation can be exploited remotely.
The PHP announcement identifies a specific exposure path: the cURL extension on Windows can invoke the affected Brotli decoder when automatic HTTP response decompression is enabled.
PHP applications frequently use cURL to retrieve API responses, download files, or communicate with external services.
By default, libcurl does not enable automatic HTTP response decompression through its CURLOPT_ACCEPT_ENCODING option. However, applications and HTTP client libraries can enable this behavior.
For example, the following configuration asks libcurl to negotiate all compression formats supported by its build:
<?php
$ch = curl_init('https://example.com/api/data');
curl_setopt(
$ch,
CURLOPT_ACCEPT_ENCODING,
''
);The empty string is significant. It tells libcurl to advertise the compression formats available in the installed library and automatically decompress supported responses.
When Brotli support is present, this can include Brotli-compressed content.
Applications may also enable automatic decompression indirectly through HTTP client libraries. Developers should therefore examine their actual dependency configuration rather than assuming the default cURL behavior always applies.
PHP provides the curl_version() function, which exposes information about the underlying libcurl installation and supported features.
A small diagnostic script can help identify the Brotli version reported by libcurl:
<?php
declare(strict_types=1);
if (!extension_loaded('curl')) {
fwrite(STDERR, "cURL extension unavailable\n");
exit(1);
}
$curl = curl_version();
if ($curl === false) {
fwrite(STDERR, "Cannot inspect libcurl\n");
exit(1);
}
printf(
"PHP version: %s\n",
PHP_VERSION
);
printf(
"libcurl version: %s\n",
$curl['version'] ?? 'unknown'
);
printf(
"Brotli version: %s\n",
$curl['brotli_version'] ?: 'not available'
);This script provides useful diagnostic information, but it is not a complete security verification tool.
In particular, it does not identify the official Windows package rebuild suffix, and the reported dependency information must be interpreted in the context of the actual installation.
For managed environments, administrators should verify the source of the installed binaries, their package versions, and the dependencies actually loaded by running PHP processes.
Most PHP administrators begin a version audit with:
php -vThat remains useful for identifying the PHP runtime version. It does not necessarily establish whether every bundled library has received its latest security update.
In this case, PHP 8.5.12 and PHP 8.5.12-1 share the same PHP source release but contain different dependency versions in their official Windows packages.
The appropriate verification process is therefore to identify the actual package installed and compare it with the official Windows downloads.
Administrators downloading packages manually should also verify their integrity using the published SHA-256 checksum.
On Windows PowerShell, this can be done with:
Get-FileHash .\php-package.zip -Algorithm SHA256The resulting hash should match the checksum published alongside the exact package on the official PHP downloads page.
Windows users running official PHP distributions should install the updated packages corresponding to their PHP branch, architecture, and thread-safety configuration.
For example, an application using the Non Thread Safe build under IIS should not switch arbitrarily to a Thread Safe package. The replacement must remain compatible with the existing server configuration and installed extensions.
After replacing the binaries, restart the relevant services and verify that the application is using the updated installation.
Developers using third-party Windows distributions or package managers should consult their distribution maintainers. The PHP project’s rebuild announcement applies specifically to its official Windows packages.
Similarly, Linux distributions may use system-provided libraries and apply security fixes through their own package-management processes. Their package versions and update procedures should not be inferred from the Windows announcement.
The Brotli update illustrates a recurring challenge in software maintenance: a runtime is more than its language interpreter.
PHP installations depend on libraries providing cryptography, networking, compression, database connectivity, and other capabilities. A vulnerability in one of these components can require a distribution update even when the PHP source code itself has not changed.
For teams maintaining production systems, this is a strong argument for tracking binary provenance, package revisions, and third-party dependencies alongside application and language versions.
The October 26 Windows rebuilds are a targeted security response to a vulnerability in a bundled compression library.
The immediate action is straightforward: Windows administrators using affected official packages should move to the updated builds.
The longer-term lesson is equally important. Knowing the PHP version is necessary, but it is not always sufficient to establish the security state of an installation.
Effective runtime maintenance requires visibility into the complete software distribution, including the native libraries on which applications depend.
A cloud provider may assign a resource identifier only after creation. An API may return a value whose exact content cannot be determined during planning. These unknown values can propagate through infrastructure configurations, sometimes preventing useful validation until the deployment is already underway.
OpenTofu 1.13, released on September 29, 2026, introduces several functions designed to address part of this problem. Alongside improved platform support and early experiments with built-in linting and reusable symbol libraries, this release offers infrastructure developers more ways to describe what they know about values that have not yet been computed.
OpenTofu 1.13 is not a major architectural overhaul. The project describes it as a relatively light release, following a shorter development cycle intended to align more closely with the Go release schedule.
According to the release announcement, the 1.13 series is expected to receive security support until August 2027. The release also introduces official Windows ARM64 builds, expands its expression language, and includes early work on tooling capabilities that remain experimental.
For teams already managing production infrastructure with OpenTofu, the most interesting changes may be those affecting how configuration expressions behave during the planning phase.
Consider a configuration that creates an AWS virtual private cloud. The provider normally determines the final VPC identifier only after the resource has been created.
During planning, an output may therefore contain an unknown value:
output "vpc_id" {
value = aws_vpc.main.id
}This is expected behavior. Infrastructure tools must avoid pretending that values are known before the provider has supplied them.
However, an unknown identifier may still have predictable properties. For example, AWS VPC identifiers follow a recognizable prefix convention, even when the complete identifier is not yet available.
OpenTofu 1.13 introduces functions that allow module authors to make certain assumptions explicit, providing additional information to the planning engine.
The new family of assume... functions allows developers to describe properties of values that are not yet finalized.
For example, when an AWS VPC resource is defined elsewhere in a configuration, we can express that its identifier is expected to be non-null and begin with a known prefix:
output "vpc_id" {
value = assumenotnull(
assumestringprefix(
aws_vpc.main.id,
"vpc-"
)
)
}The assumestringprefix() function declares an expected string prefix, while assumenotnull() indicates that the final value must not be null.
When the actual value becomes available, OpenTofu checks whether these assumptions hold. If they are violated, the operation fails rather than silently accepting an incorrect result.
These functions do not generate a resource identifier, and they do not force the cloud provider to reveal it earlier. They allow OpenTofu to reason about certain properties of a value while its exact contents remain unknown.
Reusable infrastructure modules often expose outputs consumed by other modules. If those outputs are entirely unknown during planning, downstream expressions may also become unknown, even when some useful properties can already be established.
Explicit assumptions can make these relationships easier to evaluate. For example, a consuming module might be able to determine that an identifier is not null without waiting for the entire identifier to be returned by the provider.
This can help OpenTofu evaluate conditional expressions and validation rules earlier in the deployment process.
Earlier validation is valuable because discovering a configuration problem during planning is generally less disruptive than encountering it halfway through infrastructure creation.
However, the OpenTofu documentation is careful not to promise that every problem will be detected during planning. The result depends on the available information, provider behavior, and the expressions involved.
Another addition in OpenTofu 1.13 is the convert() function. It explicitly converts a value to a specified type constraint.
Consider a module that receives a JSON configuration containing a service name and a set of labels:
variable "service_payload" {
type = string
}
locals {
service = convert(
jsondecode(var.service_payload),
object({
name = string
labels = map(string)
})
)
}If the JSON input is known, OpenTofu can decode it and validate whether it conforms to the expected structure. If the input is unknown during planning, the converted result can still carry useful type information even though its actual values remain unknown.
This makes the function particularly interesting for modules processing dynamic configuration data or provider outputs containing JSON.
It is important to remember that OpenTofu already performs many type conversions automatically. The new function is not intended to replace ordinary type declarations, but to handle situations where the expected result is ambiguous or cannot otherwise be inferred.
Beyond the expression language, OpenTofu 1.13 includes early work toward built-in linting and a feature described as Symbol Libraries.
These initiatives are still experimental. They should not be confused with fully established functionality that teams can immediately depend on in production workflows.
The direction is nevertheless worth following. Infrastructure development increasingly resembles conventional software development, with reusable modules, shared conventions, automated validation, and code review processes.
Integrating more analysis capabilities directly into infrastructure tooling could eventually simplify parts of this workflow. But established external linters, security scanners, and policy tools continue to serve important purposes today.
Teams upgrading to OpenTofu 1.13 should review the release notes carefully, particularly when maintaining shared automation environments or using provisioners.
One compatibility change concerns the base64gzip() function, whose output can differ slightly from previous releases. Configurations depending on exact encoded output should be tested.
Another change is the removal of WinRM support for provisioners. Organizations still depending on that mechanism need to examine their workflows before upgrading.
A sensible upgrade process includes testing representative configurations in a non-production environment, reviewing plans for unexpected changes, and validating provider compatibility before modifying shared deployment pipelines.
There is an important distinction between documenting a known constraint and inventing certainty where none exists.
Assumption functions are useful only when their constraints are supported by a reliable contract, such as a provider’s documented behavior or a stable external API specification.
Incorrect assumptions do not make infrastructure more predictable. They merely postpone the discovery of an invalid expectation until the actual value becomes available.
Module authors should therefore use these functions selectively, document the underlying assumptions, and test failure scenarios as well as successful deployments.
OpenTofu 1.13 is a relatively modest release, but its improvements to unknown-value handling address a practical problem in Infrastructure as Code development.
Functions such as convert(), assumenotnull(), and assumestringprefix() allow module authors to express more information about values that are not fully determined during planning.
The result is not a system that knows the future. It is a planning engine that can sometimes make better decisions based on constraints developers already understand.
For infrastructure teams, that is a useful direction: clearer configurations, more meaningful plans, and potentially earlier detection of problems, without confusing assumptions with actual results.
Developers have addressed this problem through naming conventions, CSS Modules, scoped styles in frameworks, and Shadow DOM. Each approach has advantages, but also introduces conventions or additional tooling.
With CSS @scope, browsers now provide a native mechanism for limiting where selectors apply. The feature reached Baseline newly available status in March 2026, meaning it works across current versions of the major browser engines, although older browsers still require consideration.
Consider a web application with an article component, a comments section, and an embedded third-party widget. A developer might begin with selectors like these:
.article-card h2 {
color: #243b6b;
}
.article-card a {
text-decoration: underline;
}
.article-card p {
line-height: 1.7;
}These selectors appear reasonable. The problem arises when the article component contains nested components with their own headings, links, and paragraphs.
The selectors can match elements deeper in the document tree, including elements belonging to a widget that happens to be inside the article container. The widget’s stylesheet may then override those rules with more specific selectors, encouraging another round of increasingly complex overrides.
Over time, a stylesheet can become difficult to change without introducing regressions elsewhere.
The @scope at-rule defines a region of the document within which its contained selectors are evaluated.
For example:
@scope (.article-card) {
h2 {
color: #243b6b;
}
p {
line-height: 1.7;
}
a {
text-decoration: underline;
}
}The selectors inside this rule apply within elements matching .article-card. We no longer need to repeat the parent selector for every declaration.
Importantly, this is not simply syntactic sugar. The scope participates in the CSS cascade, enabling behaviors that ordinary descendant selectors cannot express as directly.
One particularly useful feature is the ability to define both a starting boundary and an exclusion boundary.
Consider the following markup:
<article class="article-card">
<h2>Article title</h2>
<p>Article introduction</p>
<aside class="embedded-widget">
<h2>Related content</h2>
<p>Widget description</p>
</aside>
</article>We want to style the article content without changing the nested widget. CSS @scope supports this using the to keyword:
@scope (.article-card) to (.embedded-widget) {
h2 {
color: #243b6b;
}
p {
line-height: 1.7;
}
}The upper boundary includes the article component, while the lower boundary excludes the widget and its descendants.
This is commonly called donut scoping: styles apply inside one region of the document, except for a defined subtree.
It is useful for content management systems, documentation websites, dashboards, and applications combining first-party components with embedded services.
CSS @scope also introduces scoping proximity into the cascade. When otherwise competing rules have matching precedence and specificity, the rule whose scope root is closest to the target element can win.
Consider nested sections with different themes:
<div class="theme-light">
<p>Light section</p>
<div class="theme-dark">
<p>Dark section</p>
<div class="theme-light">
<p>Light section again</p>
</div>
</div>
</div>Without scoping, selectors written for light and dark sections may compete depending on specificity and source order.
With @scope, we can express the relationship more naturally:
@scope (.theme-light) {
:scope {
background: #f5f7fb;
}
p {
color: #243047;
}
}
@scope (.theme-dark) {
:scope {
background: #202939;
}
p {
color: #ffffff;
}
}The innermost paragraph receives the light theme because its closest matching scope is the inner light-themed container.
This does not mean scope always overrides specificity. CSS still considers origins, importance, cascade layers, and selector specificity before scoping proximity. However, proximity provides an additional way to resolve conflicts without endlessly increasing selector complexity.
CSS Modules typically transform local class names during a build process, helping prevent naming collisions. Framework-specific scoped styles often achieve similar results through generated attributes or selector transformations.
CSS @scope works differently. It is interpreted directly by the browser and defines boundaries within the document tree. It does not generate unique class names, remove the need for class naming conventions, or provide the stronger encapsulation associated with Shadow DOM.
These approaches are not mutually exclusive. A project already using CSS Modules may have little reason to remove them immediately. Conversely, applications built with traditional templates, server-rendered HTML, or web components without Shadow DOM may find native scoping particularly convenient.
Although @scope is available across current browser versions, older releases do not necessarily support it. Unsupported at-rules are ignored, so an application relying entirely on scoped rules may lose important styling.
A practical adoption strategy is to preserve essential styles using conventional selectors and introduce scoped rules as enhancements.
/* Baseline styling for all supported browsers */
.article-card {
padding: 1.5rem;
border: 1px solid #d7dce5;
}
.article-card .title {
color: #243b6b;
}
/* Enhanced scoping in newer browsers */
@scope (.article-card) to (.embedded-widget) {
a {
text-decoration-thickness: 2px;
text-underline-offset: 3px;
}
}In this example, the essential layout and title styling remain available even when the browser ignores @scope. The scoped link enhancement is applied only in supporting browsers.
For production applications, compatibility requirements should be based on actual user data and browser-support policies rather than assuming every user has installed the latest browser.
Native scoping should improve readability, not become another layer of unnecessary abstraction. Teams still need consistent component boundaries, predictable naming, and an understanding of the CSS cascade.
It is also worth reviewing how scoped rules interact with existing cascade layers and selectors. Mixing a large legacy stylesheet with new scoped rules without an explicit strategy can produce confusing results, especially when older high-specificity selectors remain in place.
As with any significant CSS change, visual regression tests and browser testing remain useful before applying the feature widely.
CSS @scope provides an important improvement to native browser styling. By expressing component boundaries directly in CSS, it reduces the need for repetitive selectors and offers a clearer way to manage nested components.
It does not replace every existing styling architecture, nor does it eliminate the complexity of the cascade. Its value lies in making an increasingly common requirement—styling one part of a page without unintentionally affecting another—more explicit.
For teams maintaining large front-end applications, @scope is worth testing in isolated components before deciding how broadly it should be adopted.