activeStandardy

Website Generator Stack

Defines stack routing for generated websites, surveys, dashboards and automation flows.

2026-06-07automation

Website Generator Stack

Status: draft / active reference
Module: Standards And Decisions
Source: ../intake/2026-06-07-w1b-website-generator-stack.txt
Related: web-hosting-provider-strategy.md, web-publishing-automation.md

Purpose

This standard defines the practical technology routing for RSYSTEM website and web-app generation.

It should be used when deciding whether a new web artifact should be built as:

  • a marketing page,
  • a landing page,
  • a survey or validation page,
  • a beta app,
  • a dashboard,
  • a backend-oriented service,
  • an automation-driven publishing flow.

Core Principle

Do not choose the stack by provider first.

Choose the stack by project type, interactivity level, lifecycle and automation needs.

Recommended mental model:

content-first web -> Astro + Cloudflare
Next.js app / beta UI -> Next.js + Vercel
backend-heavy service -> Render
automation and orchestration -> Hostinger VPS + n8n

Project Type Routing

Project Type Recommended Stack Primary Host Why
Marketing website Astro Cloudflare Pages Lightweight, content-first, fast and inexpensive
Landing page Astro Cloudflare Pages Good for quick campaign pages and message tests
Simple survey Static/Astro form Cloudflare Pages + n8n webhook Cheap validation flow with automation backend
Survey inside larger app Next.js Vercel Natural fit when the survey is part of a panel/app
Beta app / preview Next.js Vercel Branch previews, quick deploys and customer testing
Dashboard / web app Next.js Vercel Strong UI/app workflow and deployment ergonomics
Backend-heavy dashboard Next.js + service backend Render or Vercel + Render More server-like runtime when needed
Automation flow n8n Hostinger VPS Webhooks, orchestration, status, notifications and sync

Stack Rules

Astro + Cloudflare Pages

Use for:

  • simple marketing websites,
  • content-first branch websites,
  • campaign landings,
  • small validation pages,
  • simple forms that send data to n8n.

This is the default for fast, lightweight pages where content and SEO matter more than application logic.

Next.js + Vercel

Use for:

  • beta apps,
  • dashboards,
  • portals,
  • authenticated user interfaces,
  • RS360-style demo panels,
  • app-like product surfaces.

This is the default when the project needs interactivity, routes, login, data views, preview deployments or a product-like UI.

Render

Use only when the project has a clear backend/runtime reason, such as:

  • longer-running services,
  • separate worker-like processes,
  • classic server runtime,
  • backend services that do not fit cleanly into Vercel or Cloudflare.

Render is useful, but should stay optional until the need is concrete.

Hostinger VPS + n8n

Use as the automation layer, not the main frontend host.

n8n should:

  • receive webhooks,
  • trigger deployment flows,
  • notify Rafał or clients,
  • write deployment status and URLs,
  • orchestrate cross-tool workflows,
  • connect forms, emails, CRMs, Notion, Sheets and databases.

Automation Path

Recommended publishing sequence:

Claude Code / coding agent
  -> Git commit
  -> GitHub repository
  -> n8n webhook or schedule
  -> Vercel / Cloudflare / Render API or CLI
  -> deployed URL
  -> status saved to Notion, Sheets, DB or Planner

This keeps AI development, Git history, deployment and status reporting separated enough to control.

Practical Defaults For RSYSTEM

Default For Branch Websites

Use:

  • Astro,
  • Cloudflare Pages,
  • n8n webhook for forms and events.

Applies to:

  • industry websites,
  • lead-generation pages,
  • campaign pages,
  • fast market tests.

Default For Product Interfaces

Use:

  • Next.js,
  • Vercel,
  • optional backend/database depending on project scope.

Applies to:

  • RS360,
  • RS_HUB-like panels,
  • V2S/RS Forge interfaces,
  • client portals,
  • dashboards.

Default For Automations

Use:

  • Hostinger VPS,
  • n8n,
  • webhooks,
  • API/CLI integrations with hosting providers.

Applies to:

  • publishing automation,
  • email/facture workflows,
  • CRM and lead routing,
  • deployment notifications,
  • synchronization between systems.

Decision Checklist

Before starting a new generated website or app, answer:

  • Is this mostly content, SEO and marketing?
  • Does it need login or app-like interaction?
  • Does it need preview deployments for client testing?
  • Does it need a real backend or long-running process?
  • Does form data go directly to automation?
  • Which provider can be controlled by API, CLI or MCP?
  • What status should n8n save after deployment?

Open Questions

  • Should RSYSTEM keep separate templates for Astro and Next.js from the beginning?
  • Should each generated site have a standardized site.config file?
  • Should n8n become the official deployment status registry?
  • Should Cloudflare be the default for all small PL/EN industry landing pages?
  • Should RS360 live on Vercel from the first MVP?

Next Actions

  • Use this standard as input for the website generator module.
  • Compare it with W2. Moduł generowania stron www.md during the next import.
  • Turn the routing table into a future interactive decision helper inside Planner OS.