Ha Ha
Staged Waves
Hosting v4 rolled out through September, one stack at a time.
Ten pages of v4 docs landed September 2. Then AWS Setup, RDS, EKS, ElastiCache, Kubernetes Clusters and Working with Providers followed in staged waves through September 24. Read the docs cascade as a rollout, not a documentation cleanup.
Six departments this cycle. First Pour reaches back to September 2 for the full v4 story.
Hosting v4 rolled out through September, one stack at a time
The docs are how you can tell. Between September 2 and September 24, a full v4 rebuild of the platform appeared in docs.webscale.com in staged waves, one architectural layer at a time. Read it as a rollout, not a documentation cleanup.
The staged timeline
On September 2, ten pages went live in a single batch. The v4 Standard and Essentials stacks, the Web server stack, VM Clusters, Managed Deployments, the Deployments page, MySQL as a v4 service, Custom Logs, Creating Clusters and a rebuilt Glossary. That is the shape of a new stack architecture arriving with reference docs already written.
A week later on September 9, AWS Setup and RDS pages went up. September 11 added Create an EKS stack and Create an environment as how-tos. On September 15, seven image catalog releases landed together (2026.41 and 2026.43 through 2026.48, with 42 skipped), which points to a rolled-up patch train catching up with the v4 stacks. September 17 added Kubernetes Clusters. On September 24, EKS, ElastiCache, Working with Providers and image 2026.49 landed together, closing out the AWS-native stack surface.
What that gets you
What that lets a platform team do that they could not do before September 2: run Webscale-managed applications on their own AWS with EKS as the compute stack, RDS as the database service and ElastiCache as the cache tier, with the Webscale control plane sitting above them. Environments and stacks are created from documented flows rather than tickets. VM clusters and Kubernetes clusters are covered end to end as separate primitives under one Working with Providers abstraction. Image releases are on a cadence a platform team can plan around.
What it doesn't do yet
The docs cover the create and configure paths, but the migration story from a v3 environment to a v4 environment isn't spelled out on the latest-updates page as of September 24. If you're running v3 today, the reference architecture exists to read against, but the migration playbook is a support conversation. Ask before you start.
Full latest-updates log →Ship log
What newly appeared in the docs across the fortnight. Cross-check each item against the linked page before rebuilding.
Hosting v4 stacks
The Essentials, Standard and Web server stack pages went live September 2, alongside VM Clusters, Managed Deployments and the Deployments page. This is the v4 stack architecture landing as public reference material, with MySQL as a first-class v4 service.
AWS-native stacks
EKS, RDS and ElastiCache pages landed across September 9 through September 24. Run Webscale-managed applications on your own AWS primitives, with the control plane above.
Working with Providers
The Working with Providers how-to went up September 24. This is the abstraction under which cluster and environment work is described in v4.
Image catalog cadence
Eight image releases landed across the fortnight in two batches, from 2026.41 through 2026.49 with 42 skipped. Plan your image-pinning against a real cadence.
Every item above traces to a dated page on docs.webscale.com.
VM Clusters, Custom Logs, EKS stack architecture
Technical notes on what changed in the plumbing.
VM Clusters and Kubernetes Clusters are separate primitives
The v4 abstraction treats VM Clusters and Kubernetes Clusters as distinct stack types under the Working with Providers layer, rather than one shape with a runtime toggle. The Sept 2 and Sept 17 docs describe them separately. If your workload maps to both today, decide which primitive it belongs to before v4 migration and pick one.
Custom Logs configuration is its own how-to now
The Configuring and Viewing Custom Logs page went up September 2 alongside the v4 stacks. Log routing in v4 is a first-class configuration surface, not a per-deployment override. Audit which logs your runbooks depend on and rewire them against the new configuration path.
EKS stack architecture uses AWS-native services as first-class components
The Sept 11 Create an EKS stack how-to and the Sept 24 EKS, RDS and ElastiCache reference pages describe a stack architecture where AWS primitives are named directly rather than proxied through Webscale-owned equivalents. Read that as tighter coupling to AWS APIs and pricing where you use these stacks.
The build-versus-buy calculation moved
of organizations decided against buying a software product or feature this year because they could build it in house with agentic coding tools, most often in technology and healthcare. Forty percent of large organizations now report scaling AI agents in at least one function, against 27 percent a year earlier. Thirty-seven percent report any EBIT impact from AI at all, unchanged from the year before.
Source: McKinsey, The State of AI. Global survey of 1,719 respondents across 97 countries, fielded May 4 through June 8, 2026, weighted by each country's share of global GDP. Published August 25, 2026.
Evidence: Independent analyst research. Read the shape as reliable, the decimal places less so.
If you sell platform capabilities to a technology-organization buyer, roughly one in three of your prospects considered building it themselves this year and chose not to buy. The winning pitches are the ones that describe what you take off the roadmap, not the ones that describe what you add to it.
Pre-BFCM cutover checklist
Post-release checklist. Verb-first. One sitting.
What breaks first when ecommerce traffic spikes
Ecommerce failures during peak traffic start before the outage. Slow pages, cache misses and shopper refreshes cost revenue while the dashboards still say the site is up. Adrian walks the failure chain from first slowdown to visible outage, with the cache and third-party tag failures that show up in between. Worth reading against your own BFCM runbook, because what breaks first for you may not be what breaks first in the general case.
Read the post →Forward this to whoever owns the deploy
The platform changes, and what to do about them in your environment.