Launching BabyChain: durable image and video model chains on AWS Aurora and Vercel

Date: June 12, 2026
By: Randy Aries Saputra

Today we are launching BabyChain: a self-hosted canvas studio and durable chain API for image and video model workflows.

The short version is this: BabyChain lets you design a node-based media chain on a canvas, then call that same chain from product code as POST /api/v1/chains/runs. Every step executes through provider APIs with server-side credentials, every state transition persists to AWS Aurora, and Vercel functions stay stateless.

The new demo adds the agentic layer on top of that same durable runner: Self Control for manual execution, Agentic Copilot for human-reviewed Amazon Nova suggestions, and Agentic Autopilot for schema-validated planner steps that BabyChain executes automatically.

The product has one invariant: every output becomes the next input.

• Website: https://babychain.babysea.live
• GitHub: https://github.com/babysea-community/babychain

If you run model chains in a node-graph workbench today, BabyChain is the opinionated image/video version of that workflow: normalized, self-hosted, API-first, and durable by default.

Why we built it: visual chains need a product contract

Real generative media work is rarely one model call. It is an image model feeding an image-to-video model, often with a refine step in the middle and a video-to-video step at the end. Canvas tools made that composable. ComfyUI made the node graph familiar, and Comfy Cloud exposes an API for submitting workflow JSON, tracking async jobs, and retrieving outputs.

The wall we kept hitting was one layer higher: turning a visual chain into a stable product contract. We needed one authenticated endpoint, normalized generation_* inputs across providers, server-side credentials, idempotent retries, signed callbacks, durable run state, and a canvas that edits that contract directly.

BabyChain's design goal was to make that distance zero.

Design the chain on a canvas. Call the same chain from your backend. Those should not be two different systems.

What ships today

• Multi-flow canvas studio. Many independent image → video flows side by side on one permanent workspace, with autosave and a library of saved chains plus their results.
• 54 image and video model entries across Alibaba Cloud, Black Forest Labs, BytePlus, Google, OpenAI, and Runway, for 58,752 valid chain templates.
• Schema-true node cards, powered by Semantic Lady. Every card's fields, enum options, ranges, and defaults are generated from that model's normalized generation_* schema, so the UI cannot offer a parameter the API would reject.
• Agentic Workflow planner with Amazon Nova (Amazon Bedrock). Run chains in Self Control, Agentic Copilot, or Agentic Autopilot. Copilot proposes the next step for review; Autopilot writes and runs the next schema-valid step automatically.
• BYOK execution. Provider keys live in the server environment, never in the browser and never in caller requests. Caller apps authenticate with BabyChain API keys.
• Durable runs on AWS Aurora. Ordered steps, provider request ids, generation ids, outputs, failures, callbacks, agent checkpoints, and a timeline are all persisted. One signed callback delivers the terminal run when a webhook URL is supplied.
• Durable media storage. Completed outputs can be copied into AWS S3 or Vercel Blob before a step is marked succeeded, so previews, API responses, and downstream handoffs can use stable URLs instead of short-lived provider links.

Semantic Lady became necessary because BabyChain supports two execution worlds but keeps one request vocabulary. In BabySea mode, the BabySea SDK already gives us normalized generation_* inputs. In BYOK mode, BabyChain talks directly to provider APIs, but the canvas and API still expose the same normalized generation_* contract. Semantic Lady is the local SDK that gives BYOK mode a real schema layer: model metadata, provider model ids, field definitions, enum options, defaults, and constraints that BabyChain can validate before a provider request is sent. It does that without storing credentials or executing provider calls.

Agentic workflows without losing determinism

BabyChain's agentic runner uses the same state machine as a hand-authored chain. The difference is who writes the next step.

In Self Control, the human picks the model, prompt, and parameters. In Agentic Copilot, Amazon Nova reads the previous result, proposes a next prompt plus schema-valid fields, and pauses for human approval or edits. In Agentic Autopilot, the planner writes the next step and BabyChain executes it without an approval pause.

The important part is that the planner is not allowed to become a hidden runtime. Each suggestion is treated as data:

previous output + model schema + planner instruction
	-> Amazon Nova proposal
	-> Semantic Lady validation
	-> AWS Aurora checkpoint
	-> normal BabyChain step execution

That keeps the agentic path inspectable. Prompts, selected parameters, validation results, token usage, checkpoint state, run status, and final outputs all persist to AWS Aurora. A Vercel function can disappear between planner and provider calls, and the next poll still resumes from the database. Copilot and Autopilot are not separate systems; they are two modes on the same durable contract.

Self-host it in an afternoon

BabyChain is Apache-2.0 and built to be deployed, not hosted by us:

git clone https://github.com/babysea-community/babychain.git
cd babychain && pnpm install --frozen-lockfile
cp .env.example .env.local   # DATABASE_URL, owner login, provider keys
pnpm run aurora:migrate      # applies the schema, idempotent
pnpm dev                     # or use the one-click Vercel deploy button

For production, BabyChain is designed around AWS Aurora. For local development, it can also point at a local PostgreSQL database. The README walks through creating the AWS Aurora cluster, setting DATABASE_URL, applying the schema, and deploying the app on Vercel.

The rest of this post is the architecture: how a canvas workflow becomes durable infrastructure on AWS Aurora and Vercel.

The architecture: AWS Aurora remembers, Vercel advances

The naive way to run a multi-model chain on serverless is to hold the whole chain in one function invocation. That dies quickly. A single image → video → video-modify workflow can spend several minutes inside provider queues, and a stateless function should not be asked to babysit that entire wait.

The durable way is to make the database the only place workflow state lives:

AWS Aurora owns every fact about a run.
Vercel functions are stateless workers.
Each invocation advances a run by at most one step.
Any instance can pick up any run mid-chain.

When a caller creates a run, BabyChain persists the run and its ordered steps to AWS Aurora, may opportunistically advance the first ready step, and returns without waiting for the full chain. Each subsequent poll of GET /api/v1/chains/get/{runId}, or a cron sweep, loads the run from AWS Aurora, advances exactly one provider step (submit or poll), persists the result, and returns. Long chains survive serverless limits because no instance ever needs to outlive a step.

AWS Aurora Serverless v2 fits the workload: bursty, low-idle, spiky on demo days. The connection pool absorbs AWS Aurora wake-ups when a cluster is configured to pause with a 30-second connection timeout. For RDS endpoints, deployers keep ?sslmode=require in DATABASE_URL; BabyChain strips the driver-level query param and connects with TLS, including the RDS CA behavior expected by the Node.js pg client.

The schema: eight tables, one source of truth

Everything durable lives in one private AWS Aurora schema, babychain_private, applied idempotently by pnpm run aurora:migrate:

Two design details earned their keep:

The input_order sidecar. PostgreSQL jsonb does not preserve key order, but the public run resource echoes the caller's input back in API responses, and key order is part of how people read their own request. Run creation stores a small jsonb array of the caller's original key order alongside the canonicalized input, and the presenter re-applies it on the way out. It is a small detail, but it matters when an API response is also a debugging surface.

Guarded state transitions. Steps only leave the queued state through updates with a where status = 'queued' guard. That single predicate makes the fail-fast path race-safe: when a step fails, the runner marks the run failed and sweeps every still-queued downstream step to skipped (their input can never arrive) without ever clobbering a step that a concurrent invocation already started.

Idempotency end to end

Generative media is expensive enough that retries must not multiply spend. BabyChain makes idempotency a property of the whole pipeline, not one endpoint:

1. Run creation hashes the caller's Idempotency-Key per principal and stores it on chain_run with a unique constraint. A retried create replays the stored run: same id, same response, zero new provider calls.
2. Step submission derives a deterministic idempotency key per run, step, and chain version. If a function instance dies between submitting to a provider and persisting the result, the retry resubmits with the same key, and providers that honor idempotency can deduplicate server-side.

The same discipline applies on the way out: when a run includes a webhook URL, the terminal callback is claimed on the run row and each signed delivery attempt is recorded in callback_delivery, so concurrent instances do not both send the same terminal callback.

A canvas that cannot lose your work

The studio is a multi-flow React Flow canvas. Every edit autosaves to the canvas table in AWS Aurora, and surviving real-world usage took three iterations:

Debounced autosave is a data-loss bug with good intentions: it can drop the last burst of edits before a reload.

• A debounce-based autosave silently dropped the last burst of edits before a reload. We replaced it with a dirty flag plus a steady flush loop, so a flush is always at most ~1.5 seconds behind your latest keystroke.
• A sendBeacon final flush covers tab close, reload, navigation, and tab-hide through an owner-authenticated endpoint.
• Hydration runs exactly once per mount, so router refreshes can never reset live canvas state.

The result is the demo I like most: edit a prompt, log out, log back in on another machine. The edit is there, served from AWS Aurora. Close the tab mid-run, reopen, and the run resumes, because run progress was never in the browser to begin with.

Where the real pain lived: provider normalization

Six providers (Alibaba Cloud, Black Forest Labs, BytePlus, Google, OpenAI, and Runway), 54 supported model entries, 58,752 valid chain templates. Not one provider agrees on what "give me a 16:9 image" means.

The deepest rabbit hole was Alibaba Cloud output sizes. Each model family has different rules, documented nowhere and discovered only by probing the live API:

• qwen-image / qwen-image-plus accept exactly five sizes. Anything else is a 400.
• qwen-image-max and z-image-turbo cap each dimension at 2048.
• The wan2.6 / wan2.7 families enforce per-model pixel budgets.

Provider docs are a starting point. The live API is the truth.

So the adapter computes sizes per model. For budgeted models, a requested ratio w:h is fitted into a pixel budget P_max:

scale = sqrt(P_max / (w * h))
W = floor(scale * w / 16) * 16
H = floor(scale * h / 16) * 16

…and snapped-size models get a lookup table instead, because they allow no freedom at all. Wrong sizes now physically cannot be sent.

The same empirical attitude shaped everything at the boundary: Runway's per-endpoint pixel ratios, OpenAI's permanent quota 429s masquerading as transient rate limits, and BFL output URLs that expire after ~10 minutes (the UI shows honest loading and expiry states instead of leaking alt text).

One structural decision keeps this manageable: the canvas node cards are generated from Semantic Lady schemas (fields, enum options, ranges, defaults). BabySea mode gets normalized generation_* fields from the BabySea SDK; BYOK mode gets the same normalized surface from Semantic Lady instead of a pile of hand-built forms. The UI cannot offer a parameter the API would reject, because both are projections of the same source of truth.

What keeps it honest

BabyChain is built around runtime invariants instead of optimistic workflows. A chain should be able to fail cleanly, resume after an interrupted function, reject invalid model roles and normalized inputs before dispatch, and preserve canvas state even if the browser disappears mid-edit.

The runtime behavior we validated end to end:

Step fails             → run goes terminal, downstream steps skipped, caller sees the provider's real error
Function instance dies → next poll resumes the run from AWS Aurora, idempotent resubmit
Client retries create  → same run replayed, zero duplicate spend
Tab closes mid-edit    → sendBeacon flush, canvas intact after re-login
AWS Aurora wake-up     → 30s connection budget absorbs it when pause is enabled

The current project gate is 357 tests plus typecheck, lint, formatting, package checks, deployment preflight scripts, and production builds. The tests cover the runner, provider adapters, templates, API behavior, AWS Aurora migrations, Agentic Workflow validation, storage, cancellation, callback behavior, and the schema rules that keep the canvas and API aligned.

What I would do next

BabyChain is already usable as a deployable starter, but the next layer is about making runs cheaper to inspect, easier to share, and more autonomous without losing the schema discipline that keeps it predictable:

• Branching chains. The canvas already runs flows side by side; the runner should support fan-out inside one chain, such as one image feeding multiple video treatments.
• Team workspaces. Add multi-user accounts with per-key scopes and quotas on top of the existing api_key model.
• Run economics. Surface per-run cost estimates and provider spend from data already stored in AWS Aurora.
• Deeper agency. Let the planner choose topology, not only downstream prompts, while keeping the same validation and checkpoint receipts.

The takeaway

Statelessness is a feature you design for, not a constraint you fight. Once every fact about a run lives in AWS Aurora (runs, steps, provider ids, outputs, failures, callbacks, canvases, audit, agent checkpoints), serverless time limits, cold starts, and instance churn stop being the center of the system. Vercel gives the control plane instant deployment; AWS Aurora gives it durable memory.

Design on the canvas. Ship the same contract as an API. Let the database remember everything.

Creators and developers: deploy it, chain your own models in your own cloud, and tell us what you automate first.

• Try it: https://babychain.babysea.live
• Deploy it: https://github.com/babysea-community/babychain

Hackathon note

BabyChain is our entry to the H0: Hack the Zero Stack with Vercel v0 & AWS Databases hackathon. This post was created for the purposes of entering that hackathon. #H0Hackathon