DEV Community: Soulman

OPPO and Phala Just Solved a Real Problem in Confidential AI on Kubernetes

Soulman — Tue, 30 Jun 2026 23:47:35 +0000

Note: This article is Adapted from the official OPPO × Phala research paper: https://arxiv.org/abs/2606.03323

If you are running AI workloads on Kubernetes and handling sensitive data, you have probably asked yourself at some point: how do I actually know what is running, where it is running, and whether it has been tampered with? Most setups leave that question unanswered at the container layer. This paper from OPPO and Phala changes that.

What the Paper Actually Does
The research introduces a way to verify three things before any sensitive data enters your workload: the physical hardware running the job, the container image that was loaded, and the identity of the Pod itself. This is done through remote attestation at the Pod level inside Kubernetes, which means the verification happens where the work actually runs, not just at the machine level below it.
Most confidential compute setups today handle attestation at the hardware or virtual machine level. That leaves a gap. Once you move into container orchestration with Kubernetes, you lose that chain of trust unless something bridges it. This paper builds that bridge.

Why This Matters for Builders and Institutions
If you are building AI pipelines where the data cannot be exposed, healthcare, finance, legal, or enterprise AI, you need more than a promise that the environment is secure. You need proof. What this architecture gives you is a cryptographic receipt that covers the full stack: the chip, the image, and the workload identity, all verified before a single byte of sensitive data goes in.
For institutions evaluating confidential AI infrastructure, this is the kind of auditability that makes deployment decisions easier. You are not trusting a vendor claim. You are verifying it.
The full paper is available at https://arxiv.org/abs/2606.03323 and it is worth a read if this is part of what you are building toward.

Private AI Gateway by Phala: What It Is and What It Actually Does

Soulman — Tue, 30 Jun 2026 23:43:03 +0000

Note: This article is Adapted from the official Phala Network blog post: https://phala.com/posts/private-ai-gateway-verified-private-ai-compute

Most people building with AI today assume their prompts are private because they’re using HTTPS. That assumption has a gap. Encrypting the connection protects data in transit, but it doesn’t tell you anything about what happens inside the server handling your request. Private AI Gateway is built to close that gap.
Private AI Gateway is a routing and verification layer for AI inference running inside Trusted Execution Environments. It sits above your model providers and makes sure every request travels a verified path from client to model and back, with proof attached at every step. The result is that developers get a familiar API surface, security teams get something concrete to inspect, and sensitive prompt content stays protected the entire time.

How the verification actually works
When you send a request through Private AI Gateway, the client first checks the gateway’s attestation report. That report confirms which workload is running and exposes the workload’s encryption key. The client then uses that verified key to encrypt sensitive parts of the request before it even leaves the client machine. Only the verified gateway workload holds the matching private key, so nothing in between can read the prompt content. Routing information like billing, model selection, and rate limits stays visible because the gateway still needs to do its job. The sensitive parts stay locked until they reach the verified boundary.
Every request also produces a signed receipt. That receipt records which model route handled the request, what verification was checked before the prompt moved forward, and a chain of hashes from the original request to the final response. It gives security teams an auditable record after the fact rather than a trust assumption made upfront.

Why fragmented compute is a real problem
TEE-based model capacity is spread across many providers right now, and they all handle verification differently. Some bind their TLS key to the attestation. Some expose a separate encryption key. Some rely on GPU-level attestation. If you are routing across multiple providers, you currently have to handle each of these verification styles manually, which is an operational burden that compounds as you add providers.
Private AI Gateway handles that by aggregating providers based on their proof properties. A route only becomes available when it has the right model, acceptable latency, and a verified state. The gateway pre-verifies providers in the background, enforces the right channel binding for each one, and fails the request if the required proof is missing rather than silently routing to an unverified fallback.

What this means for developers, builders, and institutions
The API surface is OpenAI-compatible, so integration does not require rewriting existing code. You add an attestation check and an encryption step, and the rest of your workflow stays the same.
For institutions handling sensitive data, the signed receipts solve a compliance problem that attestation alone cannot. Knowing a workload was verified at boot is useful. Knowing which verified route handled each specific request, with a hash chain to prove it, is what security and legal teams actually need when they review AI usage.

Read the full blog post above from where this article is adapted from.

OpenMed Is Now Deployable on Phala Cloud

Soulman — Sun, 21 Jun 2026 12:52:58 +0000

Note: This article is Adapted from the official Phala announcement.

Healthcare AI has a data problem that most people don’t talk about enough. Clinical notes are some of the most sensitive information that exists, and yet to get value out of them with AI, you have to run them through pipelines that process, store, and analyze that data somewhere. The question is always where, and who can see it. OpenMed solves the first part by taking unstructured clinical text and turning it into structured data that AI systems can actually use. Phala Cloud solves the second part by making sure all of that happens inside a confidential compute environment where the data stays protected the entire time it’s being processed.

What Running OpenMed on Phala Actually Means
When you deploy OpenMed using Phala’s template, your clinical notes, the NLP pipeline processing them, and your app credentials all run inside a Phala TEE CVM. That means even the infrastructure provider cannot access what’s happening inside. For developers building healthcare tools or institutions evaluating AI adoption, this removes one of the biggest blockers, which is proving that sensitive patient data never left a protected environment. You don’t have to take anyone’s word for it. The architecture makes it verifiable.

Why This Makes Phala Worth Paying Attention To
What makes Phala stand out is that they keep closing the gap between confidential computing as a concept and confidential computing as something you can actually ship. A ready to deploy OpenMed template is a practical example of that. Builders don’t need to figure out the security architecture from scratch. They pick the template, deploy it, and get a working confidential environment for healthcare AI out of the box.

You can deploy at https://cloud.phala.com/templates/openmed, review the template code on Phala’s GitHub at https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/openmed, and find the upstream OpenMed project at https://github.com/maziyarpanahi/openmed

Why Svelte and Phala Cloud Work Well Together if you deploy it on Phala Cloud

Soulman — Sun, 21 Jun 2026 12:44:34 +0000

Note: This article is Adapted from the official Phala announcement.

Svelte has become a go-to choice for developers who want to build fast, reactive frontends without the weight of a large framework. It compiles your UI down to small, efficient code that runs directly in the browser, which means your app loads quickly and feels responsive. For a lot of projects, that’s exactly what you need on the frontend side. But most real applications don’t stop at the UI. At some point your app needs to run server side logic, call external APIs, or handle user data, and that’s where things get more complicated.

Where Phala Cloud Fits Into the Picture
When you deploy your Svelte app on Phala Cloud, the server side parts of your application run inside a Trusted Execution Environment backed compute instance. This means your API credentials, backend logic, and user data are processed in an environment that is isolated and verifiable, not just sitting on a standard server where you’re hoping nothing goes wrong. For developers and teams building products that institutions or security focused users need to trust, that distinction matters. You’re not asking anyone to take your word for it. The environment itself provides the guarantee.

Getting Started Is Straightforward
Phala Cloud has a ready to use Svelte template that makes it easy to get a project running without starting from scratch. The template code is open and available on GitHub, so you can review exactly how it’s structured before you deploy anything.
If you’re a developer, builder, or team working on an application that needs a clean frontend and secure backend infrastructure, this is a practical starting point worth exploring.

You can deploy directly at https://cloud.phala.com/templates/svelte and find the template code at https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/svelte and the upstream Svelte project at https://github.com/sveltejs/svelte

How Developers and Institutions Can Run AI Models Without Exposing Their Data

Soulman — Sun, 21 Jun 2026 12:38:11 +0000

Note: This article is Adapted from the official Phala and Cluster announcement.

Most people don’t think about what happens to their data the moment it leaves their device and hits an AI model. It travels through servers, APIs, and infrastructure layers, and somewhere along that path, it’s visible. For developers and institutions working with anything sensitive, a privacy policy alone doesn’t fix it.
That’s the gap Cluster and Phala Network are closing together.

What TEE Hardware Actually Does

TEE stands for Trusted Execution Environment. Think of it as a sealed room inside the processor itself. When a model runs inside a TEE, the data is encrypted during processing, not just in transit or at rest. Nobody outside that enclave can see what’s happening inside, not the cloud provider, not Phala, not Cluster.
The models running inside this setup are ones developers already use like DeepSeek, Qwen, GLM, and MiniMax. So there’s no switching costs or rebuilding your stack. You keep your existing workflow, and the hardware handles the privacy layer underneath.

The Attestation Is the Proof

Here’s the part that matters most for anyone serious about verification. Every inference call returns a signed attestation. That’s a cryptographic receipt generated by the hardware itself, confirming that your prompt was processed inside the enclave and never exposed. You’re not taking anyone’s word for it. The hardware signs off on it directly.
For institutions handling financial data, health information, legal documents, or anything else that can’t be exposed, this moves the conversation from policy to proof. If you’re building applications where data handling needs to be demonstrable and not just promised, that’s worth paying close attention to. You can explore the full breakdown through Here: https://x.com/clusterprotocol/status/2066861913267667235

GLM-5.2 Is Now Live on Phala: What Builders Need to Know

Soulman — Sun, 21 Jun 2026 12:33:20 +0000

Note: This article is adapted from the official Phala blog post. Original article published June 16, 2026 at https://phala.com/posts/glm-5-2-open-source-sota-confidential-ai-phala

Phala Network just became a launch partner for GLM-5.2, the latest open-source model from Z.ai. If you build agents, run long-context workflows, or work with sensitive data in production, this one is worth a closer look. The partnership brings together a model that sits at the top of open-source coding benchmarks with infrastructure built specifically for private, verifiable AI inference.
GLM-5.2 comes with a 1 million token context window and strong performance across long-horizon coding tasks. On FrontierSWE it trails Claude Opus 4.8 by just 1% and edges out GPT-5.5 by the same margin. It also scored first on Design Arena’s code category with 1360 Elo, and shows a sharp improvement over GLM-5.1 on Terminal-Bench 2.1 and SWE-bench Pro. For an open-source model with open weights, those numbers put it in serious company.

Why Running It on Phala Changes the Equation
Model capability gets a lot of attention, but where and how a model runs matters just as much when the workloads are sensitive. Agents handling source code, customer records, legal documents, or internal business logic carry real privacy risk inside every prompt and tool trace. Phala addresses this by running inference inside hardware-isolated environments called TEEs, where execution is protected and the runtime properties can be independently verified. Redpill provides an OpenAI-compatible API layer on top, so developers can route into this stack without changing their existing integrations.

How It Performs in a Real Environment

Phala ran their own benchmark of GLM-5.2-FP8 on an 8xH200 setup using SGLang. At standard context lengths, it holds above 25 tokens per second per user through 64 concurrent users, with aggregate throughput continuing to scale. At longer input shapes it maintains that same threshold through 32 concurrent users before latency pressure increases at higher concurrency. These are practical serving numbers that reflect how the model actually behaves under load, not just isolated lab conditions.

Where to Access It
GLM-5.2 is live on both Phala and Redpill at $1.40 per million input tokens and $4.60 per million output tokens. Most infrastructure conversations treat privacy as something added after deployment. Phala’s approach builds it into the deployment layer from the start, and this launch is a clear signal of where that infrastructure is heading.

GLM-5.2 on Phala: https://phala.com/models/z-ai/glm-5.2 on Redpill: https://redpill.ai/models/z-ai/glm-5.2

Reach out to the Phala team directly at @PhalaNetwork on X or visit https://phala.com/ to explore enterprise access and deployment options.

For individual developers and teams, getting started is straightforward through either platform. For institutions, this is a more significant conversation. If your organization is evaluating AI infrastructure for workloads that involve regulated data, client information, or anything where data exposure is a compliance or legal risk, Phala confidential inference stack is one of the few production ready options that addresses that problem at the infrastructure level rather than asking you to manage it yourself. The combination of open source model strength, verifiable execution, and a familiar API surface makes this a practical starting point, not just a proof of concept.

PaddleOCR on Phala Cloud: Extract Documents Without Exposing What’s Inside

Soulman — Mon, 15 Jun 2026 17:57:20 +0000

Note: This article is Adapted from the official Phala announcement. Original post published on the Phala X handle. Find it here: https://x.com/phalanetwork/status/2065573625588261019

PaddleOCR is one of the more capable open-source OCR engines available, built by PaddlePaddle, and it handles everything from printed text to tables with solid accuracy. Phala Network has added it as a deployable template on Phala Cloud, and the reason that matters is where it runs. When you deploy this template, your OCR workload runs inside a TEE CVM, a hardware-level isolated environment where the document contents, pipeline logic, and extracted results all stay private. That includes from the node operators themselves.

What This Opens Up
The practical value is in documents that have always been awkward to process in the cloud. Financial statements, legal contracts, medical records, internal reports. Content sensitive enough that you don’t want raw data sitting in a general-purpose cloud environment during processing. With this setup, PaddleOCR runs inside the enclave, structured data comes out, and the source material never gets exposed.
For teams building pipelines in regulated industries or handling client data under strict privacy requirements, that changes what’s actually buildable.
The template is live at https://cloud.phala.com/templates/paddleocr and the full code is on GitHub under Phala here: https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/paddleocr. and on Upstream: https://github.com/PaddlePaddle/PaddleOCR

Why This Matters for Phala
Phala keeps shipping deployable templates that let builders plug real tools into a private compute environment without starting from scratch. PaddleOCR is one more example of that pattern, and for developers and institutions taking data privacy in AI pipelines seriously, that’s the kind of progress worth paying attention to.

Flue on Phala Cloud: TypeScript Agents With Privacy Built In

Soulman — Mon, 15 Jun 2026 17:45:57 +0000

Note: This article is Adapted from the official Phala announcement. Original post published on the X handle. Check it here: https://x.com/PhalaNetwork/status/2064931094139638104

If you’re building AI agents in TypeScript, there’s always a setup tax before you write any real logic. Sessions, tool calls, sandboxes, skill routing, Flue handles all of that in one harness so you can focus on what your agent actually does.
The template is live on Phala Cloud at https://cloud.phala.com/templates/flue, with code open on GitHub under the Phala here: https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/flue. The upstream framework is at withastro/flue.check it here: https://github.com/withastro/flue

What Phala Adds
Deploying on Phala Cloud means your agent runs inside a TEE confidential virtual machine. Your repo context, prompts, and tool calls stay inside a hardware-verified environment that nobody outside it can access, including the infrastructure provider. Most agent frameworks have no real answer for this. You usually end up trusting your cloud provider with everything running inside it. Phala closes that gap without changing how you write your agent.

Why It Matters
Combining TypeScript tooling with hardware level privacy in a one-click template is not something you see often. A lot of projects treat confidential compute as a roadmap item. Phala ships it as something you can deploy today.
For teams running agent logic they can’t afford to expose, that’s a real difference, and it’s why Phala stays worth watching as the agent space grows.

Headroom Runs Inside a Phala TEE, and That Changes How You Think About LLM Pipelines

Soulman — Mon, 15 Jun 2026 17:39:57 +0000

Note: This article is Adapted from the official Phala post.

If you’re building with large language models, you already know the context window problem. Every tool output, log entry, and document chunk you feed into your model costs tokens, and those costs add up fast. Headroom handles this automatically, sitting between your data sources and your LLM and compressing tool outputs, logs, files, and RAG chunks before they reach the model. That alone is useful. But where it runs is the more interesting part.

The Data Never Leaves the Encrypted Environment
Headroom deploys inside a Phala Confidential Virtual Machine, meaning your API keys, compression rules, logs, and payloads are processed inside an encrypted hardware environment that even the underlying cloud infrastructure cannot read. This is not a software-level privacy claim. The protection comes from the hardware itself, and that trust is verifiable, not just promised.
For anyone building pipelines that touch sensitive or regulated data, that distinction matters. You can deploy it directly from a template at https://cloud.phala.com/templates/headroom, and the full code is on GitHub under Phala here: https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/headroom, with the upstream from chopratejas/headroom if you want to dig in or adapt it.check it here: https://github.com/chopratejas/headroom

Why Phala Is Worth Watching
Headroom is a small but concrete example of what becomes possible when confidential compute is the base layer rather than an afterthought. Most infrastructure forces a trade-off between flexibility and privacy. Phala removes that trade-off for workloads running on top of it. The code is open, the deployment is live, and builders can verify the environment themselves.

For developers and institutions evaluating where to run sensitive AI workloads, that combination is what a serious shortlist looks like.

GitHub’s Copilot SDK Just Got a Privacy Upgrade

Soulman — Thu, 11 Jun 2026 22:50:07 +0000

Note: This article is adapted from the official phala.com announcement.

GitHub recently released the Copilot SDK, which lets developers embed Copilot Agent directly into their own apps and services. Until now, if you wanted Copilot’s capabilities, you worked inside GitHub’s interface. The SDK changes that by opening up the agent layer so builders can bring it into whatever they’re building, on their own terms.
That’s useful on its own. But it also opens up a question most developers haven’t had to think about yet: when your agent is running inside your infrastructure, what happens to the context it’s working with? Your repo contents, your prompts, the state the agent holds while it’s executing, where does all of that actually live, and who can see it?

What Phala Built on Top of It
Phala put together a deployment template that runs the Copilot Agent inside a TEE CVM. Without getting into the weeds, that means the agent executes inside a hardware-protected environment where the contents are sealed off, even from the infrastructure provider itself. Your repo context, prompts, and execution state stay inside that environment throughout the entire process. Nothing leaks out, and the execution can be verified rather than just trusted.
If you’re a developer ready to try it, You can be up and running with a private Copilot Agent deployment faster than you’d expect. If you’re part of a team or institution evaluating how to deploy AI agents without exposing sensitive data to third parties, this is a setup worth a serious look. The infrastructure is already there, and it works today.

The template is ready to deploy at https://cloud.phala.com/templates/copilot-sdk, and both the template code and the upstream Copilot SDK are open for anyone to inspect on GitHub.

Template code: https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/copilot-sdk
Upstream: https://github.com/github/copilot-sdk

Phala.com and LLMTUNE partner in Building AI Infrastructure That Actually Keeps Your Data Private

Soulman — Thu, 11 Jun 2026 22:44:12 +0000

Note: This article is adapted from the official Phala.com announcement.

Most conversations about private AI stop at encryption. Encrypt the data before it moves, encrypt it when it sits in storage, and call it done. But there is a gap that rarely gets talked about which is what happens to your data while it is actively being processed?
That is the moment it is most exposed, and it is the part most infrastructure providers quietly skip over. Phala Network has been focused on closing that gap for a while now, using TEE to create a hardware-level boundary around computation itself. The model runs, the inference happens, and none of it is visible outside that protected space, not even to the infrastructure provider running it. That is a fundamentally different level of guarantee than what most platforms offer, and it is why serious builders keep coming back to Phala when the question of trust actually matters.

What LLMTUNE Brings to the Table
LLMTUNE focuses on the parts of the AI workflow that happen before deployment like fine-tuning models, shaping their behavior, and getting them ready to run in production.
That is meaningful work because a base model out of the box rarely does exactly what a business or developer needs. You train it, adjust it, specialize it, and then you need somewhere trustworthy to run it. The problem has always been that fine-tuning and confidential deployment were handled by completely separate systems that were never designed to talk to each other.
This partnership changes that. By combining LLMTUNE’s model preparation capabilities with Phala’s confidential compute infrastructure, the two teams are building a path where private AI goes from concept to running system without the chain of trust breaking somewhere in the middle.

Why This Matters for Anyone Building With AI Today
Institutions, developers, and businesses that handle sensitive data are running out of reasons to delay moving AI workloads into production. Regulation is tightening, user expectations around data handling are rising, and the technical excuse that truly private AI is too complicated or too limited is getting harder to make.

What Phala and LLMTUNE are building together is exactly the kind of infrastructure that removes those blockers. You get model tuning, deployment, and hardware-verified confidential compute as a connected system rather than a patchwork of tools.

Phala has been one of the more consistent projects in this space when it comes to actually shipping infrastructure that developers can build on, and partnerships like this one reflect that. The teams say more is coming, and based on what each side already does independently, that is worth paying attention to.

Supermemory on Phala Cloud: Your AI App's Memory Layer, Done Right

Soulman — Thu, 11 Jun 2026 22:35:29 +0000

*Note: This article is adapted from the official Phala announcement. *

Most AI applications need memory in a practical sense: where does the app store user context, how does it retrieve the right information at the right time, and where do the credentials live that make retrieval work? Supermemory solves this by turning memory into an API layer, so instead of building retrieval logic from scratch, you connect to it and focus on your actual product.
The problem is that memory datasets and credentials often touch sensitive data, and most builders treat the security side as something to figure out later.

What Changes When You Deploy on Phala Cloud
Phala Cloud has a deployment template for Supermemory, and the difference comes down to how computation is handled. When you deploy inside a TEE CVM, your code runs in a hardware-enforced enclave. The data being processed is not visible to the host machine or cloud provider, and you can verify this through on-chain attestation rather than just taking someone’s word for it.
Most cloud infrastructure protects data at rest and in transit. Phala extends that to data during computation, which is the gap that matters most when memory datasets contain real user data or live credentials.

The Infrastructure Is Ready. Are You?
If you are a developer building AI agents that handle user data, this is the setup worth testing. If you are an institution evaluating AI pipelines where data governance is non-negotiable, Phala gives you something most providers cannot: verifiable proof that your computation ran the way it was supposed to, not just a policy document saying it did.
Phala keeps showing up when AI infrastructure touches real-world constraints, compliance, credential handling, verified execution, and it does it with working tooling, not whitepapers. The Supermemory template is the latest example.

Deploy from the template at https://cloud.phala.com/templates/supermemory, review the code at https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/supermemory, and find the upstream project at https://github.com/supermemoryai/supermemory The infrastructure is there. Start building on it.