Instant publishing

How it works

Every publish in the dashboard is a git commit. After the commit, the site syncs the new content sha from its own handler, so the next request that renders content reads the latest version. No build or redeploy has to finish before editors see their changes on the live site.

Skip builds for content-only commits

Only set this up once your deployed site has a backend that syncs content at runtime: Alinea Cloud or a self-hosted backend. Without one, a deployment is how new content reaches your site, so skipping content-only builds would leave published changes offline.

Because content is synced at runtime, a commit that only changes content does not need a new deployment. On Vercel you can skip those builds with an ignoreCommand in vercel.json. The command exits successfully, which tells Vercel to skip the build, when the latest commit changed nothing outside the content directory:

{
  "ignoreCommand": "git diff --quiet HEAD^ HEAD -- . ':!content'"
}

It only looks at the latest commit. Every publish from the dashboard is a commit of its own, so that covers them. A push of several commits that ends with a content-only commit, such as a merge that pulled in published content, skips its build too: build it from the Vercel dashboard when that happens.

Check that it works

A skipped build shows as Canceled in the deployments of your Vercel project, and the list hides canceled deployments by default. Filter on Status → Canceled to find them: their log ends with "Ignored Build Step command returned exit code 0". To check the whole setup:

1. Publish a change in the dashboard.

2. Find the deployment of its commit: it shows as Canceled.

3. Load the page: it shows the change without a redeploy.

This checks both halves of the setup: content-only commits skip their build, and the site syncs their content at runtime.

Static pages

Static pages are revalidated for you. Every page that queries content is tagged, and after each commit the handler marks those pages as stale. The next visit is still answered from the cache while Next.js rebuilds the page in the background, and the visit after that gets the new content. No visitor waits for a render, and no revalidatePath call is needed. This includes pages generated with generateStaticParams: revalidation code in afterCommit that refreshes them by hand, such as revalidateTag('_N_T_/layout') or revalidatePath('/', 'layout'), can be removed.

Pages rendered at request time sync on their next render. The first one after a commit can still show the previous version while the shared content sha refreshes. Content pushed to your repository without the dashboard, for example a local edit, skips the handler: pages pick it up within five minutes, or within syncInterval seconds when your config sets it. Use the handler's afterCommit hook if other caches in your app depend on content, for example your own fetch tags. It receives the changed entries and the removed ones, see [Commit hooks](page:guides/deploy#commit-hooks):

import {cms} from '@/cms'
import {createHandler} from 'alinea/next'
import {revalidateTag} from 'next/cache'

const handler = createHandler({
  cms,
  afterCommit({entries, removed}) {
    const changed = [...entries, ...removed]
    if (changed.some(entry => entry.type === 'Product'))
      revalidateTag('products', 'max')
  }
})

export const GET = handler
export const POST = handler