Deploy Postgres and MySQL databases with PlanetScale + Workers

Post Syndicated from Vy Ton original https://blog.cloudflare.com/deploy-planetscale-postgres-with-workers/

Cloudflare announced our PlanetScale partnership last September to give Cloudflare Workers direct access to Postgres and MySQL databases for fast, full-stack applications.

Soon, we’re bringing our technologies even closer: you’ll be able to create PlanetScale Postgres and MySQL databases directly from the Cloudflare dashboard and API, and have them billed to your Cloudflare account. 


You choose the data storage that fits your Worker application needs and keep a single system for billing as a Cloudflare self-serve or enterprise customer. Cloudflare credits like those given in our startup program or Cloudflare committed spend can be used towards PlanetScale databases.

Postgres & MySQL for Workers

SQL relational databases like Postgres and MySQL are a foundation of modern applications. In particular, Postgres has risen in developer popularity with its rich tooling ecosystem (ORMs, GUIs, etc) and extensions like pgvector for building vector search in AI-driven applications. Postgres is the default choice for most developers who need a powerful, flexible, and scalable database to power their applications.

You can already connect your PlanetScale account and create Postgres databases directly from the Cloudflare dashboard for your Workers. Starting next month, a new Cloudflare subscription will bill for new PlanetScale databases direct to your Cloudflare account as a self-serve or enterprise user.


How to create PlanetScale databases via Cloudflare dashboard after your PlanetScale account is connected. Cloudflare billing is coming next month.

With our built-in integration, PlanetScale databases automatically work with Workers using Hyperdrive, our database connectivity service. Hyperdrive service manages database connection pools and query caching to make database queries fast and reliable. You just add a binding to your Worker’s config file: 

// wrangler.jsonc file
{
  "hyperdrive": [
    {
      "binding": "DATABASE",
      "id": <AUTO_CREATED_ID>
    }
  ]
}

And start running SQL queries via your Worker with your Postgres client of choice:

import { Client } from "pg";

export default {
  async fetch(request, env, ctx) {
   
    const client = new Client({ connectionString: env.DATABASE.connectionString });
    await client.connect();

    const result = await client.query("SELECT * FROM pg_tables");
    ...
}

PlanetScale developer experience

PlanetScale was the obvious choice to provide to the Workers community due to it’s unrivaled performance and reliability. Developers can choose from two of the most popular relational databases with Postgres or Vitess MySQL. PlanetScale matches how Cloudflare treats performance and reliability as key features of a developer platform. And with features like query insights and agent driven workflows for improving SQL query performance and branching for deploying code safely, including database changes, the PlanetScale database developer experience is first-class.

Cloudflare users get the exact same PlanetScale database developer experience. Your PlanetScale databases can be deployed directly from Cloudflare with connections managed via Hyperdrive, which already makes your existing regional databases fast with global Workers. This means access to the same PlanetScale database clusters at standard PlanetScale pricing with all features included like query insights and detailed breakdown of usage and costs.


A single node on PlanetScale Postgres starts at $5/month.

Workers placement

With centralized databases, Workers can run right next to your primary database to reduce latency with an explicit placement hint. By default, Workers execute closest to a user request, which adds network latency when querying a central database especially for multiple queries. Instead, you can configure your Worker to execute in the closest Cloudflare data center to your PlanetScale database. In the future, Cloudflare can automatically set a placement hint based on the location of your PlanetScale database and reduce network latency to single digit milliseconds.

{
  "placement": {
    "region": "aws:us-east-1"
  }
}

Coming soon

You can deploy a PlanetScale Postgres database or connect an existing PlanetScale database to Workers today via the Cloudflare dashboard. Everything today is still billed via PlanetScale.

Launching next month, new PlanetScale databases can be billed to your Cloudflare account. 

We are building more with our PlanetScale partners, such as Cloudflare API integration, so tell us what you’d like to see next.

Artifacts: versioned storage that speaks Git

Post Syndicated from Dillon Mulroy original https://blog.cloudflare.com/artifacts-git-for-agents-beta/

Agents have changed how we think about source control, file systems, and persisting state. Developers and agents are generating more code than ever — more code will be written over the next 5 years than in all of programming history — and it’s driven an order-of-magnitude change in the scale of the systems needed to meet this demand. Source control platforms are especially struggling here: they were built to meet the needs of humans, not a 10x change in volume driven by agents who never sleep, can work on several issues at once, and never tire.

We think there’s a need for a new primitive: a distributed, versioned filesystem that’s built for agents first and foremost, and that can serve the types of applications that are being built today.

We’re calling this Artifacts: a versioned file system that speaks Git. You can create repositories programmatically, alongside your agents, sandboxes, Workers, or any other compute paradigm, and connect to it from any regular Git client.

Want to give every agent session a repo? Artifacts can do it. Every sandbox instance? Also Artifacts. Want to create 10,000 forks from a known-good starting point? You guessed it: Artifacts again. Artifacts exposes a REST API and native Workers API for creating repositories, generating credentials, and commits for environments where a Git client isn’t the right fit (i.e. in any serverless function).

Artifacts is available in private beta for any developers on the paid Workers plan, and we’re aiming to open this up as a public beta by early May.

// Create a repo
const repo = await env.AGENT_REPOS.create(name)
// Pass back the token & remote to your agent
return { repo.remote, repo.token }
# Clone it and use it like any regular git remote
$ git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git

That’s it. A bare repo, ready to go, created on the fly, that any git client can operate it against.

And if you want to bootstrap an Artifacts repo from an existing git repository so that your agent can work on it independently and push independent changes, you can do that too with .import():

interface Env {
  ARTIFACTS: Artifacts
}

export default {
  async fetch(request: Request, env: Env) {
    // Import from GitHub
    const { remote, token } = await env.ARTIFACTS.import({
      source: {
        url: "https://github.com/cloudflare/workers-sdk",
        branch: "main",
      },
      target: {
        name: "workers-sdk",
      },
    })

    // Get a handle to the imported repo
    const repo = await env.ARTIFACTS.get("workers-sdk")

    // Fork to an isolated, read-only copy
    const fork = await repo.fork("workers-sdk-review", {
      readOnly: true,
    })

    return Response.json({ remote: fork.remote, token: fork.token })
  },
}

Check out the documentation to get started, or if you want to understand how Artifacts is being used, how it was built, and how it works under the hood: read on.

Why Git? What’s a versioned file system?

Agents know Git. It’s deep in the training data of most models. The happy path and the edge cases are well known to agents, and code-optimized models (and/or harnesses) are particularly good at using git.

Further, Git’s data model is not only good for source control, but for anything where you need to track state, time travel, and persist large amounts of small data. Code, config, session prompts and agent history: all of these are things (“objects”) that you often want to store in small chunks (“commits”) and be able to revert or otherwise roll back to (“history”). 

We could have invented an entirely new, bespoke protocol… but then you have the bootstrap problem. AI models don’t know it, so you have to distribute skills, or a CLI, or hope that users are plugged into your docs MCP… all of that adds friction.

If we can just give agents an authenticated, secure HTTPS Git remote URL and have them operate as if it were a Git repo, though? That turns out to work pretty well. And for non-Git-speaking clients — such as a Cloudflare Worker, a Lambda function, or a Node.js app — we’ve exposed a REST API and (soon) language-specific SDKs. Those clients can also use isomorphic-git, but in many cases a simpler TypeScript API can reduce the API surface needed.

Not just for source control

Artifacts’ Git API might make you think it’s just for source control, but it turns out that the Git API and data model is a powerful way to persist state in a way that allows you to fork, time-travel and diff state for any data.

Inside Cloudflare, we’re using Artifacts for our internal agents: automatically persisting the current state of the filesystem and the session history in a per-session Artifacts repo. This enables us to:

  • Persist sandbox state without having to provision (and keep) block storage around.

  • Share sessions with others and allow them to time-travel back through both session (prompt) state and file state, irrespective of whether there were commits to the “actual” repository (source control).

  • And the best: fork a session from any point, allowing our team to share sessions with a co-worker and have them pick it up from them. Debugging something and want another set of eyes? Send a URL and fork it. Want to riff on an API? Have a co-worker fork it and pick up from where you left off.

We’ve also spoken to teams who want to use Artifacts in cases where the Git protocol isn’t a requirement at all, but the semantics (reverting, cloning, diffing) are. Storing per-customer config as part of your product, and want the ability to roll back? Artifacts can be a good representation of this.

We’re excited to see teams explore the non-Git use-cases around Artifacts just as much as the Git-focused ones.

Under the hood

Artifacts are built on top of Durable Objects. The ability to create millions (or tens of millions+) of instances of stateful, isolated compute is inherent to how Durable Objects work today, and that’s exactly what we needed for supporting millions of Git repos per namespace.

Major League Baseball (for live game fan-out), Confluence Whiteboards, and our own Agents SDK use Durable Objects under the hood at significant scale, and so we’re building this on a primitive that we’ve had in production for some time.

What we did need, however, was a Git implementation that could run on Cloudflare Workers. It needed to be small, as complete as possible, extensible (notes, LFS), and efficient. So we built one in Zig, and compiled it to Wasm.

Why did we use Zig? Three reasons:

  1.  The entire git protocol engine is written in pure Zig (no libc), compiled to a ~100KB WASM binary (with room for optimization!). It implements SHA-1, zlib inflate/deflate, delta encoding/decoding, pack parsing, and the full git smart HTTP protocol — all from scratch, with zero external dependencies other than the standard library.

  2.  Zig gives us  manual control over memory allocation which is important in constrained environments like Durable Objects. The Zig Build System lets us easily share  code between the WASM runtime (production) and native builds (testing against libgit2 for correctness verification).

  3. The WASM module communicates with the JS host via a thin callback interface: 11 host-imported functions for storage operations (host_get_object, host_put_object, etc.) and one for streaming output (host_emit_bytes). The WASM side is fully testable in isolation.

Under the hood, Artifacts also uses R2 (for snapshots) and KV (for tracking auth tokens):


How Artifacts works (Workers, Durable Objects, and WebAssembly)

A Worker acts as the front-end, handling authentication & authorization, key metrics (errors, latency) and looking up each Artifacts repository (Durable Object) on the fly. 

Specifically:

  • Files are stored in the underlying Durable Object’s SQLite database.

    • Durable Object storage has a 2MB max row size, so large Git objects are chunked and stored across multiple rows.

    • We make use of the sync KV API (state.storage.kv)  which is backed by SQLite under the hood.

  •  DOs have ~128MB memory limits: this means we can spawn tens of millions of them (they’re fast and light) but have to work within those limits.

    • We make heavy use of streaming in both the fetch and push paths, directly returning a `ReadableStream<Uint8Array>` built from the raw WASM output chunks.

    • We avoid calculating our own git deltas, instead,  the raw deltas and base hashes are persisted alongside the resolved object. On fetch, if the requesting client already has the base object, Zig emits the delta instead of the full object, which saves bandwidth and memory.

  • Support for both v1 and v2 of the git protocol.

    • We support capabilities including ls-refs, shallow clones (deepen, deepen-since, deepen-relative), and incremental fetch with have/want negotiation.

    • We have an extensive test suite with conformance tests against git clients and verification tests against a libgit2 server designed to validate protocol support.

On top of this, we have native support for git-notes. Artifacts is designed to be agent-first, and notes enable agents to add notes (metadata) to Git objects. This includes prompts, agent attribution and other metadata that can be read/written from the repo without mutating the objects themselves.

Big repos, big problems? Meet ArtifactFS.

Most repos aren’t that big, and Git is designed to be extremely efficient in terms of storage: most repositories take only a few seconds to clone at most, and that’s dominated by network setup time, auth, and checksumming. In most agent or sandbox scenarios, that’s workable: just clone the repo as the sandbox starts and get to work.

But what about a multi-GB repository and/or repos with millions of objects? How can we clone that repo quickly, without blocking the agent’s ability to get to work for minutes and consuming compute?

A popular web framework (at 2.4GB and with a long history!) takes close to 2 minutes to clone. A shallow clone is faster, but not enough to get down to single digit seconds, and we don’t always want to omit history (agents find it useful).

Can we get large repos down to ~10-15 seconds so that our agent can get to work? Well, yes: with a few tricks.

As part of our launch of Artifacts, we’re open-sourcing ArtifactFS, a filesystem driver designed to mount large Git repos as quickly as possible, hydrating file contents on the fly instead of blocking on the initial clone. It’s ideal for agents, sandboxes, containers and other use cases where startup time is critical. If you can shave ~90-100 seconds off your sandbox startup time for every large repo, and you’re running 10,000 of those sandbox jobs per month: that’s 2,778 sandbox hours saved.

You can think of ArtifactFS as “Git clone but async”:

  • ArtifactFS runs a blobless clone of a git repository: it fetches the file tree and refs, but not the file contents. It can do that during sandbox startup, which then allows your agent harness to get to work.

  • In the background, it starts to hydrate (download) file contents concurrently via a lightweight daemon.

  • It prioritizes files that agents typically want to operate on first: package manifests (package.json, go.mod), configuration files, and code, deprioritizing binary blobs (images, executables and other non-text-files) where possible so that agents can scan the file tree as the files themselves are hydrated.

  • If a file isn’t fully hydrated when the agent tries to read it, the read will block until it has.

The filesystem does not attempt to “sync” files back to the remote repository: with thousands or millions of objects, that’s typically very slow, and since we’re speaking git, we don’t need to. Your agent just needs to commit and push, as it would with any repository. No new APIs to learn.

Importantly, ArtifactFS works with any Git remote, not just our own Artifacts. If you’re cloning large repos from GitHub, GitLab, or self-hosted Git infrastructure: you can still use ArtifactFS.

What’s coming?

Our release today is just the beta, and we’re already working on a number of features that you’ll see land over the next few weeks:

  • Expanding the available metrics we expose. Today we’re shipping metrics for key operations counts per namespace, repo and stored bytes per repo, so that managing millions of Artifacts isn’t toilsome.

  • Support for Event Subscriptions for repo-level events so that we can emit events on pushes, pulls, clones, and forks to any repository within a namespace. This will also allow you to consume events, write webhooks, and use those events to notify end-users, drive lifecycle events within your products, and/or run post-push jobs (like CI/CD).

  • Native TypeScript, Go and Python client SDKs for interacting with the Artifacts API

  • Repo-level search APIs and namespace-wide search APIs, e.g. “find all the repos with a package.json file”. 

We’re also planning an API for Workers Builds, allowing you to run CI/CD jobs on any agent-driven workflow.

What will it cost me?

We’re still early with Artifacts, but want our pricing to work at agent-scale: it needs to be cost effective to have millions of repos, unused (or rarely used) repos shouldn’t be a drag, and our pricing should match the massively-single-tenant nature of agents.

You also shouldn’t have to think about whether a repo is going to be used or not, whether it’s hot or cold, and/or whether an agent is going to wake it up. We’ll charge you for the storage you consume and the operations (e.g. clones, forks, pushes & pulls) against each repo.

$/unit

Included

Operations

$0.15 per 1,000 operations

First 10k included (per month)

Storage

$0.50/GB-mo

First 1GB included.

Big, busy repos will cost more than smaller, less-often-used repos, whether you have 1,000, 100,000, or 10 million of them.

We’ll also be bringing Artifacts to the Workers Free plan (with some fair limits) as the beta progresses, and we’ll provide updates throughout the beta should this pricing change and ahead of billing any usage.

Where do I start? 


Artifacts is launching in private beta, and we expect public beta to be ready in early May (2026, to be clear!). We’ll be allowing customers in progressively over the next few weeks, and you can register interest for the private beta directly.

In the meantime, you can learn more about Artifacts by:

Follow the changelog to track the beta as it progresses.

Watch on Cloudflare TV

ClickFix Phishing Campaign Masquerading as a Claude Installer

Post Syndicated from Nicholas Spagnola original https://www.rapid7.com/blog/post/ve-clickfix-phishing-campaign-fake-claude-installer

Overview

It is no secret that phishing campaigns utilizing various ClickFix techniques have been a commonly used method of social engineering. One of the main reasons for this is simply because they work. You know this and Rapid7 does as well. As a company offering managed detection and response (MDR), our customers expect us to be knowledgeable about and able to detect attacks as common as ClickFix campaigns. 

Recently, Rapid7 observed a small grouping of ClickFix events across customers in the EU and US. At the time of discovery, this campaign had very little traction on sites like VirusTotal or within the online security landscape. This campaign was particularly interesting as it appeared to be masquerading as an installer for Claude, an AI tool that has received a considerable amount of attention. 

Using Rapid7 InsightIDR detection rules, our SOC analysts were able to detect and respond to the threat, preventing further compromise. This campaign demonstrates the strength Rapid7 customers get from our MDR service, while peeling back the curtain to provide a real-world example on how we operate behind the scenes. In this blog, we will detail a brief technical analysis of the observed threat actor activities and discuss how this serves as an example of the service we aim to provide our MDR customers. The analysis highlights both the multi-step delivery of the payload as well as the work Rapid7 performs when investigating threats.  

Observed attacker behavior

On April 9, Rapid7 was alerted to mshta executed on a customer asset using the Windows run utility. The alert was generated by the detection rule Attacker Technique – Remote Payload Execution via Run Utility (shell32.dll). This rule will generate an alert when a suspicious process, such as mshta, is added to the RunMRU registry key. This key is important for the detection of ClickFix campaigns, as it tracks the last 26 commands executed by the Windows run utility. One thing that stuck out about this particular mshta command is that the URL, download-version[.]1-5-8[.]com/claude.msixbundle, appeared to be impersonating an MSIX bundle for the popular AI tool, Claude. 

MSIX files are Windows app packages that one would typically see from the Microsoft store, definitely not something you would see being passed as an argument to mshta. While the host was quickly taken down before Rapid7 was able to obtain the claude.msixbundle payload, a copy was obtainable on VirusTotal. Looking at the payload, it does initially appear to be an MSIX bundle. The file header signature, PK, indicates that the file is a ZIP archive and contains a string reference to the MSIX bundle, MicrosoftBing_1.1.37.0_ARM64.msix:

⠀

ClaudeFix_figure1.png

⠀

Exploring the payload deeper, however, reveals an HTML Application (HTA) embedded within the ZIP archive:

ClaudeFix_figure2.png

⠀

The Visual Basic script within the HTA file contains a series of obfuscated strings that are deobfuscated with the following VBS function:

ClaudeFix_figure3.png

⠀

Additionally, one of the functions serves to generate an encoded PowerShell script that will serve as the next step in the chain:

ClaudeFix_figure4.png

⠀

After the deobfuscation routine is complete, these strings contain references to the required objects and function calls to craft and execute – via ShellExec – the following command:

c:\Windows\System32\cmd.exe” /v:on /c “set x=pow&&set y=ershell&&call %windir%\SysWOW64\WindowsPowershell\v1.0\!x!!y! -E [ENCODED COMMAND]

⠀

ClaudeFix_figure5.png

⠀

The encoded PowerShell acts as a staging payload. The script will first generate an MD5 hash value based on the COMPUTERNAME and USERNAME environment variables. It will then take the first 16 characters of the hash value and use it to craft a URL to pull another, much larger, PowerShell script. The script also contains a string deobfuscation routine that is responsible for crafting the following strings to be passed to various .NET functions:

  • Assembly

  • System.Mangement.Automation.AmsiUtils

  • amsiContext

  • NonPublic,Static

  • 0x41414141

ClaudeFix_figure6.png

⠀

The script will then call the deobfuscation routine to craft a call to WriteInt32 in the .NET Marshal library to overwrite the amsiContext field in System.Management.Automation.AmsiUtils with the value 0x41414141. Once amsiContext is overwritten, the script will download and execute the next stage:

ClaudeFix_figure7.png

⠀

The URL is hosting yet another PowerShell script containing highly obfuscated strings and a large byte array. Upon execution of the script, the strings decode to contain the necessary .NET types and method calls to create and execute a PowerShell ScriptBlock. This ScriptBlock is derived from the byte array, which is first base64 decoded and then run through a deobfuscation routine:

ClaudeFix_figure8.png

⠀

This ScriptBlock again contains another series of obfuscated strings and a large byte array containing yet another PowerShell ScriptBlock. Following the execution of the script, the code once again creates and executes a PowerShell ScriptBlock:

ClaudeFix_figure9.png

⠀

This ScriptBlock culminates in a process injection routine using the .NET interoperability library. The code contains a byte array with encrypted shellcode that gets passed through a XOR routine. The script then obtains handles to the following Windows API calls:

  • NtAllocateVirtualMemory

  • Copy

  • NtProtectVirtualMemory

  • NtCreateThreadEx

  • NtWaitForSingleObject

  • NtFreeVirtualMemory

  • NtClose

After obtaining the handles, the script crafts delegate functions for the Windows API calls and invokes the delegates to perform the process injection routine:

ClaudeFix_figure10.png

Importance to Rapid7’s MDR customers

Rapid7 MDR customers receive the security knowledge of our threat intelligence, detection engineering, incident response, and security operations center analysts. Input from all of these sources directly feeds into how we create detections and respond to alerts. Following is an explanation of how we use events like these to further provide and enhance our services for customers. 

As previously mentioned, ClickFix activity is not new. Detection engineers in the MDR service know this and build rules to address these techniques, such as the rule that caught the activity discussed in this blog.. Detection rules are created in response to activity observed in incident response, customer requests, activity observed from the SOC, threat intelligence, and observations of the security landscape. Rapid7’s detection engineers work with the SOC to monitor these rules for efficacy. Rules that are primarily used to detect initial compromise, such as the one that alerted on this campaign, are additionally monitored to identify any new campaigns. 

Once the campaign is identified, our detection engineers research it to create additional rules. They can also perform retroactive threat hunts across the Rapid7 customer base using IOCs or any new behavioral detections created from researching the campaign. Results from researching campaigns like this one then go on to feed threat intelligence and help inform our detection strategy. This campaign provides a great example of how Rapid7 works on the backend to detect and prevent threats in customer environments. 

Mitigation guidance

Monitor the following registry key to watch for potential ClickFix attacks such as the one observed in this case:

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

While Rapid7 MDR customers were covered by the managed SOC, Rapid7 recommends the following actions for containment:

If the activity is not expected, apply containment and review the user’s browsing history for the source of the command. The initial lure is often presented to the user when they attempt to browse the internet for free downloads (media, software, etc.). In some cases the malicious command may have been copied to the user’s clipboard when visiting the initial webpage, and can be viewed by inspecting the source code of the site. If the infection is successful, an information stealer is often executed as the final payload, meaning that any credentials stored on the infected system should be reset as part of restoration.

MITRE ATT&CK techniques

System Binary Proxy Execution: Mshta

T1218.005

Obfuscated Files or Information: Encrypted/Encoded File

T1027.013

Obfuscated Files or Information: Command Obfuscation

T1027.010

Command and Scripting Interpreter: PowerShell

T1059.001

Process Injection

T1055

Indicators of compromise (IOCs)

Cloude.Msixbundle:

  • 2b99ade9224add2ce86eb836dcf70040315f6dc95e772ea98f24a30cdf4fdb97

Domains observed by Rapid7:

  • Oakenfjrod[.]ru

  • download-version[.]1-5-8[.]com

  • download[.]get-version[.]com

Human Trust of AI Agents

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/04/human-trust-of-ai-agents.html

Interesting research: “Humans expect rationality and cooperation from LLM opponents in strategic games.”

Abstract: As Large Language Models (LLMs) integrate into our social and economic interactions, we need to deepen our understanding of how humans respond to LLMs opponents in strategic settings. We present the results of the first controlled monetarily-incentivised laboratory experiment looking at differences in human behaviour in a multi-player p-beauty contest against other humans and LLMs. We use a within-subject design in order to compare behaviour at the individual level. We show that, in this environment, human subjects choose significantly lower numbers when playing against LLMs than humans, which is mainly driven by the increased prevalence of ‘zero’ Nash-equilibrium choices. This shift is mainly driven by subjects with high strategic reasoning ability. Subjects who play the zero Nash-equilibrium choice motivate their strategy by appealing to perceived LLM’s reasoning ability and, unexpectedly, propensity towards cooperation. Our findings provide foundational insights into the multi-player human-LLM interaction in simultaneous choice games, uncover heterogeneities in both subjects’ behaviour and beliefs about LLM’s play when playing against them, and suggest important implications for mechanism design in mixed human-LLM systems.

Вино или гной: Какво се яде и пие в отвъдното според исляма

Post Syndicated from Атанас Шиников original https://www.toest.bg/vino-ili-gnoy-kakvo-se-yade-i-pie-v-otvudnoto-spored-islyama/

Вино или гной: Какво се яде и пие в отвъдното според исляма

Първото тримесечие на календарната година почва с тежък хранителен товар за трите монотеистични религии и техните тукашни вариации. Ако превъртим часовника постепенно назад, най-пресен ще да ни е споменът от таман преминалото великденско преяждане и препиване. Агнета, дроб сарми, яйца, козунаци, вина, ракии, зелени салати след Великия пост – положението е сериозно, отговорно. 

Католическият Великден беше малко преди това – тази година приблизително съвпадаше с еврейския празник Песах (не го наричайте Пасха, защото за еврейската и християнската общност това са различни неща). Парче агнешко месо с кокал, горчиви зелени гарнитури от маруля или цикория, варени яйца, настъргани ябълки, ядки и подправки с вино, безквасен хляб маца, сладкиши, варени моркови и картофи, а накрая – много (наистина щедро разлято!) вино за пиене.

Преди това, застъпил част от нашите постни февруари и март, беше мюсюлманският пост за Рамадан, на който по тукашните земи му казват Рамазан – според турското произношение на арабското име на месеца. Там се пости през деня, ама за сметка на това през нощта се яде предостатъчно: баници, пилафи, баклави – каквото е дал Всевишният. „Хвала на Аллах – казваше един мой познат в Сирия навремето, – накрая на месеца на пост съм наддал с няколко килограма!“

Пък и то яденето си е за хвалба: започва с разговяване (ифтар), тоест прекъсване на поста надвечер с няколко фурми, и продължава с обилни хранения в тъмната част на денонощието. Сутринта преди съмване пак се сяда да се яде – за това хранене в арабския съществува терминът сахур. Та е някак показателно, че Главното мюфтийство в България съветва да не се преяжда по време на свещения месец.

Но нека сега да превъртим часовника напред. Много напред, чак отвъд времето на тукашния свят, за който в арабския език се употребява терминът дунйа – „по-близкото“, „по-ниското“, „настоящият живот“.

Направо ще превъртим не само часовника, но и религиозно-кулинарната игра. Ще нагазим в тема колкото странна за нас, толкова и привична за мюсюлманската теология. Как се яде и пие – не в тоя свят, ами в онзи. За него пък езикът на Пророка от Арабия разполага с термина ахира ‘онова, което иде после, по-сетне, оттатъшното’. А за оттатъшното мюсюлманското Писание, Предание и богословска традиция не пестят детайли. Защото отвъдното битие съвсем не е безплътно, безтелесно и призрачно лишено от сетивни усещания – къде наслади, къде мъчения. В крайна сметка най-популярното название на Рая е Джанна, тоест „Градина“, което и намеква, че животът в оня свят прилича на безкраен отвъден пикник (подобен на онзи, от който Адам и Ева (Хауа’) биват пропъдени).

За теб там има, да не си нито гладен, нито гол. И не ще изпиташ там нито жажда, нито слънчев пек.“ (20:118–119).

Но да не бъда голословен, нека оставим самия текст на Писанието да говори. Разгърнете Корана на сура 76, „Човекът“ (Ал-Инсан) например, и ще видите, че

храната и питието са част от насищащо, всеобхватно, направо холистично, както биха казали в бизнеса и медицината, преживяване на отвъдното.

Праведниците пият от чаши с „добавено питие“ от „Камфор“ (Кафур). Това обаче не е познатото ни вещество, а „извор, от който пият рабите на Аллах“, бликащ в изобилие. Сред наградите на праведниците за тяхното търпение е и „Градина“ (въпросната Джанна), където те са облечени с коприна, облегнати на престоли, без да виждат там ни зной, ни мраз, на сянка под сведени плодове. Обслужват ги със съдове от сребро и с чаши от сребърен кристал; отмерва им се с мярка и им се дава да пият от питие, смесено с „джинджифил“ (занджабил), от извор, наречен Салсабил. Заобикалят ги вечно млади юноши, подобни на разпръснати бисери; облечени са в зелени одежди от коприна и брокат, носят украшения – гривни от сребро – и пият от „чиста напитка“.

Небесните градини раждат колкото праведниците си пожелаят, и то леснодостъпна реколта („сведени плодовете ѝ ниско“, 76:14). Има и грозде сред „градини и лозя“, отредени в спасението за богобоязливите (78:31–32), плодове, фурми и нарове (55:68), че и „лотоси без бодли, и натежали бананови дървета“ (56:28–29). Ала този кулинарен списък не просто не се ограничава с конкретните плодове, изборът е неограничен – добавете и „птиче месо, каквото обичат“ (Коран 56:21), както и „в изобилие плодове и месо, каквито пожелаят“ (52:22). Като че ли млякото и медът стоят по средата между питиетата и храните (малко като нашенското виждане за бирата или бозата като „течна баничка“).

В Рая има и четири вида „реки от вода, която не застоява, и реки от мляко с вкус, който не се променя, и реки от вино, приятно за пиещите, и реки пречистен мед, и в който има за тях от всякакви плодове“ (47:15). Вода, мляко, мед – всичко това звучи приемливо. Водата е особено важна в множеството споменавания на извори. А ако искаме да намерим възможно инструментално обяснение за този факт, може да мислим за Пророка като литературно подобен на Пол Муад’Диб от „Дюн“ на Франк Хърбърт и пустинната планета Аракис. С други думи, в пясъците на древна Арабия водата представлява особена ценност, затова и в отвъдното е силно застъпена. „Градини, сред които реки текат“ е устойчива фигура в описанието на кораничния Рай. Добавете към тях и множеството споменавания на извори.

Но що дири тук виното? Та нали тук, при нас, е напълно възбранено (харам) заедно със свинското, хазарта и ред други неща?

Че и класическото наказание в свещения закон за консумацията му е бой с камшик. Някаква трансмутация, почти по алхимически, да не кажа транссубстанциация, за да не обидя приятелите католици, се е случила с ферментиралата напитка в отвъдното. Освен че тече в реки, то носи наслада, без да носи грях. На всичкото отгоре правоверните не ще ги боли глава, няма да се опияняват и няма да губят разум (37:47, 56:19).

Тук обаче словото на Аллах не говори директно за вино, макар коментаторската традиция изрично да уточнява, че именно то е темата на по-горните знамения. Интересен нюанс въвежда откровението чрез уточнението, че на правоверните „ще им се поднесе запечатано, пребистро питие“ с ухание на мускус, идващо от извора Тасним (83:25–28). Питието в случая е особен вид небесно вино, за което Коранът употребява необичайния термин рахик, за разлика от разпространения иначе хамр. Отделен, но свързан нюанс, е този за употребата на парфюми в отвъдното покрай одеждите и украшенията на праведните, техните ястия и питиета. 

Добре де, сега ще се отклоним още малко, за да ви вменя ход на мислите и ви изпреваря, като попитам:

А къде са девиците?

Онези, 72 на брой, с които мюсюлманският Рай е предимно известен в популярната култура – т.нар. хурии. Ето ги и тях, макар и неуточнено колко: „красавици с големи очи“ (Коран 44:54), „жени с целомъдрен поглед, недокоснати нито от човек преди тях, нито от джин“ (55:56), „хубавици, пазени в шатри“ (55:72), „хубавици с големи очи, подобни на скрити бисери“ (56:22–23), несъмнено отредени за богобоязливите в „градини и лозя, и с напъпили гърди девствени връстнички, и пълни стакани“ (Коран 78:32–34). Но колкото и да е изкушаващо, нека оставим тази отвъдна пикантерия за момент настрани – въпреки че не е съвсем почтено спрямо мюсюлманското Писание и Предание, доколкото хуриите често вървят с темата на настоящото ни разсъждение! – и да се върнем към храната и питието.

Да не си мислите, че храна в отвъдното има само за добрите. Има и за лошите, но служи за назидание и вечно мъчение.

Малко като израза на баща ми „Ще изядеш шамара!“. Ял съм го в тукашния свят – кога щедро, кога пестеливо. Само че шамарът в исляма има отвъдни кулинарни измерения и слиза в стомаха ти като адски огън, по-лош от люта чушка, сорт „Каролина Рийпър“, на прах. Апропо, водата в Ада не служи за утоляване на жаждата. Там тя е инструмент за вечно въздаяние, грешниците в Огъня вкусват „вряща вода и гной“ (38:57). Терминът за този вид вода не е обичайното арабско ма’ – онова, което тече в райските реки, а хамим – вряща течност, „която разкъсва червата“ (47:15).

Листата с напитките за грешниците се отличава с известно разнообразие – освен кипналата вода има и „гнойна вода“ (14:16), „кръв и гной“ (69:36). Това получават те, когато викат към обитателите на Рая и молят за водата или препитанието от Аллах (7:50), а като „викнат за помощ, ще им се помогне с вода като разтопен метал, която изпича лицата“ (18:29) и „кипящ извор да пият“ (88:5).

Но центърът на адското наказание е дървото Закум (аз-Заккум),

злокобната антитеза на дърветата в райската градина и на „дървото на вечността“ (20:120) от изначалната обител на Адам и Ева. На български баба ми казваше „зокум“ на олеандъра (Nerium oleander), от който гледахме няколко храста вкъщи – в тенекии от сирене. Но в кораничния контекст винаги съм си представял въпросното дърво като уродлив, мъчителен и древен аналог на Дървото на болката от „Хиперион“, друга моя любима фантастика на Дан Симънс. Споменато е пряко поне на три места в Корана, а на едно място се говори за „прокълнатото дърво“, сторено за изпитание (17:60). Заблудените, отричащите, казва самият Аллах, ще ядат от него, ще си пълнят от него стомасите и ще пият след това от врящата вода (56:52), защото е дърво, изникващо от дъното на Ада. Плодовете му са като главите на сатаните, от които ядат грешниците, и го примесват с питие от врящата вода (37:63–67). То е храната на всеки грешник, подобна на разтопен метал, кипящ в стомасите (44:44–46).

А това дотук е просто кратка разходка из Корана… Никак не е зле откъм бюлюк (от тур. изобилие), както казваше баба ми. В юдейския Танах, еврейската Библия, тоест онова, което християните наричат Стар завет, че и в християнския Нов завет липсват подобни плътни описания на отвъдното, нали?

А пък аз обичам да казвам, че има религиозни доктрини и традиции, породени от много по-оскъдни основания в дадено Писание. Кораничният текст от VII век колкото завещава на мюсюлманската общност (умма) отговори, толкова отваря пространство за множество въпроси, все важни. Ето, например аз, напълно пристрастно, веднага се запитвам: щом има плодове и меса, „каквито пожелаят“, може ли да си поръчам в отвъдния ресторант сочна свинска вратна пържола? Защото все пак, ако в оня свят има вино, от „което не боли глава“, защо любимото ми барбекю да попада под несправедливите удари на шариата и да остане харам? Или какво точно е птичето месо – знаем, че според някои предания от Пророка в Рая има зелени птици, в чиито гуши и вътрешности се помещават душите на мъчениците (ед.ч. шахид, мн.ч. шухада’) в междинното състояние (барзах) между смъртта на индивида и Съдния ден. Дали тези птици, които, след като вече не са нужни като преносители на душата на шахида, се използват за храната, спомената в Корана? Какви точно са реките на Рая, имат ли си имена, къде текат, защо се говори, че са „под градините“?

Или пък друга тема – не води ли цялото това обилно ядене и пиене до някаква отделителна дейност при обитателите на отвъдното? Следователно да очакваме ли нещо като небесни тоалетни? Ако отвъдното в добрата му част е парк, може ли да предположим, че подобно на Версай от XVII–XVIII век, неговите жители се крият по кьошетата на живия плет, за да откликнат на повика на природата – каквото и да означава „природа“ там? А ако надзърнем към дъното на Ада, как ли точно изглежда дървото Закум? Какви са тези плодове като глави на дяволи, големи ли са, малки ли са, черни ли са, бели ли са, много ли са, как са овесени, какво се случва с грешниците, когато посегнат към тях, та вътрешностите им биват прогорени от разтопен метал? Що за метал е това? Ами докато праведните се отдават на ядене, пиене и разкош в небесния пир, каква е ролята на „хуриите“? И в крайна сметка,

ако не ни харесва плътската конкретика на разказа, възможно ли е напълно да го алегоризираме и така да избегнем обвиненията в прекомерен чувствен буквализъм?

Та нали например виното в старата мюсюлманска мистична поезия на суфите се превръща в символ на опиянението от единението с Всевишния и Неговата любов. Защо да не може да направим същото с всичко останало? Само че преди да го направим според нашето собствено хрумване, е добре да знаем върху какво реално се гради отвъдната кулинария.

(Следва продължение.)

В рубриката „Ориент кафе“ Атанас Шиников поднася любопитни теми, свързани не толкова с горещата политика, колкото с историята и културата на Близкия изток. А той, древен и днешен, е по-близко до нас и съвремието ни, отколкото си представяме.

Карта на купения вот за избори 2026

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/karta-voterfraud/

Когато има желание и ръководството на МВР сериозно се заеме с изборните измами, резултатите идват бързо. Всички бяхме учудени колко добре работи полицията, която „отгоре“ не им вързват ръцете, не се опъва чадър и не ги карат „да се прибират“. Всеки ден ставаме свидетели на поток от снимки на сериозни суми, схеми и фалшива валута, с която се осигуряват гласове на определени партии. Това не е нищо ново в изборния процес в България. Разликата е, че сега го виждаме в реално време.

Снощи ми дадоха идея, че толкова много съобщение за арести и разкрити схеми биха били по-лесно осмислени, ако се сложат на карта. Затова седнах на правих набързо такава. В тази карта се оптивам да събера информацията за тези случаи. Източникът на известните случаи в профилът на Георги Кандев във Facebook и страницата на МВР. Към всеки случай има линк към оригиналния му пост. На картата виждате случаи за поне 810 хил. евро между 18 март и 15 април 2026, т.е. около 80% от обявените от главния секретар на МВР заловени суми. Някои от разкритите случаи нямат упомената точна сума, затова не се вижда на картата. Някои от схемите нямат споменато местоположение или са организирани online, затова не са поместени тук.

Местоположението на случаите в тази карта е приблизително спрямо споменатите градове, села и общини. При всяко отваряне ще е малко различно за тази цел. Поместената информация се базира изцяло на публикациите на лица от МВР и обвиненията за купуване на гласове следва да се докажат в съда от разследващите и прокуратурата, ако последните благоволят да се заемат въобще с тези случаи вместо да опъват чадър. За разлика от МВР, те все още се управляват от незаконен главен прокурор, който се държи на поста именно с цел спокойствие за купения и контролиран вот и атаки срещу длъжностни лица опитващи се да му се противопоставят.

Може да видите картата на цял екран тук.

Този сайт не е обвързан МВР, Георги Кандев или който и да е държавен орган или официално лице. Създаден е без тяхно знание или разрешение на база публична информация и не претендира за изчерпателност или точност на детайлите отвъд това, което е публикувано към дадения момент. Ще го допълвам с още информация, когато стане налична.

Cloudflare Email Service: now in public beta. Ready for your agents

Post Syndicated from Thomas Gauvin original https://blog.cloudflare.com/email-for-agents/

Email is the most accessible interface in the world. It is ubiquitous. There’s no need for a custom chat application, no custom SDK for each channel. Everyone already has an email address, which means everyone can already interact with your application or agent. And your agent can interact with anyone.

If you are building an application, you already rely on email for signups, notifications, and invoices. Increasingly, it is not just your application logic that needs this channel. Your agents do, too. During our private beta, we talked to developers who are building exactly this: customer support agents, invoice processing pipelines, account verification flows, multi-agent workflows. All built on top of email. The pattern is clear: email is becoming a core interface for agents, and developers need infrastructure purpose-built for it.

Cloudflare Email Service is that piece. With Email Routing, you can receive email to your application or agent. With Email Sending, you can reply to emails or send outbounds to notify your users when your agents are done doing work. And with the rest of the developer platform, you can build a full email client and Agents SDK onEmail hook as native functionality. 

Today, as part of Agents Week, Cloudflare Email Service is entering public beta, allowing any application and any agent to send emails. We are also completing the toolkit for building email-native agents: 

  • Email Sending binding, available from your Workers and the Agents SDK 

  • A new Email MCP server

  • Wrangler CLI email commands

  • Skills for coding agents

  • An open-source agentic inbox reference app

Email Sending: now in public beta

Email Sending graduates from private beta to public beta today. You can now send transactional emails directly from Workers with a native Workers binding — no API keys, no secrets management.

export default {
  async fetch(request, env, ctx) {
    await env.EMAIL.send({
      to: "[email protected]",
      from: "[email protected]",
      subject: "Your order has shipped",
      text: "Your order #1234 has shipped and is on its way."
    });
    return new Response("Email sent");
  },
};

Or send from any platform, any language, using the REST API and our TypeScript, Python, and Go SDKs:

curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/email-service/send" \
   --header "Authorization: Bearer <API_TOKEN>" \
   --header "Content-Type: application/json" \
   --data '{
     "to": "[email protected]",
     "from": "[email protected]",
     "subject": "Your order has shipped",
     "text": "Your order #1234 has shipped and is on its way."
   }'

Sending email that actually reaches inboxes usually means wrestling with SPF, DKIM, and DMARC records. When you add your domain to Email Service, we configure all of it automatically. Your emails are authenticated and delivered, not flagged as spam. And because Email Service is a global service built on Cloudflare’s network, your emails are delivered with low latency anywhere in the world.

Combined with Email Routing, which has been free and available for years, you now have complete bidirectional email within a single platform. Receive an email, process it in a Worker, and reply, all without leaving Cloudflare.

For the full deep dive on Email Sending, refer to our Birthday Week announcement. The rest of this post describes what Email Service unlocks for agents.

Agents SDK: your agent is email-native

The Agents SDK for building agents on Cloudflare already has a first-class onEmail hook for receiving and processing inbound email. But until now, your agent could only reply synchronously, or send emails to members of your Cloudflare account. 

With Email Sending, that constraint is gone. This is the difference between a chatbot and an agent.


Email agents receive a message, orchestrate work across the platform, and respond asynchronously.

A chatbot responds in the moment or not at all. An agent thinks, acts, and communicates on its own timeline. With Email Sending, your agent can receive a message, spend an hour processing data, check three other systems, and then reply with a complete answer. It can schedule follow-ups. It can escalate when it detects an edge case. It can operate independently. In other words: it can actually do work, not just answer questions. 

Here’s what a support agent looks like with the full pipeline — receive, persist, and reply:

import { Agent, routeAgentEmail } from "agents";
import { createAddressBasedEmailResolver, type AgentEmail } from "agents/email";
import PostalMime from "postal-mime";

export class SupportAgent extends Agent {
  async onEmail(email: AgentEmail) {
    const raw = await email.getRaw();
    const parsed = await PostalMime.parse(raw);

   // Persist in agent state
    this.setState({
      ...this.state,
      ticket: { from: email.from, subject: parsed.subject, body: parsed.text, messageId: parsed.messageId },
    });

    // Kick off long running background agent task 
    // Or place a message on a Queue to be handled by another Worker

    // Reply here or in other Worker handler, like a Queue handler
    await this.sendEmail({
      binding: this.env.EMAIL,
      fromName: "Support Agent",
      from: "[email protected]",
      to: this.state.ticket.from,
      inReplyTo: this.state.ticket.messageId,
      subject: `Re: ${this.state.ticket.subject}`,
      text: `Thanks for reaching out. We received your message about "${this.state.ticket.subject}" and will follow up shortly.`
    });
  }
}

export default {
  async email(message, env) {
    await routeAgentEmail(message, env, {
      resolver: createAddressBasedEmailResolver("SupportAgent"),
    });
  },
} satisfies ExportedHandler<Env>;

If you’re new to the Agents SDK’s email capabilities, here’s what’s happening under the hood.

Each agent gets its own identity from a single domain. The address-based resolver routes [email protected] to a “support” agent instance, [email protected] to a “sales” instance, and so on. You don’t need to provision separate inboxes — the routing is built into the address. You can even use sub-addressing ([email protected]) to route to different agent namespaces and instances.

State persists across emails. Because agents are backed by Durable Objects, calling this.setState() means your agent remembers conversation history, contact information, and context across sessions. The inbox becomes the agent’s memory, without needing a separate database or vector store.

Secure reply routing is built in. When your agent sends an email and expects a reply, you can sign the routing headers with HMAC-SHA256 so that replies route back to the exact agent instance that sent the original message. This prevents attackers from forging headers to route emails to arbitrary agent instances — a security concern that most “email for agents” solutions haven’t addressed.

This is the complete email agent pipeline that teams are building from scratch elsewhere: receive email, parse it, classify it, persist state, kick off async workflows, reply or escalate — all within a single Agent class, deployed globally on Cloudflare’s network.

Email tooling for your agents: MCP server, Wrangler CLI, and skills

Email Service isn’t only for agents running on Cloudflare. Agents run everywhere, whether it’s coding agents like Claude Code, Cursor, or Copilot running locally or in remote environments, or production agents running in containers or external clouds. They all need to send email from those environments. We’re shipping three integrations that make Email Service accessible to any agent, regardless of where it runs.

Email is now available through the Cloudflare MCP server, the same Code Mode-powered server that gives agents access to the entire Cloudflare API. With this MCP server, your agent can discover and call the Email endpoints to send and configure emails. You can send an email with a simple prompt:

"Send me a notification email at [email protected] from my staging domain when the build completes"

For agents running on a computer or a sandbox with bash access, the Wrangler CLI solves the MCP context window problem that we discussed in the Code Mode blog post — tool definitions can consume tens of thousands of tokens before your agent even starts processing a single message. With Wrangler, your agent starts with near-zero context overhead and discovers capabilities on demand through `–help` commands. Here is how your agent can send an email via Wrangler:

wrangler email send \
  --to "[email protected]" \
  --from "[email protected]" \
  --subject "Build completed" \
  --text "The build passed. Deployed to staging."

Regardless of whether you give your agent the Cloudflare MCP or the Wrangler CLI, your agent will be able to now send emails on your behalf with just a prompt.

Skills

We are also publishing a Cloudflare Email Service skill. It gives your agents complete guidance: configuring the Workers binding, sending emails via the REST API or SDKs, handling inbound email with Email Routing configuration, building with Agents SDK, and managing email through Wrangler CLI or MCP. It also covers deliverability best practices and how to craft good transactional emails that land in inboxes rather than spam. Drop it into your project and your coding agent has everything needed to build production-ready email on Cloudflare.

Open-sourcing tools for email agents

During the private beta, we also experimented with email agents. It became clear that you often want to keep the human-in-the-loop element to review emails and see what the agent is doing.The best way to do that is to have a fully featured email client with agent automations built-in.

That’s why we built Agentic Inbox: a reference application with full conversation threading, email rendering, receiving and storing emails and their attachments, and automatically replying to emails. It includes a dedicated MCP server built-in, so external agents can draft emails for your review before sending from your agentic-inbox. 


We’re open-sourcing Agentic Inbox as a reference application for how to build a full email application using Email Routing for inbound, Email Sending for outbound, Workers AI for classification, R2 for attachments, and Agents SDK for stateful agent logic. You can deploy it today to get a full inbox, email client and agent for your emails, with the click of a button.

We want email agent tooling to be composable and reusable. Rather than every team rebuilding the same inbound-classify-reply pipeline, start with this reference application. Fork it, extend it, use it as a starting point for your own email agents that fit your workflows.

Try it out today

Email is where the world’s most important workflows live, but for agents, it has often been a difficult channel to reach. With Email Sending now in public beta, Cloudflare Email Service becomes a complete platform for bidirectional communication, making the inbox a first-class interface for your agents.

Whether you’re building a support agent that meets customers in their inbox or a background process that keeps your team updated in real time, your agents now have a seamless way to communicate on a global scale. The inbox is no longer a silo. Now it’s one more place for your agents to be helpful.


Watch on Cloudflare TV

Getting started with Apache Iceberg write support in Amazon Redshift – Part 2

Post Syndicated from Sanket Hase original https://aws.amazon.com/blogs/big-data/getting-started-with-apache-iceberg-write-support-in-amazon-redshift-part-2/

In Getting started with Apache Iceberg write support in Amazon Redshift – part 1, you learned how to create Apache Iceberg tables and write data directly from Amazon Redshift to your data lake. You set up external schemas, created tables in both Amazon Simple Storage Service (Amazon S3) and S3 Tables, and performed INSERT operations while maintaining ACID (Atomicity, Consistency, Isolation, Durability) compliance.

Amazon Redshift now supports DELETE, UPDATE, and MERGE operations for Apache Iceberg tables stored in Amazon S3 and Amazon S3 table buckets. With these operations, you can modify data at the row level, implement upsert patterns, and manage the data lifecycle while maintaining transactional consistency using familiar SQL syntax. You can run complex transformations in Amazon Redshift and write results to Apache Iceberg tables that other analytics engines like Amazon EMR or Amazon Athena can immediately query.

In this post, you work with customer and orders datasets that were created and used in the previously mentioned post to demonstrate these capabilities in a data synchronization scenario.

Solution overview

This solution demonstrates DELETE, UPDATE, and MERGE operations for Apache Iceberg tables in Amazon Redshift using a common data synchronization pattern: maintaining customer records and orders data across staging and production tables. The workflow includes three key operations:

  • DELETE – Remove customer records based on opt-out requests
  • UPDATE – Modify existing customer information
  • MERGE – Synchronize order data between staging and production tables using upsert patterns
Figure : solution overview

Figure 1: solution overview

The solution uses a staging table (orders_stg) stored in an S3 table bucket for incoming data and reference tables (customer_opt_out) in Amazon Redshift for managing data lifecycle operations. With this architecture, you can process changes efficiently while maintaining ACID compliance across both storage types.

Prerequisites

For this walkthrough, you should have completed the setup steps from Getting started with Apache Iceberg write support in Amazon Redshift – part 1, including:

  • Create an Amazon Redshift data warehouse (provisioned or Serverless)
  • Set up the required IAM role (RedshifticebergRole) with appropriate permissions
  • Create an Amazon S3 bucket and S3 Table bucket
  • Configure AWS Glue Data Catalog database and setting up access
  • Set up AWS Lake Formation permissions
  • Create the customer Apache Iceberg table in Amazon S3 standard buckets with sample customer data
  • Create the orders Apache Iceberg table in Amazon S3 Table buckets with sample order data
  • Amazon Redshift data warehouse on p200 version or higher

Data preparation

In this section, you set up the sample data needed to demonstrate MERGE, UPDATE, and DELETE operations. To prepare your data, complete the following steps:

  1. Log in to Amazon Redshift using Query Editor V2 with the Federated user option.
  2. Create the orders_stg and customer_opt_out tables with sample data:
CREATE TABLE "iceberg-write-blog@s3tablescatalog".iceberg_write_namespace.orders_stg
(
customer_id BIGINT,
order_id BIGINT,
Total_order_amt DECIMAL(10,2),
Total_order_tax_amt REAL,
tax_pct DOUBLE PRECISION,
order_date DATE,
order_created_at_tz TIMESTAMPTZ,
is_active_ind BOOLEAN
)
USING ICEBERG;
INSERT INTO "iceberg-write-blog@s3tablescatalog".iceberg_write_namespace.orders_stg
(order_date, order_id, customer_id, total_order_amt, total_order_tax_amt, tax_pct, order_created_at_tz, is_active_ind)
VALUES
('2024-11-11', 1016, 10, 167.45, 13.40, 0.08, '2024-11-11 06:55:00-06:00', true),
('2024-11-12', 1017, 15, 34.99, 2.80, 0.08, '2024-11-12 23:30:30-06:00', true),
('2024-11-09', 1014, 9, 500.60, 56.80, 0.09, '2024-11-09 16:20:55-06:00', true),
('2024-11-10', 1015, 5, 329.85, 33.51, 0.08, '2024-11-10 11:45:30-06:00', true);
select * from "iceberg-write-blog@s3tablescatalog".iceberg_write_namespace.orders_stg;
Figure 2: orders_stg result set

Figure 2: orders_stg result set

CREATE TABLE dev.public.customer_opt_out
(
customer_id bigint,
customer_name varchar,
opt_out_ind char(1),
cust_rec_upd_ind char(1)
);
INSERT INTO dev.public.customer_opt_out VALUES
(9, 'Customer9 Martinez', 'Y', 'N'),
(12, 'Customer12 Thomas', 'Y', 'N'),
(13, 'Customer13 Albon', 'N', 'Y'),
(14, 'Customer14 Oscar', 'N', 'Y');
select * from dev.public.customer_opt_out;
Figure 3: customer_opt_out result set

Figure 3: customer_opt_out result set

You can now use the orders_stg and customer_opt_out tables to demonstrate data manipulation operations on the orders and customer tables created in the prerequisite section.

MERGE

MERGE conditionally inserts, updates, or deletes rows in a target table based on the results of a join with a source table. You can use MERGE to synchronize two tables by inserting, updating, or deleting rows in one table based on differences found in the other table.

To perform a MERGE operation:

  1. Verify that the current data in the orders table for order IDs 1014, 1015, 1016, and 1017.You loaded this sample data in Part 1:
select * from "iceberg-write-blog@s3tablescatalog".iceberg_write_namespace.orders
where order_id in (1014,1015,1016,1017);
Figure 4: orders data for existing orders for orders in orders_stg

Figure 4: orders data for existing orders for orders in orders_stg

The orders table contains existing rows for order IDs 1014 and 1015.

  1. Run the following MERGE operation using order_id as the key column to match rows between the orders and orders_stg tables:
MERGE INTO "iceberg-write-blog@s3tablescatalog".iceberg_write_namespace.orders
USING "iceberg-write-blog@s3tablescatalog".iceberg_write_namespace.orders_stg
ON orders.order_id = orders_stg.order_id
WHEN MATCHED THEN UPDATE 
SET
customer_id         = orders_stg.customer_id,
total_order_amt     = orders_stg.total_order_amt,
total_order_tax_amt = orders_stg.total_order_tax_amt,
tax_pct             = orders_stg.tax_pct,
order_date          = orders_stg.order_date,
order_created_at_tz = orders_stg.order_created_at_tz,
is_active_ind       = orders_stg.is_active_ind
WHEN NOT MATCHED THEN INSERT
VALUES 
(orders_stg.customer_id,orders_stg.order_id,orders_stg.total_order_amt,orders_stg.total_order_tax_amt,orders_stg.tax_pct,orders_stg.order_date,orders_stg.order_created_at_tz,orders_stg.is_active_ind);

The operation updates existing rows (1014 and 1015) and inserts new rows for order IDs that don’t exist in the orders table (1016 and 1017).

  1. Verify the updated data in the orders table:
select * from "iceberg-write-blog@s3tablescatalog".iceberg_write_namespace.orderswhere order_id in (1014,1015,1016,1017);
Figure 5: merged data on orders from orders_stg

Figure 5: merged data on orders from orders_stg

The MERGE operation performs the following changes:

  • Updates existing rows – Order IDs 1014 and 1015 have updated total_order_amt and total_order_tax_amt values from the orders_stg table
  • Inserts new rows – Order IDs 1016 and 1017 are inserted because they don’t exist in the orders table

This demonstrates the upsert pattern, where MERGE conditionally updates or inserts rows based on the matching key column.

UPDATE

UPDATE modifies existing rows in a table based on specified conditions or values from another table.

Update the customer Apache Iceberg table using data from the customer_opt_out Amazon Redshift native table. The UPDATE operation uses the cust_rec_upd_ind column as a filter, updating only rows where the value is ‘Y’.

To perform an UPDATE operation:

  1. Verify the current customer_name values for customer IDs 13 and 14 in customer_opt_out and customer (loaded this sample data in Part 1) tables:
select * from dev.public.customer_opt_out
where cust_rec_upd_ind = 'Y';
Figure 6: verify existing customer data for customers from customer_opt_out

Figure 6: verify existing customer data for customers from customer_opt_out

select customer_id,customer_name from dev.demo_iceberg.customer
where customer_id in(13,14);
Figure 7: verify existing customer name for customers from customer_opt_out

Figure 7: verify existing customer name for customers from customer_opt_out

  1. Run the following UPDATE operation to modify customer names based on the cust_rec_upd_ind from customer_opt_out:
UPDATE dev.demo_iceberg.customerSET customer_name = customer_opt_out.customer_name
FROM dev.public.customer_opt_out
WHERE customer_opt_out.cust_rec_upd_ind = 'Y'and customer.customer_id = customer_opt_out.customer_id;
  1. Verify the changes for customer IDs 13 and 14:
select customer_id,customer_name from dev.demo_iceberg.customer where customer_id in(13,14) order by 1;
Figure 8: updated customer names in customer table

Figure 8: updated customer names in customer table

The UPDATE operation modifies the customer_name values based on the join condition with the customer_opt_out table. Customer IDs 13 and 14 now have updated names (Customer13 Albon and Customer14 Oscar).

DELETE

DELETE removes rows from a table based on specified conditions. Without a WHERE clause, DELETE removes all the rows from table.

Delete rows from the customer Apache Iceberg table using data from the customer_opt_out Amazon Redshift native table. The DELETE operation uses the opt_out_ind column as a filter, removing only rows where the value is ‘Y’.

To perform a DELETE operation:

  1. Verify the opt-out indicator data in the customer_opt_out table:
select * from dev.public.customer_opt_out
where opt_out_ind = 'Y';
Figure 9: verify customer records for opt out

Figure 9: verify customer records for opt out

  1. Verify the current customer data for customer IDs 9 and 12:
select * from dev.demo_iceberg.customerwhere customer_id in(9,12);
Figure 0: verify existing customers data in customer table for opt out

Figure 10: verify existing customers data in customer table for opt out

  1. Review the query execution plan:
EXPLAINDELETE FROM demo_iceberg.customerUSING public.customer_opt_out
WHERE customer.customer_id = customer_opt_out.customer_id
AND customer_opt_out.opt_out_ind = 'Y';
Figure 1: query plan for the DELETE queryThe execution plan shows Amazon S3 scans for Apache Iceberg format tables, indicating that Amazon Redshift removes rows directly from the Amazon S3 bucket.

Figure 11: query plan for the DELETE query. The execution plan shows Amazon S3 scans for Apache Iceberg format tables, indicating that Amazon Redshift removes rows directly from the Amazon S3 bucket.

  1. Run the following DELETE operation:
DELETE FROM demo_iceberg.customer
USING public.customer_opt_out
WHERE customer.customer_id = customer_opt_out.customer_id
AND customer_opt_out.opt_out_ind = 'Y';
  1. Verify that the rows were removed:
select * from dev.demo_iceberg.customer where customer_id in(9,12);
Figure 2: result set from customer table for opt out customer after delete

Figure 12: result set from customer table for opt out customer after delete

The query returns no rows, confirming that customer IDs 9 and 12 were successfully deleted from the customer table.

Best practices

After performing multiple UPDATE or DELETE operations, consider running table maintenance to optimize read performance:

  • For AWS Glue tables – Use AWS Glue table optimizers. For more information, see Table optimizers in the AWS Glue Developer Guide.
  • For S3 Tables – Use S3 Tables maintenance operations. For more information, see S3 Tables maintenance in the Amazon S3 User Guide.

Table maintenance merges and compacts deletion files generated by Merge-on-Read operations, improving query performance for subsequent reads.

Conclusion

You can use Amazon Redshift support for DELETE, UPDATE, and MERGE operations on Apache Iceberg tables to build data architectures that combine warehouse performance with data lake scalability. You can modify data at the row level while maintaining ACID compliance, giving you the same flexibility with Apache Iceberg tables as you have with native Amazon Redshift tables.

Get started:

About the authors

Sanket Hase

Sanket Hase

Sanket is an Engineering Manager with the Amazon Redshift team, leading query execution teams in the areas of data lake analytics, hardware-software co-design, and vectorized query execution.

Raghu Kuppala

Raghu Kuppala

Raghu is an Analytics Specialist Solutions Architect experienced working in the databases, data warehousing, and analytics space. Outside of work, he enjoys trying different cuisines and spending time with his family and friends.

Ritesh Sinha

Ritesh is an Analytics Specialist Solutions Architect based out of San Francisco. He has helped customers build scalable data warehousing and big data solutions for over 16 years. He loves to design and build efficient end-to-end solutions on AWS. In his spare time, he loves reading, walking, and doing yoga.

Sundeep Kumar

Sundeep Kumar

Sundeep is a Sr. Specialist Solutions Architect at Amazon Web Services (AWS), helping customers build data lake and analytics platforms and solutions. When not building and designing data lakes, Sundeep enjoys listening to music and playing guitar.

Get to insights faster using Notebooks in Amazon SageMaker Unified Studio

Post Syndicated from Praveen Kumar original https://aws.amazon.com/blogs/big-data/get-to-insights-faster-using-notebooks-in-amazon-sagemaker-unified-studio/

In this post, we demonstrate how Notebooks in Amazon SageMaker Unified Studio help you get to insights faster by simplifying infrastructure configuration. You’ll see how to analyze housing price data, create scalable data tables, run distributed profiling, and train machine learning (ML) models within a single notebook environment.

Data scientists and analysts often spend days configuring infrastructure and managing authentication across multiple data sources before they can begin analysis. When working with data across Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Snowflake, and local files, teams face repeated authentication setup, manual compute scaling decisions, and tool-switching overhead that delays insights.

Notebooks in Amazon SageMaker Unified Studio provide instant access to 12+ data sources, compute scaling from local to distributed processing, and AI-powered code generation within a single browser-based environment. You’ll learn to use polyglot programming, multi-engine compute, and AI-assisted development to accelerate your path from question to insight.

What are Notebooks in Amazon SageMaker Unified Studio?

Notebooks in Amazon SageMaker Unified Studio provide an interactive environment for data analysis, exploration, engineering, and machine learning workflows. It delivers five integrated capabilities:

  • Polyglot programming: Write code in Python and SQL interchangeably within the same notebook environment
  • Unified data access: Connect instantly to data stored in Amazon S3, AWS Glue Data Catalog, Apache Iceberg tables, and third-party sources like Snowflake and BigQuery
  • Native visualization: Create charts directly from Python and SQL results for immersive data analytics
  • AI-powered development: Generate code through natural language prompts using SageMaker Data Agent, with an intelligent chat interface for data analytics, data science, and ML tasks
  • Flexible compute: Scale from basic instances to GPU-powered environments as your needs grow

Architecture

This section covers the architecture of Notebooks, which delivers enterprise-scale analytics with browser-based simplicity through a cloud-native architecture that integrates multiple compute engines, diverse data sources, and AI-powered assistance.

Presentation layer

You access the notebook interface through Amazon SageMaker Unified Studio, interacting with a familiar interface featuring code cells for execution, markdown cells for documentation, and visualization cells for charts and tables.

Compute layer

A dedicated notebook server manages your kernel lifecycle and session state. Key components include a Language Server for code completion, a Python 3.11 runtime with pre-loaded data science libraries, and a Polyglot Kernel that handles your Python, PySpark, and SQL execution within the same notebook. Persistent Amazon Elastic Block Store (Amazon EBS) storage backs each notebook you create.

Execution layer

Notebooks support multiple execution engines, automatically routing your code to the optimal processing engine. In-memory execution handles your smaller datasets and rapid prototyping. Apache Spark via Amazon Athena provides distributed processing for your large-scale analytics via Spark Connect. Native connectivity to Amazon Athena (Trino), Amazon Redshift, Snowflake, and BigQuery processes your SQL queries.

Data Integration

You get unified access to 12+ data sources including AWS-native (Amazon S3, AWS Glue, Amazon Athena, Amazon Redshift) and third-party (Snowflake, BigQuery, PostgreSQL, MySQL) data sources. For the latest supported data sources, see Connect to data sources .

AI layer

The SageMaker Data Agent operates in two modes to assist you: an Agent Panel for multi-step analytical workflows and Inline Assistance for focused, cell-level code generation. For a detailed overview, see Accelerate context-aware data analysis and ML workflows with Amazon SageMaker Data Agent .

Security is embedded throughout the architecture to protect your work. Data access respects your AWS Identity and Access Management (AWS IAM) permissions. The notebook and the agent can only access data sources you’re authorized to use. Communication between components uses encrypted channels, and your notebook storage is encrypted at rest. The AI agent includes built-in guardrails to help prevent destructive operations and logs interactions for your compliance and auditing purposes.

Prerequisites

Before you begin, you need:

  • An AWS account with appropriate permissions to create Amazon SageMaker Unified Studio resources. See Set up IAM-based domains for complete permission requirements.
  • Basic familiarity with Python programming and SQL queries
  • Understanding of data analysis concepts and ML workflows
  • Access to the sample housing dataset (provided in the walkthrough)

Getting started with Notebooks

To get started, open the Amazon SageMaker console and choose Get started.

You will be prompted either to select an existing AWS Identity and Access Management (AWS IAM) role that has access to your data and compute, or to create a new role. For this walkthrough, choose Create a new role and leave the other options at their defaults.

Choose Set up. It takes a few minutes to complete your environment.

Use case

In this post, you’ll use a Notebook and the SageMaker Data Agent to perform the following:

  1. Working with dataset: Upload sample dataset housing.csv and explore with data explorer
  2. Polyglot programming: Query dataframes with SQL via DuckDB
  3. Multi-engine access via AWS Glue: Create an AWS Glue table to unlock Athena SQL/Spark engines for distributed processing
  4. Advanced analytics: Use Athena Spark for data profiling
  5. AI-assisted development: Generate profiling and ML code with Data Agent
  6. ML workflow: Train Random Forest model and evaluate results

First, let’s walk through the interface and explore its core capabilities.

Understanding the interface

The Notebooks interface follows familiar notebook conventions with cells for code execution and markdown for documentation. Within the notebook, you’ll see your current programming environment (such as Python 3.11) and compute profile specifications. The interface allows you to:

  • Access your data by browsing files, exploring data catalogs, and managing third-party connections
  • Monitor variables created within your notebook context
  • Scale compute resources on demand by adjusting virtual CPUs and RAM based on your workload requirements, even scaling up to GPU instances
  • Manage packages by installing and configuring Python packages as needed

Working with the dataset

For this walkthrough, you’ll use the housing.csv sample dataset which you can download from this page. (the file is named canvas-sample-housing.csv on the linked page). Choose the Files icon in the left panel and choose the Local tab. Upload the CSV file to the notebook on the Local tab.

Notebooks provide you with instant access to your data assets. Using the data explorer, you can browse your AWS Glue Data Catalog, Amazon S3 table catalogs, Amazon S3 buckets, and configured third-party connections.

Choose the three-dot options menu.

Choose Read as dataframe, then run the inserted cell in the notebook to view the results.

import pandas as pd
<<df_csv_xxxx>> = pd.read_csv('housing.csv')
<<df_csv_xxxx>>

When you return a dataframe, Notebooks render it in a rich table format with automatic data profiling.

Polyglot programming: Python and SQL together

One of the most powerful features in Notebooks is the interoperability between Python and SQL. After you load data into a Python dataframe, you can immediately query it using SQL. For example, to calculate total population and household by ocean proximity, you can run:

select sum(population) ,sum(households),ocean_proximity 
from<<df_csv_xxxx>> 
group byocean_proximity

The notebook’s autocomplete functionality recognizes dataframes in your context, making SQL queries intuitive.

This SQL query runs on DuckDB (an in-memory SQL database engine), which requires no separate installation or server maintenance on your part. DuckDB’s lightweight design integrates into Python, Java, and other environments, making it ideal for your rapid interactive data analysis. For distributed processing needs, you can use engines such as Apache Spark or Trino after creating an AWS Glue table for this dataset.

Create an AWS Glue table for the dataset

After you create an AWS Glue table, you can query the dataset using various AWS Glue catalog-compatible engines, including Amazon Athena SQL (Trino) and Amazon Athena Spark. These engines deliver optimal price-performance for your specific workload requirements.

Start by creating an AWS Glue database. To do that, create a new cell in the notebook by choosing SQL and selecting Amazon Athena (SQL).

Run this SQL to create a database: create database demo;

Next, go to data explorer and choose +Add on the top left, then choose Create table. Choose the database you created earlier and enter a name for the table. Upload the housing.csv dataset file used earlier. Continue by choosing Next in the side panel to create the table.

Next, let’s run a sample SQL query in a new cell using Amazon Athena SQL:

select sum(population) , sum(households), ocean_proximity 
fromdemo.housing
group by ocean_proximity

Advanced capabilities with Athena Spark

Before you can build an ML model to predict house prices, let’s analyze the dataset further and run data profiling for additional insights. For advanced exploration, you can use Amazon Athena Spark within your notebook.To do that, you’ll create a new Python cell which has a built-in Spark session. Run the following code to check the Spark version:

# Verify Spark version
spark.version

Using the SageMaker Data Agent for data profiling

Instead of writing boilerplate code manually, you can use the built-in generative AI capability.

Prompt: “Perform data profiling and create visualization for housing table”

The AI assistant generates comprehensive profiling code for you, including basic statistics calculation, column-level profiling, data type analysis, and missing value detection.

The agent accessed your AWS Glue Data Catalog, understood your housing table structure, and generated profiling code tailored to your specific columns and data types. This context awareness reduces the trial-and-error cycle you’d normally face when adapting generic code snippets to your environment. Review the generated code and run it. The fast response times help you iterate on your analysis efficiently.

If you encounter an error, you can resolve it using Fix with AI as shown in the following figure. When errors occur during execution, the “Fix with AI” feature analyzes the traceback, diagnoses the root cause, and generates corrected code, so you can keep your analysis moving forward.

Training ML models

Next, you’ll use the data agent to generate code for training a model that predicts housing prices.

Prompt: “Generate code to train a model that predicts housing prices. Use table housing.”

The AI assistant generates end-to-end code for you that:

  1. Reads housing data from AWS Glue catalog using Amazon Athena Spark and converts to pandas
  2. Converts string columns to numeric, encodes using one-hot encoding and removes missing values
  3. Trains a Random Forest model to predict median house values
  4. Evaluates model performance (RMSE, MAE, R-square)
  5. Displays top 10 most important features for predictions

This multi-step orchestration saves you hours of development time by handling the entire workflow from data access to model evaluation.

If you encounter an error, you can resolve it using Fix with AI available in the results traceback section.

This workflow showcased Notebooks’ unified capabilities: you uploaded files locally, created AWS Glue tables for multi-engine access, used Amazon Athena Spark for distributed profiling, and used AI-assisted ML development to predict housing prices. All of this happened within a single notebook environment without switching tools.

Key benefits and best practices

Notebooks in Amazon SageMaker Unified Studio deliver several advantages:

  • Faster time to insights: With traditional environments, you might spend hours on configuration before analysis begins. Notebooks bypass this overhead, so you can start work immediately.
  • Improved collaboration: You can share notebooks with consistent environments, supporting reproducibility and reducing “works on my machine” issues.
  • Reduced complexity: You can access multiple data sources and compute engines from one interface rather than navigating separate tools for each data source or processing engine.
  • AI-accelerated development: Generate task-specific code and receive intelligent suggestions, reducing time spent on repetitive coding tasks.
  • Scalable performance: Handle datasets from megabytes to petabytes with appropriate compute resources. The system scales automatically as data volumes grow.

Best practices

  1. Start with appropriate compute profiles by beginning with smaller instances and scaling up as your needs grow.
  2. Use AI assistance with natural language prompts for your repetitive tasks and complex operations.
  3. Combine engines strategically by using Amazon Athena Spark for your large-scale processing, Amazon Redshift for data warehousing and other specialized engines for your specific workloads.
  4. Document your work using markdown cells to create living documentation alongside your code.
  5. Organize using multiple cells by breaking the complex workflows into logical steps for better readability and debugging.

Cleaning up

To avoid incurring future charges, delete the resources you created in this walkthrough:

  1. In the Amazon SageMaker Unified Studio console, navigate to the Notebook page
  2. Delete the notebook
  3. Delete the demo database and housing table from the AWS Glue Data Catalog
  4. Delete Amazon SageMaker Unified Studio domain created during this walkthrough
  5. If you created a new IAM role specifically for this walkthrough, delete it from the IAM console

Conclusion

In this post, we demonstrated how Notebooks in Amazon SageMaker Unified Studio help you work more efficiently and deliver insights more quickly. By combining familiar notebook interfaces with enterprise-scale compute, multi-engine support, and generative AI assistance, teams can streamline data and AI workflows.

The integration of Python and SQL, instant access to diverse data sources, and intelligent code generation capabilities make Notebooks a valuable tool for modern data teams. Teams can perform exploratory data analysis, build complex data pipelines, or train ML models with the flexibility and power needed within a single, intuitive environment.

Ready to get started? Create your first notebook in Amazon SageMaker Unified Studio and begin analyzing data within minutes.

Explore additional capabilities:

  • Time series analysis workflows with seasonal decomposition and forecasting
  • Natural language processing pipelines for text classification and sentiment analysis
  • Integration with Amazon SageMaker Model Registry for ML model versioning
  • Advanced Spark optimization techniques for petabyte-scale processing

Learn more:

About the authors

Praveen Kumar

Praveen Kumar is a Principal Analytics Solutions Architect at AWS with expertise in designing, building, and implementing modern data and analytics applications using cloud-based services. His areas of interest are serverless technology, data governance, and data-driven AI applications.

Majisha Namath Parambath

Majisha Namath Parambath is a Principal Engineer at Amazon SageMaker, bringing over a decade of experience at AWS to her role. She spearheads critical initiatives for Amazon SageMaker Unified Studio, the next-generation service that provides comprehensive data analytics and interactive machine learning capabilities with an emphasis on agentic systems. Her expertise encompasses system design, architecture, and cross-functional execution, with particular attention to security, performance, and reliability at enterprise scale. When she’s not engineering solutions, Majisha enjoys reading, cooking, and hitting the slopes for skiing.

Siddharth Gupta

Siddharth Gupta is heading Generative AI within SageMaker’s Unified Experiences. His focus is on driving agentic experiences, where AI systems act autonomously on behalf of users to accomplish complex tasks. Previously, he led edge machine learning solutions at AWS. His work focuses on improving how developers and data scientists interact with AI, creating more intuitive data integrations and better tools for building and deploying machine learning models. An alumnus of the University of Illinois at Urbana-Champaign, he brings extensive experience from his roles at Yahoo, Glassdoor, and Twitch. You can reach out to him on LinkedIn.

Избори 2026 – четири карти за секциите в България и чужбина

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/iz2026-karti/

Тази година има няколко различни ресурса, с които може да се запознаете с местата за гласуване в страната и в чужбина. Някои – като картата на МВнР и Софийска община ги има от последните няколко вота през 2024-та. Други се публикуват за пръв път сега.

Glasuvam.org

Започвам с картата на секциите в чужбина, която поддържам от 13 години и 15 вота до сега. Всички предходни ще намерите на основната страница на проекта. Самата карта ще намерите тук. Повече за секциите ще прочетете в предходната ми статия заедно с още една карта показваща къде е машинният вот в чужбина. В по-ранна статия показах и разликата между отворените сега секции и предишни години.

Данните за картата събирам от заповедите на МВнР. Обикновено сам ги намирам и поставям на картата. В последните години седмица преди вота публикуват и таблица с адресите, а от предишния вот и карта. От там взимам по-точно местоположение и изменени адреси преди изборния ден. В последните три дни, например, има три секции със изменен адрес и още две, които бяха без адрес, но вече са със заповеди.

При публикуване на картата и при изменение на адресите уведомявам с индивидуални email-и всички абонирани за бюлетина на Glasuvam.org заедно със съвети за деня на гласуване. Преди и след това пускам също съобщения и новини, като например за процеса на заявления, промени в начина на гласуване и прочие. Към този момент има над 3100 абонирани за бюлетина. Анонимизираното разпределение от къде са се вижда на картата на заглавната страница на проекта.

В последните няколко години картата и проекта са с логото на Демократична България като част от усилията на Да, България в помощ на българите зад граница. На тези избори може да подкрепите кандидатите и програмата с номер 7 в бюлетината. Призовавам ви да разгледате профилите им, защото има не само прекрасни хора, кои и прекрасни истории, стратегии и опит зад тях. Както често казвам, сред тях ще намерите хората с план като контрапункт на хората със схема, за които съм писал премного до сега.

Новата карта на ЦИК

Буквално преди часове за пръв път ЦИК публикува карта на всички секции в страната и чужбина. Данните за чужбина съвпадат с тези от картата на МВнР, която ще спомена след малко. В България секциите имаха публикувани адреси до сега, но за пръв път ги виждам поставени на картата за цялата страна. Опитах се да го направя преди години, но се отказах след като поне една четвърт не успях да открия. Например „старото читалище“ в някое село, както често се случва.

Към този момент картата показва местата и секциите, както и броят гласоподаватели в тях. Разрових се в кода и данните, които зарежда страницата и има функционалност за показване на активност, резултати, PDF-и и видео. Към този момент са изключени, но предполагам, че в деня на изборите ще публикуват текущи данни, а след това може би резултати и излъчване на живо от преброяването. Надявам се да е така и за тази цел да е предвиден кода в страницата.

Картата ще намерите с банер на страницата на ЦИК или направо през този линк. С филтрите може да изберете секциите в чужбина или за цяла България или за определена област. Може също да покажете обобщена информация по РИК или държави.

Картата на София

Столична община публикува портал вече няколко вота подред с цялата нужна информация за изборите. Там ще намерите гео портал и карта на всички секции. В допълнение на информацията, която ЦИК публикува днес, картата на Столична община показва и районът, в който гласуват в дадената секция, както и дали е достъпна за инвалиди. Тук виждате, например, една секция в Лозенец.

За съжаление, не мога да показа на картата в коя секция би следвало да гласува Пеевски, защото както BIRD писаха преди четири години, според ГРАО той няма право да бъде поместен в никой изборен списък. Защо не отговаря на условията да гласува, а се кандидатира и е бил депутат междувременно, ЦИК отказва да отговори или провери.

Картата на Външно

Министерство на Външните Работи публикува втори вот подред карта на секциите в чужбина. Заедно с това предоставя и таблица с адресите на секциите на български и английски. В предишни години тези адреси се събираха от общото усилие на доброволци и сверяваха със заповедите публикувани от МВнР. Последните са сканирани, отделни документи и беше много трудоемко да се извлече някаква информация.

Картата им е обикновена Google Maps карта, но с последните промени в приложението им позволява да я добавите като слой на картата, която много използват за навигация. Така за някои може да е по-удобно да намерят секциите. Не работи обаче с Apple Maps, но тогава се отваря като страница.

Бонус – карта на активните българи в чужбина

След всеки вот използвам анонимизираните данни, които платформата на Glasuvam.org събира, за да направя анализ за движението на българи в чужбина. Не пазя лична информация за хора, макар тя да е достъпна в изборните списъци, а само хешове на публичните записи от заявленията за гласуване. На тяхна база мога да направя оценка за това как някои българи са се местили по света приемайки, че заявлението им за гласуване отчита пребиваване. Разбира се, част от тях може да са само на почивка и да има съвпадение на имената.

Повече за методологията как изчиствам тези и други проблеми съм описал в статията за първата карта, която направих преди 10 години. За последно публикувах карта след изборите през 2021-та. Направих анализа и след изборите през 2024-та, но не я бях публикувал до сега. Може да я намерите на този линк. Препоръчвам първо да прочетете предходните статии с разясненията, за да я разберете.

Доколкото картата умишлено не предоставя възможност за проследяване на отделни хора, тя дава обща картинка за движението на миграцията ни. Например кои градове биват напускани от хора и в кои има прираст. Разбира се, това далеч не е представително и съм го описал подробно в миналото. Картата има за цел колкото да предостави обща картина, колкото и да има естетическа стойност, поне в моите очи.

Показва също какво е възможно да бъде постигнато с данните публикувани от избирателните списъци, особено тези в България, ако някой наистина се заеме. Призовавах доста години наред да се спре с публикуването им и да се премине към проверка през защитена услуга подобна на тази, която има при ГРАО. За съжаление, това не се случи.

FSF clarifies its stance on AGPLv3 additional terms

Post Syndicated from jzb original https://lwn.net/Articles/1067771/

OnlyOffice CEO Lev Bannov has recently
claimed that the Euro-Office fork of the
OnlyOffice suite violates the GNU Affero General Public License
version 3 (AGPLv3). Krzysztof Siewicz of the Free Software
Foundation (FSF) has published
an article on the FSF’s position on adding terms to the AGPLv3. In
short, Siewicz concludes that OnlyOffice has added restrictions to
the license that are not compatible with the AGPLv3, and those
restrictions can be removed by recipients of the code.

We urge OnlyOffice to clarify the situation by making it unambiguous
that OnlyOffice is licensed under the AGPLv3, and that users who
already received copies of the software are allowed to remove any
further restrictions. Additionally, if they intend to continue to use
the AGPLv3 for future releases, they should state clearly that the
program is licensed under the AGPLv3 and make sure they remove any
further restrictions from their program documentation and source
code. Confusing users by attaching further restrictions to any of the
FSF’s family of GNU General Public Licenses is not in line with free
software.

[$] Forking Vim to avoid LLM-generated code

Post Syndicated from daroc original https://lwn.net/Articles/1067007/

Many people dislike the proliferation of Large Language Models (LLMs) in recent
years, and so make an understandable attempt to avoid them.
That may not be possible in general, but there are two new forks of
Vim that seek to provide an editing
environment with no LLM-generated code. EVi focuses on being a modern Vim
without LLM-assisted contributions, while Vim Classic focuses on providing a long-term maintenance
version of Vim 8. While both are still in their early phases,
the projects look to be on track to provide stable alternatives — as long as
enough people are interested.

Security updates for Wednesday

Post Syndicated from jzb original https://lwn.net/Articles/1067718/

Security updates have been issued by AlmaLinux (capstone, cockpit, firefox, git-lfs, golang-github-openprinting-ipp-usb, kea, kernel, nghttp2, nodejs24, openexr, perl-XML-Parser, rsync, squid, and vim), Debian (imagemagick, systemd, and thunderbird), Slackware (libexif and xorg), SUSE (bind, clamav, firefox, freerdp2, giflib, go1.25, go1.26, helm, ignition, libpng16, libssh, oci-cli, rust1.92, strongswan, sudo, xorg-x11-server, and xwayland), and Ubuntu (rust-tar and rustc, rustc-1.76, rustc-1.77, rustc-1.78, rustc-1.79, rustc-1.80).

Introducing Agent Lee – a new interface to the Cloudflare stack

Post Syndicated from Kylie Czajkowski original https://blog.cloudflare.com/introducing-agent-lee/

While there have been small improvements along the way, the interface of technical products has not really changed since the dawn of the Internet. It still remains: clicking five pages deep, cross-referencing logs across tabs, and hunting for hidden toggles.

AI gives us the opportunity to rethink all that. Instead of complexity spread over a sprawling graphical user interface: what if you could describe in plain language what you wanted to achieve? 

This is the future — and we’re launching it today. We didn’t want to just put an agent in a dashboard. We wanted to create an entirely new way to interact with our entire platform. Any task, any surface, a single prompt.

Introducing Agent Lee.

Agent Lee is an in-dashboard AI assistant that understands your Cloudflare account. 

It can help you with troubleshooting, which, today, is a manual grind. If your Worker starts returning 503s at 02:00 UTC, finding the root cause: be it an R2 bucket, a misconfigured route, or a hidden rate limit, you’re opening half a dozen tabs and hoping you recognize the pattern. Most developers don’t have a teammate who knows the entire platform standing over their shoulder at 2 a.m. Agent Lee does. 

But it won’t just troubleshoot for you at 2 a.m. Agent Lee will also fix the problem for you on the spot.


Agent Lee has been running in an active beta during which it has served over 18,000 daily users, executing nearly a quarter of a million tool calls per day. While we are confident in its current capabilities and success in production, this is a system we are continuously developing. As it remains in beta, you may encounter unexpected limitations or edge cases as we refine its performance. We encourage you to use the feedback form below to help us make it better every day.

What Agent Lee can do

Agent Lee is built directly into the dashboard and understands the resources in your account. It knows your Workers, your zones, your DNS configuration, your error rates. The knowledge that today lives across six tabs and two browser windows will now live in one place, and you can talk to it.

With natural language, you can use it to:

  • Answer questions about your account: “Show me the top 5 error messages on my Worker.”

  • Debug an issue: “I can’t access my site with the www prefix.”

  • Apply a change: “Enable Access for my domain.”

  • Deploy a resource: “Create a new R2 bucket for my photos and connect it to my Worker.”

Instead of switching between products, you describe what you want to do, and Agent Lee helps you get there with instructions and visualizations. It retrieves context, uses the right tools, and creates dynamic visualizations based on the types of questions you ask. Ask what your error rate looks like over the last 24 hours, and it renders a chart inline, pulling from your actual traffic, not sending you to a separate Analytics page.

Agent Lee isn’t answering FAQ questions — it’s doing real work, against real accounts, at scale. Today, Agent Lee serves ~18,000 daily users, executing ~250k tool calls per day across DNS, Workers, SSL/TLS, R2, Registrar, Cache, Cloudflare Tunnel, API Shield, and more. 

How we built it

Codemode

Rather than presenting MCP tool definitions directly to the model, Agent Lee uses Codemode to convert the tools into a TypeScript API and asks the model to write code that calls it instead.

This works better for a couple of reasons. LLMs have seen a huge amount of real-world TypeScript but very few tool call examples, so they’re more accurate when working in code. For multi-step tasks, the model can also chain calls together in a single script and return only the final result, ultimately skipping the round-trips.

The generated code is sent to an upstream Cloudflare MCP server for sandboxed execution, but it goes through a Durable Object that acts as a credentialed proxy. Before any call goes out, the DO classifies the generated code as read or write by inspecting the method and body. Read operations are proxied directly. Write operations are blocked until you explicitly approve them through the elicitation gate. API keys are never present in the generated code — they’re held inside the DO and injected server-side when the upstream call is made. The security boundary isn’t just a sandbox that gets thrown away; it’s a permission architecture that structurally prevents writes from happening without your approval.

The MCP permission system

Agent Lee connects to Cloudflare’s own MCP server, which exposes two tools: a search tool for querying API endpoints and an execute tool for writing code that performs API requests. This is the surface through which Agent Lee reads your account and, when you approve, writes to it.

Write operations go through an elicitation system that surfaces the approval step before any code executes. Agent Lee cannot skip this step. The permission model is the enforcement layer, and the confirmation prompt you see is not a UX courtesy. It’s the gate.


Built on the same stack you can use

Every primitive Agent Lee is built on is available to all our customers: Agents SDK, Workers AI, Durable Objects, and the same MCP infrastructure available to any Cloudflare developer. We didn’t build internal tools that aren’t available to you — instead we built it with the same Cloudflare lego blocks that you have access to.

Building Agent Lee on our own primitives wasn’t just a design principle. It was the fastest way to find out what works and what doesn’t. We built this in production, with real users, against real accounts. That means every limitation we hit is a limitation we can fix in the platform. Every pattern that works is one we can make easier for the next team that builds on top of it.

These are not opinions. They’re what quarter of a million tool calls across 18,000 users a day are telling us.


Generative UI

Interacting with a platform should feel like collaborating with an expert. Conversations should transcend simple text. With Agent Lee, as your dialogue evolves, the platform dynamically generates UI components alongside textual responses to provide a richer, more actionable experience.

For example, if you ask about website traffic trends for the month, you won’t just get a paragraph of numbers. Agent Lee will render an interactive line graph, allowing you to visualize peaks and troughs in activity at a glance.

To give you full creative control, every conversation is accompanied within an adaptive grid. Here you can click and drag across the grid to carve out space for new UI blocks, then simply describe what you want to see and let the agent handle the heavy lifting.

Today, we support a diverse library of visual blocks, including dynamic tables, interactive charts, architecture maps, and more. By blending the flexibility of natural language with the clarity of structured UI, Agent Lee transforms your chat history into a living dashboard.


Measuring quality and safety

An agent that can take action on your account needs to be reliable and secure. Elicitations allow agentic systems to actively solicit information, preferences, or approvals from users or other systems mid-execution. When Agent Lee needs to take non-read actions on a user’s behalf we use elicitations by requiring an explicit approval action in the user interface. These guardrails allow Agent Lee to truly be a partner alongside you in managing your resource safely.

In addition to safety, we continuously measure quality.

  • Evals to measure conversation success rate and information accuracy.

  • Feedback signals from user interactions (thumbs up / thumbs down).

  • Tool call execution success rate and hallucination scorers.

  • Per-product breakdown of conversation performance.

These systems help us improve Agent Lee over time while keeping users in control. 

Our vision ahead

Agent Lee in the dashboard is only the beginning.

The bigger vision is Agent Lee as the interface to the entire Cloudflare platform — from anywhere. The dashboard today, the CLI next, your phone when you’re on the go. The surface you use shouldn’t matter. You should be able to describe what you need and have it done, regardless of where you are.

From there, Agent Lee gets proactive. Rather than waiting to be asked, it watches what matters to you, your Workers, your traffic, your error thresholds and reaches out when something warrants attention. An agent that only responds is useful. One that notices things first is something different.

Underlying all of this is context. Agent Lee already knows your account configuration. Over time, it will know more, what you’ve asked before, what page you’re on, what you were debugging last week. That accumulated context is what makes a platform feel less like a tool and more like a collaborator.

We’re not there yet. Agent Lee today is the first step, running in production, doing real work at scale. The architecture is built to get to the rest.

Try it out

Agent Lee is available in beta for Free plan users. Log in to your Cloudflare dashboard and click Ask AI in the upper right corner to get started.


We’d love to know what you build and what you’d like to see in Agent Lee. Please share your feedback here.


The collective thoughts of the interwebz