Deploy by Suize: How an Agent Ships a Walrus Website End to End
Suize is an agent-first publishing service: one MCP tool call and one gasless payment turn a static build folder into a live, verified Walrus website.
Suize is an agent-first publishing service for static websites. It turns a build folder into a live site stored on Walrus, paid for with a single gasless USDC payment on Sui. There is no account, API key, or hosted wallet – the payer signs locally and becomes the site's owner. Suize won the Walrus track at the Sui Overflow hackathon.
Key takeaways
- An agent can build a whole site and still stall at the last step, because website publishing typically relies on human-managed accounts, credentials, and billing.
- Suize replaces that with payment-as-authorization: the payer signs a gasless USDC payment locally, Suize recovers the payer's identity from the payment itself, and that identity becomes the site's owner.
- A single deploy crosses three independent systems – payment settlement, Walrus upload, and a Sui transaction – in a seven-step flow.
The Walrus track at Sui Overflow turned up a run of teams rethinking how agentic systems get built. The track challenged builders to use Walrus as a verifiable data platform for AI – giving agents long-term memory, persistent file access, and context they can share and carry across sessions instead of locking it into one app or model. We're spotlighting the winners one at a time – what they shipped, and how – starting with Suize.
Suize lets a coding agent publish a static website on its own – one tool call, one payment, no account, and no private key handed to a service. We talked to its builder @Sceat_, and pulled out the one idea worth borrowing: a publish flow where the payment is the login.
Where agents stall: the last step of publishing
You give Claude Code a spec. It scaffolds the project, writes the components, fixes its own build errors, and drops a finished ./dist in front of you. Then it stops.
Not because it can't deploy. Because deploying means creating an account, configuring a project, generating an API token, attaching billing, and clicking a button in someone's dashboard. Every one of those steps assumes a person. So the agent does the hard 95% and hands you the boring 5% – which is also the only part that produces a URL.
You can hand the agent a deploy token. Now a process you are supervising loosely holds a credential that can publish to your production hostname. Most builders quietly decide that's fine, right up until it isn't, and long-running agents are exactly where loosely-held credentials turn into incidents.
What Suize is, and who it's for
Suize is an agent-first publishing service for static websites. It turns a static build folder into a live, integrity-verified Walrus website with one gasless payment, and it does that without an account or API key.
It is designed for developers working through coding agents – Claude Code, Codex, Cursor. The agent points a local MCP server at a built folder, usually ./dist, and calls deploy_site. Suize provides a browser dashboard at suize.io/#/sites for developers who would rather connect a wallet and drop a folder in.
The real challenge: autonomy without custody
The hard engineering problem, as Sceat frames it, was making deployment autonomous without making Suize custodial: a remote agent needs to pay for storage, but Suize should never hold the payer's private key. His first direction went the conventional route – a hosted backend, wallet authentication, subscriptions, and hosted wallet infrastructure. It worked, but it also introduced custody questions, more operational state, and too many concepts for a simple publish action. A hosted MCP server would need access to a key to authenticate for payment, which would be a weak trust model.
Another challenge was a timing boundary: payment settlement is fast and irreversible. You cannot architect around it. Walrus storage and the ownership record that follows it take longer. A failure in between must not charge twice, and must not leave someone paid-up with no site.
Inside the stack
Suize is a Bun and TypeScript monorepo: React 19 and Vite for the frontend, Cloudflare Workers for the paid publishing API and for serving sites, Cloudflare edge cache plus R2 in front for delivery speed.
The publish path runs like this. The agent or browser requests a deployment. Suize answers with an HTTP 402 Payment Required quote. The user's local key signs a gasless USDC payment, and a stateless, open-source x402 facilitator verifies and settles it. Suize uploads the site files to Walrus, writes and submits a Sui Move transaction recording the Walrus references and the recovered payer, and returns the live URL and Site ID.
A single deploy crosses three independent systems in a seven-step flow, and the payment identifies the owner, funds the storage, and doubles as the receipt used for replay protection.
Three implementation choices worth reusing
1. Store both IDs
The content ID retrieves the bytes; the object ID is what you need to inspect or extend the storage period later. Keep only the content ID and paid extensions get much harder.
2. Upload permanent blobs and hand the object to your service wallet
const query =
``epochs=${epochs} +
``&permanent=true +
``&send_object_to=${serviceWallet};
permanent=true means the blob cannot be deleted before its expiry – a single store is currently capped at 53 epochs, roughly two years on Mainnet.
3. One quilt, one manifest
A static site can be hundreds of small files, and storing each as its own Walrus blob would pile up per-blob overhead. Suize packs them into a single Walrus quilt instead – one blob that bundles many files, each addressable by a patch identifier per path – which is far more cost-efficient for lots of small files. A small manifest blob, whose hash is anchored in the Sui Site object, ties it together. Serving verifies the manifest and every file against that anchor, which is what lets a CDN sit in front without becoming trusted storage.
Where Walrus fits
The property Sceat wanted was survivability: the published artifact should survive independently of Suize's own application server. An ordinary object store would make Suize's infrastructure the final authority over every site it hosted. Walrus provides content-addressed data, a storage lifecycle that can be extended and a Sui integration that ties a site's files, ownership, payment receipt, and paid-through date together without inventing a second trust system.
What paid off
Payment-as-authorization paid off more than the team expected. The same signed object pays for the deployment, identifies the payer, and produces the receipt used for replay protection – so accounts, API keys, hosted login, and a separate ownership transfer all fell away at once.
Rough edges & lessons learned
The unpleasant surprise was latency: content-addressed storage is not automatically low-latency hosting. A cold aggregator read may reconstruct data from slivers – the erasure-coded fragments Walrus splits a blob into – and freshly certified data can briefly hit propagation or cached-404 behavior. Suize answered with content-addressed edge and R2 caches, background warming, and retry handling.
Two more rough edges: Mainnet publishing needs an authenticated publisher or relay, because storage consumes real SUI and WAL. Plus, every Walrus blob is public by default – so private sites need to be encrypted with Seal, gated by a Move allowlist, and decrypted in the browser, rather than treating an obscure blob ID as if it were access control.
The lesson the team draws: design idempotency before you accept money. Every retry must either finish the original work or return the result already produced.
What's next for Suize
The next phase is adoption and hardening rather than more features: easier first-time setup, better publishing observability, broader agent-client compatibility, and making the open-source facilitator easier for other people to run. Further out, he's floated a project layer – GitHub Action publishing, preview deployments on pull requests, and rollback by repointing a domain at an earlier immutable Site.
Build with Walrus
Walrus is the Verifiable Data Platform for AI builders: the foundation to store and manage your data, persistent, portable, and under your control across apps, providers, and agents. Start with the Walrus quickstart, or bring questions to the Discord.
FAQ
How to build on Walrus?
Walrus is a Verifiable Data Platform for AI builders – programmable storage where your data stays persistent, portable, and under your control across apps, providers, and agents. To start building, head to the Walrus docs or the Github.
How do autonomous agents access and pay for data?
An autonomous agent can pay for data itself by signing a payment that also authorizes the action, with no account, API key, or hosted wallet in between. The agent requests a resource, gets an HTTP 402 Payment Required quote, and its local key signs a gasless payment that an open-source facilitator settles. Suize uses exactly this for publishing: the settled USDC payment funds Walrus storage and identifies the site's owner in one step.
How does Suize differ from using Walrus Sites directly?
Walrus Sites gives you more control and lets you update an existing site object. Suize trades some of that flexibility for a smaller agent-native publish flow – one MCP tool call, payment over HTTP 402, no credentials. Each Suize deployment is immutable and gets a fresh Site ID and URL.
Do I need a Suize account or API key to publish?
No. There is no signup, no account, and no API credential. Point the local MCP server at your build folder, your local key signs a gasless USDC payment, and the address recovered from that payment becomes the owner of the site.
Does Suize hold my private key?
No. Signing happens locally, in your own environment. Suize recovers the payer's identity from the settled payment, which is why it never needs custody of a key to attribute ownership.
Can I publish a private site?
Yes. Private sites are encrypted with Seal before upload and gated by a Move allowlist. The browser decrypts locally once a connected wallet proves access. This matters because every Walrus blob is public by default.
About Walrus
Walrus is a Verifiable Data Platform for builders in AI and onchain finance. No more fragile foundations: Walrus finally makes it possible to verify where data came from, prove it hasn't been tampered with, and know it's always available, without compromising on speed. It is the foundation for applications where unverifiable data can cause irrecoverable losses. The more we trust AI and onchain finance with our money and decisions, the more mission-critical this becomes. Created by the ex-Meta engineers behind Sui.
