Samsung, sektöre öncülük ettiği katlanabilir telefonlar sonrasında pazara genişleyen akıllı telefonlar da çıkarmak istiyor. Bu konuda uzun zamandır çalışmalar yapan şirket, kısa süre önce yana doğru genişleyen bir telefon modeli için patent aldı. Aynı zamanda yukarıya doğru genişleyen cihazlar üzerinde de çalışan teknoloji devi, kullanıcılara rahat taşınabilecek devasa ekranlı telefonlar sunmak istiyor. Bu alanda ilk ticari adımı 2027 ya da 2028’de atması beklenen Samsung, önümüzdeki aylarda geniş yapılı bir katlanabilir telefon modeli de tanıtacak.

Samsung, yana doğru genişleyen bir telefon için patent aldı yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

In Part 1 I laid out the Jenkins-as-a-Code setup — JCasC, Job DSL, ephemeral workers, Packer images, all of it. And I said macOS workers were their own special kind of hell that deserved a separate post. This is that post.

If you’ve never had to run macOS builds in CI, the short version is: everything that’s easy on Linux is hard on macOS, and everything that’s hard on Linux is also hard on macOS but in a different way. Apple’s licensing rules, the fact that you can’t just spin up a Mac in AWS the same way you spin up Ubuntu, the keychain weirdness, the signing tooling, the Xcode versions — all of it adds up. And the answer at most companies is “we have a few Mac minis under someone’s desk that everybody SSHes into”. Which works until it doesn’t.

I wanted the same story I had for Linux and Windows — born for one build, destroyed after, byte-identical state every time — but on macOS. Took me a while to get there. Here’s what actually worked.

Why macOS is hard in the first place

Before getting into solutions, it helps to name the problems, because they explain why the architecture ends up looking weird.

1. The cloud Mac story is awkward. EC2 Mac instances do exist. They’re real Mac hardware living in AWS data centers, and you can absolutely rent one. The catch is the shape: they’re dedicated hosts with a 24-hour minimum allocation (Apple’s licensing requirement, not AWS being weird), and the per-hour pricing is brutal compared to Linux. For ephemeral workers that live for 30 minutes per build, paying for 24 hours per allocation makes the per-build economics painful. Cloud Mac exists; it’s just shaped wrong for high-volume ephemeral CI.

2. Apple’s EULA only allows macOS to run on Apple hardware. Which means: no, you cannot legally virtualize macOS on a Linux box. You need real Mac hardware somewhere in the loop. Either you own it, you rent it, or you use a provider that owns it for you.

3. macOS virtualization is its own ecosystem. On Intel Macs the answer used to be VMware (vSphere or Fusion) or VirtualBox. On Apple Silicon, neither of those works the same way — Apple’s Virtualization.framework is what everything is built on top of now, and the tooling around it is much younger.

4. Signing and notarization need credentials that don’t love being ephemeral. Apple Developer ID certificates, app-specific passwords, the keychain — none of these were designed with “fresh VM every build” in mind. They were designed for “a developer’s laptop”. Making them work in CI is a whole sub-problem.

5. macOS images are huge. A baked Packer image with Xcode is 60–80 GB. Spinning that up from cold storage is slow. Caching matters way more than it does for Linux.

Once you understand those five things, the architecture choices below stop looking weird.

What I evaluated and didn’t pick

The macOS CI space is small enough that I can name everything serious in it. Before settling on the approaches below, I did a real evaluation of the commercial options — they exist for a reason, they’re not bad, they just didn’t fit our cost shape.

• Veertu Anka — the most mature paid platform specifically for macOS CI virtualization. Does roughly what Tart does, with a polished management UI, enterprise support, and a richer feature set. Licensing is per-host or per-VM, and at fleet sizes that matter for a growing engineering org it adds up quickly. If you have the budget and want vendor support, it’s a credible choice.
• MacStadium — a managed-Mac hosting provider. You rent physical Macs in their data center, optionally bundled with their own orchestration layer (Orka). Solves the “I don’t want to rack Macs myself” problem cleanly. Pricing is per-host per-month — makes sense for a large, steady-state fleet, less so if your volume is spiky or you already have Macs you want to use.
• AWS EC2 Mac instances — covered above. Useful for very low-volume work where the operational simplicity wins; bad for high-volume ephemeral CI because of the 24-hour minimum.
• GitHub Actions managed macOS runners — fine for OSS projects and small teams. At any real volume the per-minute pricing gets uncomfortable, and you can’t customize the image — which matters as soon as your build needs anything beyond stock Xcode.

The thing that pushed me toward Tart is the licensing, more than the technology. Tart’s commercial license is structured so that small-scale and personal use is genuinely free, and the paid tier doesn’t scale linearly with fleet size the way per-host licensing does on Anka. For our build volume, that math just works — and at smaller scales (one or two Macs) you pay nothing at all. That’s hard to beat.

And as of April 2026 — when Cirrus Labs joined OpenAI — that licensing got even better: Tart, Vetu and Orchard have been relicensed under a more permissive license and the commercial fees were dropped entirely. If you were on the fence before, the math is even simpler now.

The other thing the Cirrus Labs team gets right is the coherent toolchain around Tart. Tart for VMs, Orchard for fleet orchestration, and the Cirrus CLI for running CI tasks locally — the same .cirrus.yml configs that would run on the the Cirrus CLI runs the same YAML task definitions locally against a Tart VM. The local-reproduction story alone has saved me hours of “wait, why does this fail only in CI” debugging. It’s one of those toolchains where each piece is useful on its own, but the combination is what makes the whole thing pleasant to live with.

Three ways I ended up provisioning macOS workers

There’s no single tool that does everything I needed. So the answer ended up being: three different provisioners for three different shapes of Mac fleet. All three follow the same pattern from Part 1 — a Jenkins job invokes the provisioner, the worker comes up from a Packer-baked image, runs the build, gets destroyed — but the layer underneath is different.

Option A — Tart, for Apple Silicon

Tart is a small open-source CLI built by the Cirrus Labs folks that wraps Apple’s Virtualization.framework. You give it an OCI-compatible image (basically a tarball with the macOS VM disk), it spins up a VM on Apple Silicon hardware in seconds. The image is reusable, you can layer on top of it, and it’s the closest thing to “docker, but for macOS VMs” that exists today.

How it fits:

• The Mac hardware itself is a fleet of Mac minis (or Mac Studios) — physical machines we own or rent, sitting in a rack.
• Each Mac has Tart installed at the host level.
• A dedicated Jenkins job picks an available host, runs tart clone from a known image tag, runs tart run, registers the new VM as a Jenkins agent, and after the build runs tart delete to clean up.
• Packer has a tart-cli source that builds those images. We bake everything — Xcode, Homebrew, signing tools, languages — into the image at build time.

The good: spin-up is genuinely fast. From tart clone to “agent connected to Jenkins” is under a minute. The image is a snapshot, so every build truly starts from byte-identical state — same as the Linux pod story.

The not-so-good: you still need to own or rent the Mac hardware. You’re not escaping the “real Apple machines in a rack” problem; you’re just orchestrating them better. And the Tart ecosystem is young — expect to write some glue.

Option B — vSphere / VCSA, for the older Intel fleet

Before Apple Silicon, the Mac fleet was a stack of Intel Mac minis hooked into a vSphere cluster. macOS VMs were managed as ESXi guests, exactly like any other VMware VM.

How it fits:

• Each Mac mini runs ESXi (which is the one OS allowed to be installed on a Mac and host macOS guests, per Apple’s licensing).
• A “golden” macOS VM template lives in vSphere, baked by Packer’s vSphere ISO builder.
• A dedicated Jenkins job runs Terraform with the vSphere provider to clone the template (linked clones are faster), bring up the VM, configure it as an agent, and tear it down after.

This setup predates the Apple Silicon transition and it still works — but it’s the heaviest of the three. Linked clones speed up the spawn time, but it’s still slower than Tart, and vSphere itself is a chunky thing to operate.

I’d describe this as the “responsible enterprise” path. If you already have VMware in your org, it slots in cleanly. If you don’t, you’d never start here in 2026.

Option C — Orchard, for pooled / remote Macs

Orchard is also from Cirrus Labs — same family as Tart. The pitch is: instead of you orchestrating individual Mac hosts, Orchard runs as a controller that manages a pool of Mac workers, and you ask it for a VM via an API. It handles scheduling, queuing, and lifecycle.

How it fits:

• Useful when you have a pool of Macs (could be your own, could be from a managed provider like MacStadium or a similar cloud-Mac vendor), and you don’t want each Jenkins job to know which physical machine to pick.
• A dedicated Jenkins job calls Orchard’s API to request a VM with a specific image and resource profile, gets a VM back, runs the build, releases it.
• Useful when capacity is the constraint. You can have 20 builds queued and 5 Macs available, and Orchard does the scheduling for you.

The good: clean separation of concerns. The Jenkins job doesn’t care where the Mac is physically.

The not-so-good: another piece of infrastructure to run. Worth it only at a certain fleet size — for a tiny pool of 2–3 Macs, raw Tart is simpler.

What gets baked into the Packer image

Same story as Linux and Windows — we bake everything we can into the image, so the build itself doesn’t pay setup time. The macOS Packer image is the heaviest one in the fleet by a wide margin.

What goes into a typical macOS worker image:

• OS: a specific macOS version (we pin to specific point releases — Xcode compatibility is brittle, you don’t want to be on “whatever’s latest”).
• Xcode: a specific Xcode version, plus the command line tools. Xcode alone is 30+ GB.
• Homebrew + packages: all the brewed tools the build needs, pre-installed and pre-warmed.
• Language runtimes: Node, Python, Ruby — pinned to specific versions matching what production uses.
• Build tools: CMake, Ninja, Conan, whatever the project uses.
• Signing tools: codesign, notarytool, xcrun — these come with Xcode but worth confirming they’re available.
• Pre-warmed caches: Conan cache, npm cache, brew cache — anything that would otherwise need to be downloaded on first build.

The Packer template itself is short — most of the heavy lifting is in a chain of shell scripts that run after the base macOS install:

source "tart-cli" "macos" {
  vm_base_name = "ghcr.io/cirruslabs/macos-monterey-base:latest"
  vm_name      = "macos-ci-${var.image_version}"
  cpu_count    = 4
  memory_gb    = 8
  disk_size_gb = 120
  ssh_username = "admin"
  ssh_password = "admin"
}

build {
  sources = ["source.tart-cli.macos"]

  provisioner "shell" {
    scripts = [
      "scripts/post-install.sh",
      "scripts/brew-setup.sh",
      "scripts/xcode.sh",
      "scripts/nodejs-setup.sh",
      "scripts/deps.sh",
      "scripts/prewarm-caches.sh",
    ]
  }
}

The whole template is maybe 30 lines. The interesting stuff lives in the shell scripts, which are versioned in the same repo and reviewed in the same PRs as everything else.

A baked image is around 60–80 GB. Storage matters. So does the cache locality — if every Mac in the fleet has to pull a fresh 70 GB image from the registry over the network on first use, you’ve got problems. We pre-cache base images on each host out of band.

The signing-on-ephemeral-VMs problem

This is the one part of the macOS story that genuinely deserves its own section, because it’s where most of the time disappears when you first set this up.

Apple’s signing pipeline assumes a developer machine with a persistent keychain. You unlock your keychain once, you sign apps for the rest of the day, life is good. In CI with ephemeral VMs, none of that holds. Each VM is brand new. There’s no pre-existing keychain. There’s no unlocked state. There’s no “saved password”.

Here’s the contract we ended up with — generic enough that it’ll work for most teams:

1. Apple Developer ID certificate + private key live in a secrets manager (AWS Secrets Manager, Vault, whatever you use). Never in the image. Never in git.
2. At job start, the Jenkins pipeline pulls the certificate + key from the secrets manager and imports them into a temporary keychain it creates on the VM.
3. The temporary keychain gets a random password generated for that build, used for the duration of the build, and discarded with the VM.
4. Notarization credentials (app-specific password or notarytool API key) come from the same secrets manager and are used directly — they don’t need a keychain.
5. When the build finishes and the VM dies, the keychain dies with it. Same lifecycle as the rest of the worker.

A simplified version of the keychain-bootstrap script looks like this:

#!/usr/bin/env bash
set -euo pipefail

KEYCHAIN="ci-build.keychain"
KEYCHAIN_PASSWORD="$(openssl rand -base64 24)"

# Create a brand-new keychain just for this build.
security create-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
security set-keychain-settings -lut 21600 "$KEYCHAIN"
security unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"

# Add it to the search list so codesign can find it.
security list-keychains -d user -s "$KEYCHAIN" $(security list-keychains -d user | tr -d '"')

# Import the cert + key from the secrets-manager-provided files.
security import "$DEVELOPER_ID_CERT" -k "$KEYCHAIN" -P "$CERT_PASSWORD" -T /usr/bin/codesign

# Grant codesign permission to use the key without prompting.
security set-key-partition-list -S apple-tool:,apple: -s -k "$KEYCHAIN_PASSWORD" "$KEYCHAIN" >/dev/null

Things that will bite you if you don’t know them:

• set-key-partition-list is mandatory on modern macOS. Without it, codesign prompts for a password from the UI and the build hangs forever.
• The keychain must be in the search list. A keychain that exists but isn’t searched is invisible to codesign.
• Notarization is async. notarytool submit --wait does block until done, but be ready for it to take several minutes. Plan for it in build timeouts.
• Stapling fails silently if you forget it. Notarization succeeds, the artifact ships, end users get a Gatekeeper warning anyway because the ticket isn’t stapled. xcrun stapler staple <artifact> after notarization succeeds.

It’s not deep magic, but every team I’ve seen do macOS CI for the first time burns a week on this. So: budget for that week, and write the keychain bootstrap script before you write the rest of the pipeline.

Trade-offs — which one should you pick?

Honest answer: probably more than one, depending on what fleet you’ve inherited. But if I were starting from a blank slate today, in 2026:

The thing I’d push back on is “let’s just use Mac minis under someone’s desk”. That’s fine for one team. It’s not fine when it’s the bottleneck for every iOS release.

What I’m still figuring out

A few open problems I haven’t fully solved:

• Image freshness. Xcode updates land every few weeks. Keeping the Packer image current without breaking everyone’s builds is a constant low-grade tax. We rebuild images on a schedule and pin every job to a specific image version, but the rebuild itself is a 90-minute job and it’s not free.
• Cost. Mac hardware is expensive whether you own it or rent it. The economics only work above a certain build volume; below that, the per-build cost is uncomfortable.
• Apple Silicon transition for older code. Some of our older C++ code still has Intel-only dependencies that haven’t been ported. We run those builds on the vSphere/Intel fleet, but that fleet is shrinking, and “rewrite all the legacy build deps for arm64” is its own project.
• Notarization queue times. Apple’s notarization service has occasional bad days where submissions take 20+ minutes. There’s nothing we can do about it on our side, but it does mean macOS builds have a longer tail than the others.

Closing thought

The macOS CI story doesn’t have a single right answer. There’s no equivalent of “just run a pod in EKS”. You’re going to end up with physical hardware in the loop, a hypervisor (probably more than one), and a signing problem that doesn’t exist on any other platform. The trick is to treat it the same way as everything else: ephemeral, image-baked, orchestrated by a job in git, secrets from a vault. Once the contract is the same as Linux and Windows, the macOS hell becomes a tractable hell.

Next up — Part 3, where I’ll talk about running spot instances as GitHub Actions runners and the cost story behind moving some of this work off Jenkins entirely. Different model, different trade-offs, similar headaches.

Appendix — tools mentioned in this post

Cirrus Labs toolchain (the one I ended up on)

• Tart — macOS VMs on Apple Silicon via Virtualization.framework. Free for small-scale; licensing.
• Orchard — controller for pooled Tart hosts.
• Cirrus CLI — run CI tasks locally against a Tart VM; same .cirrus.yml as Cirrus CI’s SaaS.
• Packer Tart plugin — Packer builder for Tart images.

Commercial alternatives I evaluated

• Veertu Anka — paid platform for macOS CI virtualization, polished, enterprise support.
• MacStadium — managed Mac hosting + optional Orka orchestration.
• AWS EC2 Mac instances — real Apple hardware in AWS, 24-hour minimum allocation.
• GitHub-hosted macOS runners — fine for OSS / small scale.

Other

• vSphere and the Terraform vSphere provider — for the older Intel fleet.
• HashiCorp Packer — bakes all the worker images.
• Apple’s notarytool — the modern notarization CLI.

This is Part 2 of My CI/CD Odyssey. If you want to be pinged when Part 3 drops, follow me here on dev.to. And if you’re doing macOS CI differently — I’d love to hear about it in the comments.

I ran into a small but annoying problem while deploying a Next.js MDX blog to Cloudflare Workers with OpenNext.

The blog worked locally. The build passed. OpenNext even listed the blog routes during the build.

Then I opened the deployed site, and the blog page was empty.

The issue was not MDX. It was not frontmatter. It was not a missing route. The real problem was that my blog code was still thinking like a normal Node.js app, while Cloudflare Workers runs from a bundled Worker output.

The Short Version

If your MDX blog works in next dev but shows empty pages or missing posts on Cloudflare Workers, check if you read blog files with node:fs at request time.

This is the safer pattern:

• Keep writing posts as .mdx files.
• Parse the files during the build.
• Generate a small TypeScript file with post metadata.
• Generate another TypeScript file that statically imports every MDX post.
• Render posts from that generated registry in production.

That way the Worker does not need to scan your content/blog folder at runtime.

What Broke

The old setup looked something like this:

import fs from "node:fs";
import path from "node:path";
import matter from "gray-matter";

const postsDir = path.join(process.cwd(), "content", "blog");

export function getAllPosts() {
  return fs.readdirSync(postsDir).map((file) => {
    const raw = fs.readFileSync(path.join(postsDir, file), "utf8");
    const { data } = matter(raw);

    return {
      slug: file.replace(/.mdx$/, ""),
      title: data.title,
      description: data.description,
    };
  });
}

This feels fine in local development because the source files are right there on disk.

But after OpenNext builds the app for Cloudflare Workers, the app is running from a Worker bundle. Cloudflare does support node:fs through a virtual filesystem, but that filesystem is not the same as having your project folder mounted in production. Files inside the Worker bundle are readable under /bundle, and /tmp is temporary for a request.

So I stopped treating the source folder as runtime data.

The Fix

I moved blog discovery to build time.

The build step reads the MDX files once, parses the frontmatter, and writes generated TypeScript files that the app can import normally.

The mental model is simple:

Authoring:
  content/blog/*.mdx

Build:
  read MDX files
  parse frontmatter
  generate metadata
  generate static imports

Runtime:
  import generated modules
  render the matching MDX component

This keeps the nice file-based writing flow, but removes runtime filesystem reads from the deployed Worker.

Step 1: Generate Blog Metadata

I use a script before the build. It reads the .mdx files and creates metadata for the blog index, sitemap, RSS feed, and page metadata.

// scripts/generate-blog-data.mjs
import fs from "node:fs";
import path from "node:path";
import matter from "gray-matter";

const root = process.cwd();
const postsDir = path.join(root, "content", "blog");
const outputDir = path.join(root, "src", "lib", "blog");

const files = fs.readdirSync(postsDir).filter((file) => file.endsWith(".mdx"));

const posts = files.map((file) => {
  const slug = file.replace(/.mdx$/, "");
  const raw = fs.readFileSync(path.join(postsDir, file), "utf8");
  const { data, content } = matter(raw);

  const words = content.trim().split(/s+/).filter(Boolean).length;

  return {
    slug,
    title: data.title,
    description: data.description,
    date: data.date,
    readingTime: `${Math.max(1, Math.ceil(words / 225))} min read`,
  };
});

fs.mkdirSync(outputDir, { recursive: true });

fs.writeFileSync(
  path.join(outputDir, "generated-posts.ts"),
  `export const allBlogPosts = ${JSON.stringify(posts, null, 2)} as const;n`
);

The important part is not the exact script. The important part is when it runs.

It runs before next build, not when someone opens /blog.

Step 2: Generate Static MDX Imports

The next file is the one that makes the Worker build reliable.

Instead of doing this:

await import(`../../../content/blog/${slug}.mdx`);

I generate static imports:

// src/lib/blog/generated-components.ts
import type { ComponentType } from "react";

import Post0 from "../../../content/blog/first-post.mdx";
import Post1 from "../../../content/blog/second-post.mdx";

const blogPostComponents: Record<string, ComponentType> = {
  "first-post": Post0,
  "second-post": Post1,
};

export function getPostComponent(slug: string) {
  return blogPostComponents[slug] ?? null;
}

This gives Next.js and OpenNext a clear import graph. They can see the MDX files, compile them, and include them in the Worker output.

That is much easier to trust than a variable import path.

Step 3: Render From the Registry

The blog route becomes a lookup, not a file scan.

import { notFound } from "next/navigation";
import { getPostComponent } from "@/lib/blog/generated-components";
import { allBlogPosts } from "@/lib/blog/generated-posts";

export function generateStaticParams() {
  return allBlogPosts.map((post) => ({ slug: post.slug }));
}

export default async function BlogPostPage({ params }) {
  const { slug } = await params;
  const post = allBlogPosts.find((item) => item.slug === slug);
  const PostContent = getPostComponent(slug);

  if (!post || !PostContent) {
    notFound();
  }

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.description}</p>
      <PostContent />
    </article>
  );
}

Now the production route only depends on bundled code.

No fs.readdirSync. No process.cwd(). No runtime gray-matter.

Step 4: Run the Script Before Every Build

I wired the generator into the build scripts:

{
  "scripts": {
    "prebuild": "node scripts/generate-blog-data.mjs",
    "build": "next build",
    "prebuild:cf": "node scripts/generate-blog-data.mjs",
    "build:cf": "opennextjs-cloudflare build -c wrangler.jsonc"
  }
}

Now when I add a new .mdx file, the next build updates the generated metadata and component registry.

I still get the same writing flow:

content/blog/my-new-post.mdx

But the deployed Worker gets predictable imports.

Step 5: Test the Worker Build

I do not stop at next build for this kind of bug.

next build can pass while the Worker output still behaves differently. So I check the Cloudflare build too:

pnpm build:cf

Then I preview the Worker locally:

pnpm exec opennextjs-cloudflare preview -c wrangler.jsonc

And I test three routes:

curl -I http://localhost:8787/blog
curl -I http://localhost:8787/blog/my-real-post
curl -I http://localhost:8787/blog/not-a-real-post

The result I want:

/blog                 200
/blog/my-real-post    200
/blog/not-a-real-post 404

The fake post matters. A working blog should render real posts and still reject bad slugs.

Quick Debug Checklist

• Does any blog route import node:fs?
• Does /blog call fs.readdirSync during a request?
• Does the post page use a variable MDX import path?
• Does the generated registry include every .mdx file?
• Does pnpm build:cf list the expected blog routes?
• Does the local Worker preview return 200 for a real post?
• Does it return 404 for a fake post?

Where the Content Lives

The full post content still lives in MDX files.

The generated metadata file only stores things like:

• slug
• title
• description
• date
• reading time
• headings, if you need a table of contents

I do not put the whole article body into JSON. That gets messy fast, especially with code blocks, custom MDX components, and imports.

Instead, the body is compiled from the MDX module:

content/blog/my-post.mdx
        |
        v
import Post from "../../../content/blog/my-post.mdx"
        |
        v
<Post />

That is the clean split:

• metadata is generated as plain data
• content is rendered as compiled MDX

A Small SEO Note

The technical fix gets the pages to render. SEO still depends on whether the page is useful.

For this kind of technical post, I try to keep the basics simple:

• use a clear title
• describe the problem in the first few lines
• use short sections
• write headings that say what the section is about
• add examples that someone can copy into their project
• link to the official docs when they matter
• avoid padding the post to hit a word count

That last point is important. Google does not require a magic word count. A shorter post that solves the problem is better than a long post that makes the reader dig.

Final Thought

The fix was mostly a change in where the work happens.

Before, the Worker had to discover blog files at request time.

After, the build discovered the files once, generated a registry, and gave the Worker normal imports to render.

That made the blog simple again. I can still add posts as .mdx files, but production no longer depends on reading my source folder at runtime.

Further Reading

• Cloudflare Workers node:fs documentation
• OpenNext Cloudflare CLI documentation
• OpenNext Cloudflare get started guide
• Google Search Central SEO starter guide
• Google Search Central helpful content guide

Every session,
the LLM starts fresh. The user re-explains their role, their constraints, their preferences, what they were doing last time. Then the session ends, and next time: same thing.

The industry has diagnosed this correctly — statelessness is a real limitation. But the solutions being built mostly share the same premise: that memory is a service you connect to. I think that premise is wrong, and it shapes everything downstream.

The actual cost of statelessness

This isn’t just a UX annoyance. A 2026 study by Pichay measuring 857 production AI sessions found that 21.8% of input tokens are “structural waste” — context that has to be re-established on every session because nothing persists. Nearly a quarter of your token budget, on every call, going toward re-explaining what should already be known.

For casual chat, that’s tolerable. For workflows where context is dense and high-stakes — a lawyer switching between matters, a developer moving between codebases, a clinician picking up a patient thread — the cost compounds. And it’s paid on every session, indefinitely.

What everyone else built

The market’s answer has been centralized memory stores. Mem0 just closed $24M in funding (October 2025) to build “the memory layer for AI.” Letta/MemGPT persists agent state in a server-side database. Zep builds a temporal knowledge graph of user interactions. SAMEP and MemTrust add encryption layers on top of server-side storage.

These are all genuinely useful tools. They solve the statelessness problem for most use cases. But they share an architecture: your context lives on their infrastructure, retrieval is query-scoped, and access is controlled by the service provider.

Even the solutions that advertise encryption — SAMEP, MemTrust — encrypt server-side. The data leaves the client before any cryptographic protection is applied. You’ve traded “AI forgets you” for “your memory is a managed cloud service.” For many applications that’s fine. For sensitive workflows, it’s a different risk surface, not a smaller one.

The question that didn’t get asked

What if memory is a file, not a service?

Not metaphorically. Literally: a single encrypted file, owned by the user, that travels with them across sessions and across models. The LLM reads it at session start, updates it at session end, and the file lives wherever the user puts it.

{
  "format": "klickd/v1",
  "encrypted_payload": "<AES-256-GCM ciphertext>",
  "kdf": "argon2id",
  "salt": "<per-file salt>",
  "nonce": "<GCM nonce>"
}

The key insight: persistent context doesn’t require a server. It requires a standard. A shared format that any model can read and any client can write.

What we built

We built .klickd around this premise. The architecture is deliberately minimal:

• AES-256-GCM encryption, Argon2id key derivation. Client-side only. The key is derived from a passphrase that never leaves the device. There is no server that could be subpoenaed, breached, or decommissioned.
• Provider-agnostic. The same .klickd file works with GPT-4o, Claude, Gemini, Llama. It’s not bound to any model provider’s infrastructure or format.
• Zero-server. There is no backend storing context. The file is the memory. If the file doesn’t exist on your machine, the context doesn’t exist anywhere.

On personalization quality: our LLM-judge benchmark (Zenodo, DOI: 10.5281/zenodo.20320480) — run across 23 test lots and 115 profiles, using qwen3-32b as judge — showed an average improvement of +13.9 points over baseline, with a range of +12.8 to +19.2. This is with llama-3.3-70b-versatile as the model under test. Results are published as-is; methodology and raw data are in the report.

For legal and regulated workflows specifically: the file-per-context model makes cross-matter contamination structurally impossible — not enforced by query scoping or ACLs, but by physical separation. Discovery compliance changes shape: you produce the file, or you don’t. There’s no “server logs” ambiguity.

The honest tradeoffs

This architecture gives up things that matter in other contexts.

You lose:

• Centralized governance and server-side revocation
• Query analytics and usage telemetry
• Multi-tenant management at scale
• Cross-device sync without a separate sync layer

You gain:

• Zero trust surface: there is nothing to breach on the provider side
• GDPR-native by architecture: personal data doesn’t leave the client, so data residency and right-to-erasure are trivially satisfied
• Portability: the file works with any model, now and in the future

This is not a universal solution. It is the right solution for a specific class of use cases: privacy-sensitive, cross-model, user-owned context. If you’re building a consumer product where the vendor needs to manage memory at scale, use Mem0 or Zep — they’re well-engineered for that. If you’re building for a context where the user owns the data and the service provider should have zero access, the server-side model is architecturally incompatible with that requirement, regardless of how good the encryption story is.

Is this a new standard?

The field probably needs a portable, encrypted, open context format the way it needed JWT for auth tokens or RSS for feed syndication — a shared abstraction that any tool can read and write, owned by no single vendor.

We’re not claiming .klickd is that standard. It’s a proof of concept that the abstraction is viable. The memory-file spec is open: https://github.com/Davincc77/klickdskill

The question I keep coming back to: if the AI ecosystem converged on server-side memory because that’s what was easy to build first, not because it’s the right primitive — what does the right primitive actually look like? And is the file abstraction the right level, or is there something better?

Curious what others think, especially those who’ve hit the limits of query-scoped retrieval in production.