activeStandardy

Web Publishing Automation Standard

Standard for publishing websites, previews, landings and small applications through an automated path.

2026-06-07automation

Web Publishing Automation Standard

Status: draft / active reference
Module: Standards And Decisions
Source: ../intake/2026-06-07-w1a-www-stack-publishing-automation.txt
Related: software-project-best-practices.md, software-project-master-brief.md, ai-native-architecture.md, ai-architecture-scalability-blueprint.md

Purpose

This standard defines how RSYSTEM should publish web projects, previews, landings, and small applications with a single automated path from local work to deployed URL.

It is meant to support vibe coding, rapid iteration, preview environments, and clear deployment ownership.

Core Principle

Claude Code and similar coding agents should work close to the terminal, Git, CLI and MCP where available.

The deployment path should be simple:

local edit -> git -> automation -> hosting -> URL -> log/report

Publishing Strategy

Recommended split:

  • Claude Code writes or updates code locally.
  • Git becomes the source of truth.
  • n8n orchestrates triggers and follow-up.
  • Hosting provider receives deploys.
  • The system stores the resulting URL, status and logs.

Main Tooling Role Split

Git

Use Git as the canonical project state and review layer.

CLI

Use CLI for deploys, checks, logs and reproducible automation.

MCP

Use MCP where a stable official integration exists.

REST API

Use REST API as fallback or for automation orchestration through n8n.

Recommended Provider Roles

Vercel

Best for:

  • Next.js,
  • preview deploys,
  • fast iteration,
  • frontend-heavy app surfaces.

Cloudflare Pages / Workers

Best for:

  • simple sites,
  • forms,
  • lightweight landings,
  • static or edge-oriented projects.

Render

Best for:

  • backend services,
  • longer runtime jobs,
  • backup deployment targets.

Hostinger VPS + n8n

Best for:

  • orchestration,
  • automation,
  • webhook handling,
  • internal workflow control.

Publishing Flow

The recommended flow is:

  1. Agent updates code.
  2. Agent commits to Git.
  3. GitHub event or manual trigger starts automation.
  4. n8n detects the change.
  5. n8n deploys to the selected provider.
  6. n8n stores the URL and result.
  7. Notification is sent to the team.

Branch Strategy

Keep branch and environment behavior visible and predictable:

  • feature or beta branch for new work,
  • preview deploy for review,
  • main branch for production target,
  • explicit promotion step for stable work.

Deploy Rule

Do not hide deployment state inside the editor.

Every deploy should leave behind:

  • deployed URL,
  • deployment status,
  • logs,
  • timestamp,
  • source commit.

Output Visibility

Client-facing or internal stakeholders should see:

  • panel,
  • landing,
  • preview URL,
  • result,
  • not the raw internal workflow unless explicitly useful.

Automation Rule

n8n should be the orchestration layer for publication and follow-up:

  • trigger deploy,
  • capture URL,
  • record status,
  • store logs,
  • notify stakeholders,
  • optionally collect health signals.

Risk Rule

Avoid coupling Claude Code directly to every provider panel.

Prefer a stable abstraction:

  • Git,
  • CLI,
  • MCP,
  • automation layer.

Next Actions

  • Use this standard as the baseline for the upcoming web stack docs.
  • Link it from the standards index and planner.
  • Use it when defining branch/release behavior for RSYSTEM web projects.
  • Use web-hosting-provider-strategy.md to decide whether a given web artifact should go to Vercel, Cloudflare, Hostinger/n8n or Render.