Keep it static.Make it editable for your customers.

A GitHub repository and a Vercel project.

GitHub: The website's repository, connected to Vercel via Vercel's Git integration. biberblog publishes with a fine-grained token for this repository only and pushes directly to main – so main must not require pull requests or status checks.

Vercel: Builds and hosts the website. A Vercel Blob store serves as temporary image storage while editing.

Node.js: Version 24, as specified in .nvmrc.

Everything else ships with the biberblog template – a regular Next.js project with the App Router.

Sort of — but deliberately much smaller.

biberblog gives clients CMS-like content editing without introducing a separate CMS application, content database or admin dashboard. It is an editing layer for static Next.js websites, not a full editorial platform.

No.

Published content lives in JSON files inside the repository. Published images become optimized files in public/. The website itself remains a static Next.js site.

In the same repository as the website.

Code, content and published assets stay together, so they can be versioned, transferred and restored as one project.

They can only edit what you explicitly make editable.

You keep control over the layout, components, styling and application code. You also define structural constraints such as collection fields and image dimensions.

Your frontend should still be designed to handle real-world content such as longer text, of course.

With one password per website and a signed session cookie.

The password is never stored in plain text: you hash it locally (Argon2id) and store only the hash as an environment variable in Vercel. After logging in, the browser receives a signed, HttpOnly session cookie. It is valid for about a year and renewed on every use, so your client rarely has to log in again.

Publishing and image uploads verify this session on the server. The GitHub token and all other secrets stay in the Vercel environment variables and never reach the browser.

Setting a new password ends all sessions at once. There is no rate limiting on login, so choose a strong password.

biberblog validates the open changes, processes changed images if necessary and writes the resulting content and assets to GitHub in one commit.

That commit triggers a new Vercel deployment. Once the new deployment is live, the client sees the updated static version of the website.

Every successful publish creates a Git commit.

Published content and assets therefore have a traceable history, and previous versions can be restored through Git.

Unpublished drafts are different: they only exist in the current editing session until they are published.

Yes.

The editor source code lives inside the project under src/system/. You can inspect it, restyle it, modify it or extend it if a project needs something different.

You do not have to. The point is that you can.

The published website is portable. The current editing workflow is not.

biberblog currently uses GitHub for publishing, Vercel for deployments and Vercel Blob for temporary image storage while editing.

If that infrastructure does not fit your project, biberblog is probably not the right tool.

Usually not.

biberblog is designed for one primary editor making occasional content changes.

If publishing content is a core business process with multiple editors, roles, approvals or frequent updates, use a CMS built for those requirements.

The project can leave with them.

The website, published content and assets live together as a normal project rather than being split across a proprietary content platform.

Another developer can take over without first migrating the website out of a CMS.

Every biberblog project contains its own copy of the system code, but it can still be updated from the upstream repository.

Use npm run system:status to check the installed version, available releases and local system changes. npm run system:update then merges a newer release into the project with a 3-way Git merge.

Project-specific changes are kept where possible, conflicts are surfaced for review, and dependencies, scripts and migrations are updated alongside the system. Nothing is committed automatically, so you can inspect, test and commit the update like any other project change.

The editor therefore stays visible and editable inside every project without giving up a central release path for fixes and new versions.