Ship the Agent, Not Just the App: Curie vs Deployah and the Future of the Git-Push Deploy Contract

On August 5, 2026, two projects launched on Hacker News a few hours apart, both promising to simplify Kubernetes deploys, and both meaning almost opposite things by it. Curie ships Claude Code agents themselves to Kubernetes with git push, treating the agent as the deployable artifact. Deployah deploys ordinary workloads from a short spec file with no Helm charts and nothing installed in-cluster, treating the manifest layer as the thing that needed simplifying. One changes what you deploy; the other changes how much YAML it takes.

Here is the verdict up front, with the receipts below: if you run a Render-compatible git-push platform, extend the artifact end first. Agent identity, tool grants, sandbox bounds, evals, and spend budgets are deploy-time concerns that no amount of manifest shrinking provides — and whoever defines that deploy contract first owns the interface every agent-gateway, MCP server, and sandbox runner will have to speak. Borrow Deployah's ownership split as the shape, but build Curie's direction as the substance. The rest of this post is the side-by-side that earns that sentence.

Both projects are small, young, and Apache-2.0 licensed: Curie (Python, created July 2026, ~35 stars) and Deployah (Go, created January 2025, ~29 stars), each actively pushed within the last day as of this writing. Neither is a platform you should bet your production fleet on today. But as design documents for where the deploy interface goes next, they are the two clearest statements of the two possible answers — which is exactly why they are worth reading together.

What Curie actually deploys​

Curie's deployable unit is a Claude Code plugin bundle: skills/<name>/SKILL.md for instructions, .mcp.json for the MCP servers (tools) the agent may call, and evals/cases.json for the eval cases that grade its behavior. curie init scaffolds exactly this shape, and the format is the Claude Code plugin format verbatim — the thing you authored in your editor is the thing that ships, not a translation of it.

The signature mechanic is the parity ladder. The same immutable bundle climbs three tiers: skill runs it as a single container with no platform in front (the fast loop), local runs it through the full platform — Postgres, Valkey queue, API, worker — via Docker Compose, and cluster runs that same full platform on Kubernetes. Each tier answers the same verbs (up, message, eval), so promoting skill → local → cluster is a ladder, not three separate setups. Curie is explicit that this is an environment guarantee, not a behavior guarantee: production traffic can still surprise you, and no honest platform promises otherwise.

Git push is the deploy path, and it has a genuinely agent-shaped semantic. A push to the dev branch archives, validates, and stores the bundle as an immutable versioned artifact, then fans its eval suite out as a CI check that sets a commit status. Merging to prod promotes the same bytes without rebuilding — no clone, no re-validation, no git-remote access needed — only re-checking the stored bundle's bounds against current caps. Pushes arrive over an HMAC-verified webhook, with a commit-poller fallback for self-hosted clusters behind firewalls that cannot receive inbound webhooks.

The deployed agent gets a bot identity per environment: push to dev updates @curie-dev, merging to prod promotes to @curie.

Then comes the part no stateless-web-service deploy contract has: the sandbox. Each agent turn runs in a claimed sandbox — SandboxClaim CRDs on Kubernetes, the same runner image as a local Docker container on a laptop — with a gVisor RuntimeClass where offered, an egress allowlist inferred from the model credential's prefix, and per-agent connector secrets fenced by a reserved-name policy so agent-supplied variables can never clobber platform boot vars. Traces, eval scores, and cost flow through Langfuse and the OTel Collector into one console. The repo's own summary: a Slack message is answered by a versioned plugin running in an isolated Kubernetes sandbox, traced end to end and steerable mid-turn.

The maturity ledger is refreshingly explicit. Built and live-verified end to end: the API, worker kernel, runner, dispatcher, eval plane, chart with security rails, CLI, and UI — including a rehearsed install on a fresh k3s cluster and a timed cold-start rehearsal that passed at v0.4.0-rc.3. Deferred: the email channel's live-cluster rehearsal, automatic memory generation, and the native OpenAI wire format (non-Anthropic providers ride an Anthropic-compatible base-URL seam instead). As the HN launch author put it, the gap from "works locally" to "real application" for agents is as large as the gap from local code to prod SaaS — because it is the same problem, and Curie is an attempt to give it the same lifecycle machinery.

What Deployah actually deploys​

Deployah's deployable unit is deliberately boring: your existing container image, described by a short deployah.yaml. The quickstart spec that runs nginx is nine lines — project name, one component, image, port, environment filter, expose: true. Deployah parses and validates it against JSON Schema, resolves the environment, merges the platform file and profiles, and renders a hidden umbrella chart that it installs as a real Helm release. The authors call the flow Spec-to-Release, "like Source-to-Image, but for the deploy step": S2I builds your image, Deployah runs your release.

The binary embeds Helm, the Kubernetes client, and Kind as libraries, and installs nothing in your cluster — the output is inspectable afterward with ordinary helm history and helm get.

The load-bearing idea is the ownership split. The app developer owns deployah.yaml — image, port, resources, expose intent, scaling, persistence, workers — with no cluster context and no real domain names in it. The platform side owns deployah.platform.yaml — cluster contexts, domains, TLS, storage classes, and named profiles for placement, security, and resource ceilings. Domains, TLS modes, and policy can change without editing every app spec, and each environment maps to its own cluster and settings, including prefix-matched review targets like review/pr-123.

The defaults are opinionated in the way a PaaS operator would recognize: Deployments, one replica, TCP health checks, 30/60-second graceful stops, retained ReadWriteOnce persistence, and hostname-plus-TLS from the environment's domain. deployah plan renders the diff read-only (with --offline, --drift, and JSON for CI), and tasks: covers migrations and CronJobs — the Heroku-release-phase equivalent. Follow-up HN launches added the expected day-two surface: an init wizard, tasks, and CronJobs in v0.8.0.

Deployah's comparison doc is unusually honest about where it sits. Against DevSpace, Werf, Score, Epinio, and Kubero, its claim is narrow and checkable: it is the only one where the developer needs no Helm knowledge, there is no platform to install, and you still get a real Helm release. The same page lists what it does not do — no image builds, no dev loop, no web UI, no database add-ons, no Git or PR preview apps, no dependency model ("ask for a Postgres, the platform creates it" is Score's strength, not Deployah's) — and the schemas are alpha (v1-alpha.5 / platform/v1-alpha.3) with breaking changes expected. That candor is a feature: the tool knows it is a deploy step, not a platform.

The collision table​

Now put the two contracts next to each other and ask the question the TODO item poses: what changes once the tenant's unit of deployment is an autonomous operator rather than a stateless web service? Six deploy-time concerns appear that a classic PaaS never had to name — and the table shows which project answers each natively.

The asymmetry is the point. Every row Deployah leaves blank is one where "the manifest got shorter" cannot help, because the concern is not expressible in Deployment-shaped YAML at all. Tool grants are the sharpest example: an agent's .mcp.json is a capability list, and shipping it inside the versioned artifact means a prod promotion cannot silently widen an agent's reach. There is no Helm-values equivalent of that property; it has to be designed into the artifact format.

Sandbox bounds rhyme: a sandbox claim with an egress allowlist is a different primitive from a pod spec with a good securityContext.

Read the table the other way and Deployah's bet looks equally deliberate. Curie answers all six rows by installing a full platform — API, queue, worker, Postgres, object store, Langfuse — into your cluster. Deployah answers one row (identity-via-Helm) with a stateless binary and zero cluster-side setup. For teams deploying stateless services, that is not a gap; it is the product.

The disagreement is really about which complexity is load-bearing: Curie says the artifact got stranger so the platform must get smarter; Deployah says the platform got heavier so the client must get thinner.

The HN objections, adjudicated​

Both launch threads drew the critiques every deploy-tool launch draws, and the authors' answers are instructive. On Deployah's thread, the DSL objection arrived first: developers do not want yet another abstraction over Kubernetes; render full YAML and skip the templating. The author's answer is architectural — the output stays a real Helm release inspectable with normal Helm commands, so the spec is a bridge you can always look under. Verdict: a draw with a warning, since every profile added to close a gap makes the "short" spec longer.

The sharper objection was about trust: nothing in-cluster means handing developers raw cluster access. The author's rebuttal reframes the boundary correctly — Deployah is client-side like helm/kubectl, runs with whatever RBAC the invoking identity already has, and the platform file stays under platform-team ownership. A developer with a namespace-scoped kubeconfig is not a developer with cluster-admin. Verdict: answered, provided teams actually enforce the ownership split.

The third counter — a small team can just share one Helm chart customized through values.yaml — is the one that sticks, and Deployah's own comparison page concedes its shape: Werf and DevSpace give more control to people who already know Helm. If your team writes Helm fluently, a curated internal chart is genuinely competitive. Deployah's answer is that most teams do not, and should not have to. Verdict: true for Helm-fluent teams, a shrinking population.

Curie's thread was quieter — one comment, from the author — but the unasked objection is the interesting one: Curie installs the heaviest thing in this comparison (queue, worker fleet, Postgres, object store, Langfuse) to deploy the thing nobody has standardized yet. The adopt-not-build boundaries are the mitigation: most of the weight is someone else's maintained software. Verdict: fair concern, honestly bounded — and it means Curie's contract only pays off for teams already committed to operating Kubernetes, which is precisely the audience a self-hosted PaaS serves.

Which end first, concretely​

So: which end should a Render-compatible git-push platform extend first? The artifact end, for one reason that survives contact with the table above: manifest simplification is table stakes anyone can copy, while the agent deploy contract is the missing primitive nobody has standardized.

Consider what happens if you build Deployah's direction first. You get a shorter spec, a cleaner ownership split, and a nicer plan — all genuinely good, and all immediately comparable to every other short-spec tool (Score, DevSpace values, a curated Helm chart) on purely ergonomic grounds. There is no moat in "our YAML is shorter," and the moment an agent workload arrives, you face the six-row table with five blank cells and no artifact format to put the answers in. Tool grants, sandbox bounds, evals, and budgets do not fit in a Deployment-shaped spec no matter how short it is; bolting them on later means versioning a second artifact format under a live platform.

Build Curie's direction first and the ordering inverts. Define the agent as a deployable: a versioned bundle of instructions, tool grants, and evals, shipped by git push, promoted across environments without rebuild, gated by behavioral checks, budgeted, and run under a bot identity inside claimed sandboxes. The stateless web service then becomes the degenerate case of that contract — a bundle with no tools, no evals, and a trivial sandbox profile — rather than the thing the whole platform assumes.

And Deployah's best idea, the app/platform ownership split, ports over cleanly: the tenant owns the bundle (what the agent is and may touch), the platform owns the contexts, domains, sandbox profiles, model credentials, and budget caps (where and under what bounds it runs). Short specs for plain services can follow as a second act on top of a contract that already knows what an agent is.

Concretely, the first extension is five deploy-time fields: tools (the MCP grant list, versioned with the bundle), sandbox (the named sandbox profile — runtime class, egress policy, secret scope), evals (the gate suite that must pass before promote), budgets (spend caps re-checked at promote time), and identity (the bot identity the deployment serves under). Everything else — the queue, the worker, the trace backend — is adopt-not-build, exactly as Curie's architecture demonstrates. The platform that ships those five fields with git push semantics has defined what it means to deploy an operator, not just an app. The platform that ships a shorter service spec has defined what it means to deploy the same thing with less typing.

That is the disagreement, settled as far as two thirty-star repos can settle anything: Curie bets the artifact changed; Deployah bets the manifest was the problem. Both can be good tools. But only one of the two bets names the future workload — and a git-push platform is, above all, a bet on what the next deployable thing is.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. As agents become the deployable unit, the deploy contract has to grow identity, tool grants, and sandbox bounds; that is the direction bex is built to extend. Star the repo on GitHub or deploy your first app today.