AI agents are getting very good at producing static sites.
Give an agent a product idea, a docs outline, or a screenshot, and it can often edit the code, run the build, and leave behind a dist/, build/, or .zip artifact. For a local demo, that is enough. The next request is where the boundary gets interesting: “ship it.”
What should the agent do with those files? Which credential should it use? What proves the URL is live? If the user wants to roll back, are we rolling back a file set, a route, or a temporary deployment hidden inside a provider dashboard?
Static publishing is often described as an upload problem. Pick object storage, a CDN, or a Pages product. Upload the files. Get a URL. That user experience matters; products such as Cloudflare Pages Direct Upload and Netlify Drop have made that clear. Appaloft is focused on the layer underneath it: when the upload can be started by an AI agent, CLI, Web UI, or CI job, it should still go through the deployment control plane.
This post follows A deployment control plane for the AI era, Skills are not MCP, and AI agents should not log in by copying cookies. AI can produce the files. Publishing them should still be reviewable, auditable, readable after the fact, and reversible.
dist/ Is Not Deployment State
A static build output is usually simple: HTML, CSS, JavaScript, images, fonts, a manifest.json, and maybe a 404.html or an index.html fallback for a single-page app.
The harder part is what happens after those files leave the machine.
- Which files are included in this publication?
- What digest does each file have?
- Is the route plain static files, SPA fallback, or hash routing?
- Which project, resource, and environment owns the publication?
- Were unsafe paths, duplicate paths, suspicious secrets, oversize files, and known bad fixtures checked?
- Is the returned URL immutable, or is it a current alias?
- Does rollback switch an alias, or upload old files again?
- Where are storage usage, bandwidth attribution, and cleanup responsibility recorded?
If the answers live only in provider UI or terminal logs, the agent is pushed toward guessing. It may call a cloud provider API directly, ask the user to paste a token, or treat “files uploaded” as the same thing as “the site is live.”
That is the boundary Appaloft is trying to keep. dist/ is input. The control plane needs to turn it into a static artifact publication.
Make Publishing A Public Boundary First
The public Appaloft core should not know Appaloft Cloud’s commercial domain, object storage choice, CDN strategy, billing model, or abuse process. It should own the neutral static artifact publishing semantics.
That is where StaticArtifactPublisherPort, StaticArtifactStorePort, and StaticArtifactRouteProviderPort fit. The application layer can accept a source path, inline file payload, or zip archive, then compose manifest creation, payload handling, storage, route activation, and publication readback through ports.
For a caller, the entrypoint should stay boring:
appaloft static-artifacts publish ./dist
appaloft static-artifacts publish ./dist.zipHTTP/API should expose the same meaning instead of giving Web or agents a separate upload shortcut:
POST /api/static-artifacts/publishPOST /api/static-artifacts/publish-payloadPOST /api/static-artifacts/publish-archiveGET /api/static-artifacts/publications
Those operations do not decide whether Cloud eventually uses R2, S3, MinIO, Cloudflare Pages, an IPFS gateway, or a local filesystem adapter. They define the product fact: here is a set of static files; publish it as a readable artifact publication.
That matters for AI. An agent can inspect a project, build it, choose dist/ or a zip archive, and call the same CLI/API/operation catalog path. It does not need to know the private Cloud bucket, provider account, DNS route index, or cache purge implementation.
Do The Unglamorous Checks Before Upload
Static files sound safe until the upload surface is open to browsers, CI jobs, and agents.
Paths may contain ../. Two entries may target the same path. File sizes may exceed policy. Base64 may be malformed. A demo can accidentally include .env, a private key, a database URL, or a provider credential. Someone can upload a credential-harvesting page, malicious script, or archive entry designed to escape extraction.
That is why Appaloft Cloud splits static artifact publishing into policy, scan, store, route, and readback steps. The repository already has code-owned fake readiness and a production-shaped guard scanner boundary: safe fixtures can publish, unsafe and oversize fixtures are rejected, and scan output does not echo raw secrets or paths. Real third-party malware scanning, URL reputation, object storage readback, CDN routing, DNS/TLS, and cache purge still need go-live evidence. They should not be described as finished just because the abstraction exists.
That caveat is less shiny. It is also closer to a real platform.
The faster AI generates artifacts, the less the platform should trust artifacts by default. The control plane has to reject obvious bad inputs before writing to storage or activating a route.
Route Intent Belongs In The Model
Not every static site routes the same way.
A documentation site may map paths directly to files. A single-page app may need unknown paths to fall back to index.html. A content-addressed or hash-routing flow may not need provider rewrites at all.
If that distinction only lives inside a Cloud provider adapter, the publication record becomes hard to explain. Appaloft keeps the caller’s intent in a provider-neutral routeBehavior:
static-filessingle-page-apphash-routing
This is not a Cloudflare, R2, Pages, or IPFS field. It only says how this artifact wants to be served. A real provider adapter can later translate it into a CDN rewrite, Pages route rule, object gateway fallback, or hash-routing hint.
This is also where the public/private boundary helps. Public Appaloft can understand route behavior. Cloud can decide the official default domain, Worker route index, object storage provider, and cache strategy. Neither side needs to leak the other’s concerns.
Readback Matters More Than The URL
The easiest thing to return after publishing is a URL. It is also the easiest thing to overtrust.
A URL may be allocated while files are still missing. An alias may still point at the old version. A CDN may not have refreshed. A default-domain route index may exist while edge readback fails. A provider API may return success while the object cannot be read back.
Static artifact publication needs readback evidence. On the Cloud side, Appaloft records the manifest digest, storage reference, store provider key, route provider key, resource id, route behavior, and provider readback evidence. That evidence does not expose buckets, endpoints, account ids, or credentials. It says whether a provider step is verified, deferred, or blocked, and it can point to an external-system gap when needed.
That gives the UI, CLI, and AI agent a more honest answer: “The publication is recorded, but real CDN readback is still deferred.” Or: “The immutable URL is verified, and rolling back the current alias will switch the route instead of uploading files again.”
The agent should not pretend it understands a provider dashboard. It should read Appaloft’s readback.
Rollback Should Not Mean Upload Again
Static sites are a good fit for versioned publications. Each publish creates an immutable artifact, and the current URL points at one of those versions.
That lets rollback become an alias or route decision, not “rebuild, reupload, and hope the old dependencies still install.” Appaloft’s fake publisher already models versioned URLs, alias rollback dry-runs, cache purge as a deferred gap, and usage attribution. How a real provider later performs cache purge, route activation, or object lifecycle work belongs to adapters and operational evidence.
This is useful for agents too. If the user says “roll back that static site,” the agent should not guess the previous Git commit or delete objects by hand. It should query publications, choose a verified version, produce a rollback plan, and go through an accepted control-plane action.
This Is Not The Same As Blueprint Deployment
Appaloft can already treat a static site as a normal workload: create a static-site resource, build it into a runnable static server, and deploy it to a user-owned server.
Static artifact publishing is a different path. It means: “I already have the built files; publish these files to a managed static surface.” It fits AI agents, browser uploads, CI artifacts, design-tool exports, documentation builds, and frontend demos that need a public URL.
Both paths should go through the control plane, but they solve different problems:
- BYOS static-site deployment is closer to runtime workload deployment.
- Static artifact publishing is closer to managed file publication.
Mixing them makes the model fuzzy. Keeping them separate lets an agent choose the right entrypoint: deploy a resource, or publish an artifact.
What Is Still Rough
There is still real work here.
Cloud’s default R2/S3-compatible object store, Worker default-domain gateway, DNS/TLS, cache purge, abuse takedown, external malware or URL reputation providers, lifecycle cleanup, and production run evidence cannot be waved away with “we will plug it in later.” They need provider configuration, readback, fail-closed policy, and cleanup boundaries.
What is already clear is the product shape. Static files produced by an AI agent should not skip Appaloft. They should enter an explainable publication workflow. Public Appaloft defines the neutral entrypoint. Cloud injects private policy, scanning, storage, routing, audit, and provider evidence.
AI makes generating a site faster. Shipping it should not become more casual. A good upload experience can feel light, but it still needs to leave facts behind: what was published, who published it, where it routes, how it was verified, and how to undo it.