An independent publication needs a dependable way to write, review, publish, correct, and preserve its work. It does not automatically need a database answering every request for an article.
TAHAI-Press separates those jobs. Editors maintain structured content and media. A build produces the reader-facing site. Hosting serves the generated files. That separation makes the publication's source, delivery, and recovery paths easier to examine. [1]
This walkthrough covers a first publication and its operating routine. It is not a client case study, a performance benchmark, or a claim that static publishing removes every maintenance responsibility.
Version note: paths and commands were checked against repository snapshot 00c4236, whose package metadata identifies version 3.0.3, on October 20, 2026. This is a documentation baseline, not a claim about which version is installed on your website or which release has passed your acceptance checks. Use the instructions supplied with your chosen release. [2]
Understand the five parts before connecting accounts
A simple architecture is most useful when its responsibilities stay clear.
| Part | Responsibility |
|---|---|
| Publication source | Article records, author information, site settings, and approved media. |
| Editing interface | Pages CMS or the included writing tools help people work with those files. |
| Git repository | Stores committed source changes and their history; access still needs deliberate configuration. |
| Build and checks | Validate the source and generate the files readers will receive. |
| Hosting | Deliver the approved output at the publication's address. |
Pages CMS edits files in a GitHub repository; it does not replace the site generator or the deployment platform. TAHAI-Press supplies the publication build, while Cloudflare Pages can build and deploy from the connected repository. [3][4]
The important distinction is no database in the public article-serving path, not “no dependencies anywhere.” The reviewed package declares build and tooling dependencies. Accounts, permissions, backups, domains, and updates still need an owner. [2]
Establish the working copy and prove it locally
Start with a reviewed copy of the TAHAI-Press source in a repository controlled by the publication. Decide who can change production content before connecting the editor or the host.
Keep the release's package.json, lockfile, configuration, and documentation together. The reviewed package requires Node.js 22 or newer; use the version documented for the release and deployment environment you select. [2]
Inside that working copy, the basic local sequence is:
node --version
npm ci
npm run ci
npm run preview
These commands perform different jobs. npm ci installs dependencies from the lockfile and fails when the lockfile conflicts with package.json, instead of silently updating it. npm run ci invokes TAHAI-Press's own quality pipeline. They are not interchangeable. [2][5]
The reviewed repository documents the local preview at http://localhost:8788 and generated output under dist/. Its quality pipeline includes source validation, tests, generated-output checks, an HTTP smoke check, and release-proof creation. Read the actual output and investigate failures rather than treating a command invocation as proof of success. [1][2]
Save the source revision and successful check results with the release record. An attractive preview is useful, but it does not identify which source produced it.
Set the publication identity before writing around the template
The primary site settings live in content/site.json. Article and author records have their own directories, and public images and documents have separate upload locations. [1]
content/site.json
content/articles/
content/authors/
content/categories/
public/uploads/images/
public/uploads/documents/
Replace the demonstration name, description, publication address, public contact, and visual identity. Review the navigation, contributor information, categories, sample stories, and policy text. A real publication should not accidentally speak in the template's voice or list someone else's example content as its own.
The included Launch Desk at /setup/ supports guided setup while template mode is enabled. The reviewed documentation also permits direct editing of the source. Choose one clear configuration path and retain a backup before applying a launch package. [1]
Set the intended HTTPS site_url before checking production canonical links and feeds. Keep template mode enabled during demonstration setup, then deliberately disable it for an approved launch. TAHAI-Press documents indexing restrictions for template and preview builds. Those restrictions are not authentication and do not make unpublished material confidential. [1][4]
Keep sensitive reporting, credentials, and private source records out of a public repository and public upload folders. A private repository also needs a review of the generated output: files actually deployed to a public host may be directly accessible.
Build one complete article before importing an archive
The fastest way to understand the workflow is to finish one useful, original article—not to start by importing hundreds of incomplete records.
Choose a topic your publication can explain accurately. Write the headline, reader-facing summary, body, author attribution, and intended publication date. Select an appropriate category and record the sources a reader needs to evaluate the work.
The reviewed content model stores articles in content/articles/*.json. The slug must match the JSON filename and becomes part of the public address. For example, an article with the slug reading-a-meeting-agenda would use content/articles/reading-a-meeting-agenda.json and a generated route under /stories/reading-a-meeting-agenda/. This is an illustrative filename, not a claim that the story exists. [6]
Choose the article type around the reader's task:
| Format | Use it for |
|---|---|
| Written article | A story or guide whose body is the primary content. |
| PDF-first record | A source document with a meaningful reader-facing introduction. |
| Written article with supporting PDF | Explanation first, followed by the supporting document. |
| Externally hosted document | Context and an explicit link to a document controlled by another host. |
Those formats correspond to the reviewed content model's standard, pdf, mixed, and external types. Do not create a second custom content structure just to handle a document. [6]
A document-led article still needs to explain what the file is, why it matters, who produced it, and any important limitations. Preserve a direct document link and a usable text alternative. Check that the reader can reach the source even when the embedded viewer does not work.
Keep drafting, saving, and publishing distinct
The included Writer Desk at /studio/ is a browser-local drafting and export tool. It does not publish an article merely because someone types, previews, or saves a local draft. Export the draft and move it into the repository's editorial workflow. A local browser draft is not an independent backup. [7]
For repository-based editing, Pages CMS reads .pages.yml from the repository root. TAHAI-Press already supplies that configuration; preserve it rather than replacing it with a generic getting-started example. [3][7]
The documented article workflow begins under Publishing → Articles, with a new entry left as Draft while the editor completes the content. Publication requires the relevant source/content, rights/privacy, and accessibility review confirmations. A checked box records a decision; it does not perform the review. [7]
Use a review branch for work that should not go straight to production. Saving a repository edit, changing an article's status, passing a build, and deploying to the public domain are separate events. Keep that distinction visible in the publishing procedure.
Also distinguish publication state from access control. A draft can be absent from generated reader pages while still visible to someone with repository access—or to anyone when the source repository is public. [6]
Prepare media for readers, not just for the upload button
Start with the minimum media that helps the article. Write useful image descriptions, preserve necessary credits, review publication rights, and choose a crop that does not remove important context. Check the result on a narrow screen as well as a wide one.
For PDFs, confirm the correct version, legible content, reader-facing title, source information, and direct-open path. Test the document itself, not merely the image of its first page. A polished article wrapper cannot repair an unreadable or mistakenly published source file.
Store approved public media in the release's documented upload directories. Keep originals and working material in the publication's controlled archive when they should not ship. Review dist/ before release; do not assume that an unlinked file is inaccessible.
For a first edition, one complete article with one properly described image is a better test of the workflow than a visually busy front page filled with unfinished entries.
Connect Cloudflare to the build—not the source folder as a website
For the reviewed Git-connected setup, the TAHAI-Press deployment documentation specifies the following contract. Cloudflare's dashboard must actually be configured to match it; the descriptive JSON file in the repository is not automatically applied by Cloudflare. [4]
| Setting | Reviewed value |
|---|---|
| Framework preset | None |
| Production branch | main, unless the publication deliberately selects another branch |
| Root directory | Repository root |
| Build command | npm run build:cloudflare |
| Build output directory | dist |
| Node version | 22 in the documented deployment configuration |
Keep preview branch deployments available for review. The intended sequence is: edit the source on a branch, inspect the check results and preview, approve the change, merge to the configured production branch, then confirm the production deployment. Cloudflare's Git integration builds and deploys changes from the connected repository. [4][8]
Deploy the generated site, not the whole working directory. The source tree, development dependencies, internal notes, and test artifacts are not the public publication.
Before changing domain records, confirm which Cloudflare project or Worker currently owns the hostname. Do not point a production domain at a new target simply because a preview looks right. Coordinate the cutover and keep the prior working deployment available for recovery.
Use a release check that tests what people actually do
Inspect the whole article: introduction, lower sections, sources, document controls, related coverage, and footer. Start with a narrow viewport and repeat on a desktop display. Increase browser zoom. Follow links with the keyboard. Check that content remains understandable without optional JavaScript.
Then test the publishing paths. Can the intended reader find the article from the homepage or archive? Does search lead to the right route? Do the direct document links work? Are the title, description, author, and sharing details appropriate for the article rather than inherited from a sample?
Check both sides of the release boundary. The approved production site should have the intended indexing behavior; previews and demonstrations should retain their restrictions. Test an unknown URL on the actual host so that a pleasant error page does not hide incorrect routing.
Treat a clean automated report as one input. It cannot tell you whether a paragraph is accurate, a source genuinely supports a claim, a crop changes the meaning of an image, or a contact button sends readers to the wrong business.
Get the publishing release and handoff checklist. It separates source checks, editorial review, preview review, production verification, and recovery.
Plan corrections and recovery before the first incident
For an ordinary correction, retain the article's permanent slug. Update the content, use a meaningful update date when appropriate, and explain a material correction to readers. Git history preserves committed source revisions; a public correction note serves a different purpose by explaining what changed. [7]
When a permanent URL must change, the reviewed workflow supports previous article URLs and generated redirects. Review the redirect target and test the deployed result. Do not leave the old link broken or redirect every retired story to an unrelated homepage. [6][7]
Scheduling also deserves a realistic expectation. The included workflow checks for due scheduled articles hourly, and the editor guide warns that GitHub's scheduler can run late. Confirm the workflow is enabled; do not promise an exact-minute release from that mechanism. [7]
For a bad deployment, Cloudflare Pages supports restoring a prior successful production deployment. That is a delivery rollback, not a correction to the repository. Correct or revert the source through the approved workflow as well, otherwise a later build can reintroduce the same fault. [4][9]
Keep a separately retained backup of source, approved media, and release information. Git history in a single account is not your entire recovery plan.
Hand over the publication—not just a link
The owner should receive the source and its revision, generated release output, media inventory, configuration record, deployment instructions, review checklist, and a plain-language explanation of how to publish and correct an article.
Record which account owns the repository, domain, hosting project, and editing access. Transfer access through the providers' approved controls; do not place tokens or passwords in the handoff ZIP. Identify who receives build-failure notices and who has authority to approve a production change.
Complete one supervised publishing cycle with the person who will own the work. Have them locate the source, prepare an edit, review the preview, identify the release, and explain recovery. Record unresolved questions rather than leaving them for the first urgent correction.
Database-free publishing is a strong fit when the central product is public content and a deliberate editorial release process. It is not, by itself, a complete solution for private customer accounts, complex transactions, or application features that require server-side authorization. Add those capabilities deliberately rather than describing the static site as something it is not.
Want the publication launched and handed over properly?
TAHAI Web Services offers defined implementation work around publication structure, TAHAI-Press setup, branding, migration where needed, Cloudflare delivery, accessibility review, and owner handoff. [10]
Discuss a publishing project or explore TAHAI-Press. Agree on the scope, deliverables, ownership, and completion checks before the work begins.
The goal is not merely a site that can be published. It is a publication its owner can keep publishing.
References
TAHAI-Press, README and architecture, repository snapshot
Read source00c4236.TAHAI-Press, Package metadata and scripts, repository snapshot
Read source00c4236.Pages CMS, Introduction and Configuration overview.
Read source · Configuration referenceTAHAI-Press, Git-connected publishing and deployment.
Read sourcenpm, npm ci.
Read sourceTAHAI-Press, Content model.
Read sourceTAHAI-Press, Editor workflow.
Read sourceCloudflare, Pages Git integration.
Read sourceCloudflare, Pages rollbacks.
Read sourceTAHAI Web Services, Engineering services.
Read source
Repository commands and paths were checked against source; no deployment was executed for this article. Recommendations are a practical editorial workflow, not reported customer results.