> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gradial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Publishing & Releases

> How ACI stages, activates, and rolls back content releases with atomic publishing and instant rollback.

Agentic Content Infrastructure (ACI) treats publishing as a first-class operation. Every publish is staged, validated, and activated atomically. Every release is immutable. Every rollback is instant.

## The Two-Step Model

Publishing in ACI is always two steps: **stage**, then **activate**.

```mermaid theme={null}
flowchart LR
    subgraph "Step 1: Stage"
        A["Compiled\nPayloads"] --> B["Render\nPages"]
        B --> C["Upload to\nCDN"]
    end

    subgraph "Step 2: Activate"
        D["Flip\nPointer"]
    end

    C --> D
    D --> E["Live\nSite"]

    style A fill:#6366f1,color:#fff
    style D fill:#22c55e,color:#fff
    style E fill:#22c55e,color:#fff
```

**Staging** is the heavy lift. ACI takes the compiled payloads from the content compiler, renders them through your code capsule (producing static HTML for SSG pages or compiled JSON for SSR pages), and uploads everything to the CDN alongside your current live site.

During staging, nothing changes for your users. The current site continues serving normally.

**Activation** is a single pointer update. The CDN's routing configuration switches from the old release to the new one. This is atomic: your users see either the old site or the new site, never a mix.

## Delta Publishing

ACI doesn't rebuild your entire site on every publish. The content compiler's dependency graph tells ACI exactly which pages were affected by a change.

<CardGroup cols={3}>
  <Card title="Typo Fix" icon="pen">
    1 page changed, 1 page re-rendered. The other 49,999 pages are untouched.
  </Card>

  <Card title="Footer Update" icon="table-layout">
    Shared section changed. ACI re-renders just the footer, not the 500 pages that use it. Pages are assembled at the edge, so shared pieces update independently.
  </Card>

  <Card title="Full Publish" icon="globe">
    New code capsule with breaking changes. All pages re-rendered, but in parallel. Minutes, not hours.
  </Card>
</CardGroup>

Fingerprint-based hashing provides a second layer of optimization. Even if a page is "affected" by a change, if the compiled payload hash is identical to the previous release, ACI skips the render entirely. This handles cases where a change is technically in scope but produces no visible difference.

## Rendering

When ACI renders a page, it hands the compiled payload to your **code capsule**, the built artifact from your frontend project. The capsule is your actual Astro, Next.js, or SvelteKit code, compiled into a portable, self-contained renderer.

ACI supports two rendering modes:

| Mode                             | How it works                                                                       | When to use                                                                              |
| -------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| **SSG** (Static Site Generation) | Pages rendered to HTML at publish time. Uploaded to CDN as static files.           | Marketing pages, blog posts, product pages, i.e. content that doesn't change per-request |
| **SSR** (Server-Side Rendering)  | Compiled JSON payloads deployed to edge functions. HTML generated at request time. | Dynamic content, authenticated pages, real-time personalization                          |

Both modes go through the same staging and activation pipeline. Both benefit from the same validation and rollback guarantees.

<Info>
  Rendering runs behind a sandboxed renderer boundary, so your frontend code stays isolated from other customers' content and from the host environment. Today that boundary is backed by managed Node processes with a warm worker pool. Because everything runs behind the same boundary, stricter process, container, or microVM isolation can be introduced as requirements grow, without changing the frontend contract.
</Info>

## Edge Composition

ACI does not serve monolithic HTML files. Instead, it breaks each page into independent pieces and assembles them at the edge when a user requests a page.

A page is composed from a layout skeleton (the overall HTML structure), the page body (the content unique to that route), and shared sections (navigation, footer, sidebar). Each of these is rendered and stored independently. When a request arrives, a lightweight edge function fetches the pieces in parallel and stitches them together before responding.

```mermaid theme={null}
flowchart LR
    A["User Request\n/pricing"] --> B["Edge Function"]
    B --> C["Layout Skeleton"]
    B --> D["Page Body\n(/pricing)"]
    B --> E["Navigation"]
    B --> F["Footer"]
    C --> G["Assembled\nHTML"]
    D --> G
    E --> G
    F --> G
    G --> A

    style B fill:#6366f1,color:#fff
    style G fill:#22c55e,color:#fff
```

This is what makes shared content updates so efficient. When the footer changes, ACI re-renders just the footer. The 50,000 page bodies and the layout skeletons are untouched. The edge function picks up the new footer on the next request and assembles it with the existing pieces. No full-site rebuild required.

<CardGroup cols={2}>
  <Card title="Independent Updates" icon="puzzle-piece">
    Shared sections like navigation and footers update once, not once per page. A site with 50,000 pages and a footer change re-renders 1 artifact, not 50,000.
  </Card>

  <Card title="Fast Assembly" icon="bolt">
    The edge function fetches pieces in parallel and assembles them with simple string substitution. Frequently-requested pieces are cached in memory, making most page loads near-instant.
  </Card>

  <Card title="Personalization at the Edge" icon="users">
    The same edge router that assembles pages also handles personalization. ACI compiles multiple variants per page (by audience, locale, or campaign), and the edge function serves the right one based on a cookie or header. No decision service. No runtime latency.
  </Card>
</CardGroup>

## Releases as Immutable Artifacts

Every publish creates a **release**, an immutable artifact that captures the complete state of your site at that moment:

* The content version hash
* The code capsule version
* Every rendered page and its content hash
* The route table
* The CDN configuration

Releases are numbered and permanent. They're never modified or deleted. This means you always have a complete record of what was live at any point in time.

## Instant Rollback

Because releases are immutable and the CDN serves from a pointer, rollback is trivial:

```mermaid theme={null}
sequenceDiagram
    participant Operator
    participant ACI
    participant CDN

    Note over CDN: Serving Release N+1
    Operator->>ACI: Rollback to Release N
    ACI->>CDN: Update pointer → Release N
    Note over CDN: Serving Release N
    ACI->>Operator: Rollback complete (< 1 second)
```

No rebuild. No re-upload. No waiting for a CI/CD pipeline. The previous release is already on the CDN. ACI simply switches the pointer.

This changes the risk profile of publishing fundamentally. Going live is no longer a high-stakes operation. If something is wrong, you roll back in seconds and investigate at your leisure.

## Your Hosting, Not Ours

ACI is not a hosting provider. Your live site runs on infrastructure built for high availability and low latency at global scale (CloudFront, Vercel, or others). ACI orchestrates the build and deploy, then your hosting platform handles serving.

For the full picture on how ACI integrates with your hosting platform, see [Hosting →](/aci/platform/hosting).

***

*Next: [Preview →](/aci/architecture/preview)*