A little DX win as we near the finish line for Webiny v6 🏁 Extending built-in features is cleaner now — no more @webiny/di imports or manual calls. Just your code. 👇

In Webiny v6, unifying all developer APIs into the new "webiny" package delivers: 📘 A comprehensive documentation experience. This will make API references easier to navigate!

We started with a Rspack setup for Webiny v6, but testing showed that `Rsbuild` was better. Switching to it allowed us to remove a lot of outdated code, resulting in the cleanest build summaries we've ever had. It feels great to modernize our foundation before release.

It took us a while to get to it, but Webiny v6 now includes proper TypeScript error blocking during API builds. If something doesn’t match its expected type, the build will fail. This was sitting in our backlog for ages, but it’s finally here. Check out the screenshot below to

We’ve been showing webiny.config.tsx a lot lately, but not what actually sits behind those extension entries. Here are a couple of simple implementations in action — one that registers a custom Admin logo/name, and another that hooks into the “API key after update” lifecycle

Following up on yesterday’s peek behind webiny.config.tsx, here are two more extension implementations in action. One registers a custom Pulumi handler so you can run additional infrastructure logic during deploys. The other defines a custom CLI command that becomes part of the

The shift away from a monorepo in Webiny v6 brought some huge quality-of-life improvements. Exhibit A: the root package.json. What used to be a massive blob of dependencies, scripts, workspace utilities, resolutions, and custom project setup… …is now a tiny, clean, modern

re:Invent vibes are starting already ⚡ As some of you may know, Webiny is all about #serverless on AWS (at least for now 😉), so we’re definitely hoping for some fresh serverless goodies next week. Any predictions? Anything you’d like to see? We all know the AI overload is a

Webiny v6 finally introduces a proper DI system — @webiny/di under the hood — and it works the same across everywhere you write code and extend Webiny: its backend APIs, Admin app, CLI, and infrastructure. Whether you’re adding a GraphQL resolver, a model, a CLI command, or a

🚀 With Webiny v6, we’re upgrading OpenSearch 2.11 → 3.3! This upgrade lays the foundation for smarter content discovery: 🤖 Ready for semantic & AI-powered search in the future ⚡ Faster queries — optimized for large sites & similarity searches 💡 Better related content

Durable Functions for AWS Lambda just went live 🎉 We’re really curious how this could plug into Webiny’s background task workflows — and even more excited about what this could unlock `for Webiny users`. Definitely something we’ll be experimenting with: aws.amazon.com/blogs/aws/buil…

A subtle but huge Webiny v6 improvement: strict extension validation! 🎉 When you declare something like Security.ApiKey.AfterUpdate, Webiny now checks that your implementation matches the right handler. Pick the wrong abstraction? The API build stops and tells you exactly why.

Webiny v5 projects came with Pulumi secret env vars pre-generated in .env file. But… Accidentally lose them, and you couldn’t deploy your existing dev environment anymore — you basically had to redeploy it from scratch. And yes… that happened 😅 In v6, they’re no longer

With Webiny v5, developers could watch API changes, but each edit meant redeploying AWS Lambda functions—a slow and frustrating process. Then we introduced a new “yarn webiny watch api” command as a beta feature to solve this: run AWS Lambda functions locally, debug easily, and

Most DI containers catch errors at runtime. Webiny’s DI container (webiny/di) catches them at compile time. With Abstraction<T>, the token _is_ the type — so the container knows exactly what you meant, and TypeScript yells the moment something doesn’t match. No magic strings,

A small internal experiment: visualizing parts of Webiny’s DI object graph. Not a feature, not a roadmap item — just us poking around in the sandbox. Since DI now spans Admin, API, and the CLI, being able to see how everything wires together is super insightful. A snapshot of

In Webiny `v6`, you can finally choose different DB setups per environment — DynamoDB-only in dev, DynamoDB+OpenSearch in prod, etc. But to prevent broken environments (and even potential data loss), we’ve added a safety check: 👉 If an environment was first deployed with

CLI output is part of DX too. Just experimenting with a couple of output styles for the Webiny v6 CLI. Same info, a bit different presentation. A or B — what’s your pick?

🚀 Big observability upgrade coming to Webiny. In v5, logging was mostly unstructured and hard to work with. In v6, logging is fully structured — consistent, readable, and machine-friendly by default. This unlocks: • easier debugging • clearer CloudWatch output • seamless

Structured logging in Webiny v6 isn’t just for the backend. The CLI can now stream structured logs directly into your terminal, showing what’s happening under the hood while building, deploying, or running commands. This makes debugging issues — and reporting bugs —