Overview​

We've added a new skpr console command to the Skpr CLI that lets you directly access the Skpr Console for an environment.

Example​

skpr console <environment>

Link​

• v1.9.0

Overview​

We've added a new skpr logs query command to the Skpr CLI that lets you run a bounded query over the logs of a running application.

Unlike the streaming skpr logs tail command, skpr logs query fetches a finite window of log events - making it ideal for investigating past incidents, filtering for specific errors, or reviewing activity over a defined time period.

For more information, run:

skpr logs query --help

Link​

• v1.9.0

Overview​

We've introduced improvements to how skpr validate and skpr deploy handle warnings.

These changes are designed to surface issues early, particularly in CI workflows, before they make it into a deployment.

Changes​

Validate now exits with an error on warnings​

Previously, running skpr validate <env> would exit successfully even if your site had warnings. As of v1.9.0, warnings will cause the command to exit with a non-zero status, making it easier to catch issues early in CI pipelines.

skpr validate dev

Deploy blocks on warnings​

If your site has warnings, skpr deploy <env> will now throw an error and refuse to deploy. Violations and warnings will be printed on failure so you can see exactly what needs to be addressed.

skpr deploy dev

Bypassing warnings​

If you've reviewed the warnings and are happy to proceed, you can bypass them using the --ignore-warnings flag:

skpr deploy dev --ignore-warnings

Note: Violations cannot be bypassed — only warnings.

What triggers a warning?​

Warnings are raised for significant configuration changes, such as removing a domain name from an environment. The set of conditions that trigger warnings will be updated with each Skpr minor release as required.

Link​

• v1.9.0

Overview​

Our PHP versions have been updated to:

• 8.5.9
• 8.4.24
• 8.3.33
• 8.2.33

This is a security release, covering the following:

• CVE-2026-17543 (PGSQL, PDO_PGSQL) - The PostgreSQL escaping functions don't escape backslashes, so user input placed inside an E'...' string literal can break out of the quotes and inject SQL.
• CVE-2026-17544 (BCMath) - bccomp() could write outside its allocated buffer when the scale argument trimmed trailing zeros from a fraction, for example bccomp("1.901", "0", 2). This one only affects 8.5 and 8.4.
• CVE-2026-7260 (Phar) - Recursive symlinks inside a Phar archive crash the stream handler, which an attacker can use for denial of service.
• CVE-2026-9672 (GD) - Upstream libgd upgrade that fixes image processing vulnerabilities.

Link​

Pull Request #195

Overview​

Two critical vulnerabilities have recently been disclosed in NGINX's ngx_http_rewrite_module. We have been actively monitoring both issues since disclosure. Our configuration is not susceptible to either vulnerability. As a precaution, we have updated our base NGINX images to the latest patched version.

The vulnerabilities​

NGINX Rift — CVE-2026-42945 (CVSS 9.2 Critical)​

Disclosed on 13 May 2026, NGINX Rift is a heap buffer overflow in NGINX's ngx_http_rewrite_module triggered when the rewrite, if, or set directive is used with an unnamed expression (such as $1 or $2) to replace strings after a question mark. A single crafted HTTP request from an unauthenticated remote attacker can crash the worker process (DoS) or, in some conditions, achieve remote code execution. The bug had been present in the codebase since NGINX 0.6.27 in 2008 and affects NGINX Open Source versions 0.6.27 through 1.30.0 and NGINX Plus R32 through R36.

NGINX PoolSlip — CVE-2026-9256 (CVSS 9.2 Critical)​

Disclosed on 22 May 2026, just nine days after Rift, PoolSlip is a second heap overflow in the same rewrite module. It is triggered when a rewrite directive uses a regex pattern with distinct, overlapping PCRE capture groups, such as ^/((.*))$ paired with a replacement string referencing multiple captures, like $1$2. The crafted request causes a controlled pointer "slip" across adjacent linked structures within the NGINX memory pool, allowing the attacker to overwrite cleanup handler pointers, again enabling DoS and potential RCE. Affected versions are NGINX Open Source 0.1.17 through 1.30.1 and 1.31.0.

Why our configuration is safe​

Both vulnerabilities require specific patterns in rewrite / set / if directives, unnamed capture groups for Rift, and overlapping PCRE capture groups with multi-capture backreferences for PoolSlip. Our base NGINX configuration does not use these patterns, so neither exploit is reachable against our deployed servers.

What we changed​

Out of an abundance of caution, we have updated our base NGINX images to the latest upstream release, which incorporates the patches for both CVE-2026-42945 and CVE-2026-9256. No action is required from customers; the updated images will roll out as part of the normal deployment cycle.

Link​

• CVE-2026-9256
• CVE-2026-42945

Overview​

Skpr now supports custom application metrics. Applications can expose metrics rooted in their own business logic, not just infrastructure signals like CPU and memory usage.

This lets you track what actually matters to your platform. For example: active user sessions, queue depth, or pieces of content published. You define the metrics in your application, and Skpr surfaces them alongside the platform's existing observability data.

Metrics are exposed in Prometheus format. Prometheus is a widely used open standard for collecting and querying time-series data. Any monitoring or alerting tool that reads this format can scrape, graph, and alert on your metrics with no custom integration work.

Link​

• How to enable application metrics for Drupal

Overview​

You can now view Content Delivery Network (CDN) upload and download metrics directly in the Skpr user interface.

These metrics show how much data your CDN is serving and receiving over time. That makes it easier to understand traffic patterns and spot unusual spikes.

Everything sits alongside your existing Skpr metrics, so you get a single view of how your application is performing.

Overview​

Nginx access logs now include a JA4 fingerprint for each request. JA4 is an open standard for fingerprinting TLS clients based on how they negotiate their connection, rather than what they claim to be.

This matters because details like the user agent can be faked. A JA4 fingerprint identifies the underlying client, so two requests from the same tool share a fingerprint even if one spoofs its user agent.

The fingerprint comes through from CloudFront and appears in the http_cloudfront_viewer_ja4_fingerprint field:

"http_cloudfront_viewer_ja4_fingerprint": "t13d1516h2_8daaf6152771_02713d6af862"

You can use it to spot bots, group related traffic, and investigate suspicious activity. It's especially useful for identifying automated clients during traffic spikes or denial-of-service attempts.

Overview​

In release v1.5.0, we've added a new command to the Skpr command-line interface (CLI): release pull.

This command pulls the packaged container images created by the skpr package command, so development teams can pull and debug the packaged application artefacts directly. To use it, run:

$ skpr release pull <environment>

Link​

• v1.5.0

Overview​

With the release of Skpr v1.0 we have added first class support for Payload CMS.

Features:

• MongoDB support through AWS DocumentDB.
• Our CDN solution configured specifically to support Payload.
• CLI and Skpr UI support.
• Same development workflow as other project types.

Link​

• skpr/examples/payload