Deploy

editkraft pages are ordinary Next.js pages — you deploy your app as usual (e.g. on Vercel). Two things are editkraft-specific: the environment variables and the revalidation on publish.

#Rendering

The render route init generates reads published content with the anon/publishable key and renders it with EditkraftPage:

import { EditkraftPage } from "@editkraft/react";
import { registry } from "@/blocks/registry";

export default async function Page({ params }) {
  const { slug } = await params;
  return EditkraftPage({ supabase, slug: slug.join("/"), registry });
}

For SEO, read ek_pages.meta in generateMetadata (title tag + meta description, editable per page in the Studio) and return it as title / description.

#Environment variables

init writes .env.editkraft.example with everything you need. The core:

  • NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY — for the public render (published content only, via RLS).
  • a revalidate secret — protects the webhook the Studio calls to revalidate after a publish.

Set these in your hosting environment (e.g. Vercel Project Settings).

#Revalidation

On publish, the Studio calls the revalidate webhook so the static page shows the new state immediately. The handler comes from the package:

// app/api/editkraft/revalidate/route.ts
import { createRevalidateHandler } from "@editkraft/react";

export const POST = createRevalidateHandler();

As a safety net you can also set export const revalidate = 30 on your render routes — then publishes appear within the interval at the latest, even if an on-demand revalidate ever fails to reach you.

#Updates

@editkraft/react and @editkraft/schema are npm packages in your project. You get new runtime features by bumping the version and redeploying — they don’t update on their own. The Releases page lists what landed in which version.

#Next steps