website/docs/PAGES.md

netOrk Website — Page Structure & Content Plan

This document defines every page of the website: its purpose, section structure, and draft copy. Use this as the brief for implementation.

---

Page Overview

Route	Page	Priority
/	Landing (Home)	P0 — build first
/features	Full feature list	P1
/drivers	Supported devices	P1
/docs/getting-started	Installation guide	P1
/roadmap	Roadmap — planned + under consideration	P1
/nis2	NIS2 landing page — Art. 21 mapping, evidence, roadmap	P1
/docs/architecture	Technical overview	P2
/plugins	Plugin system	P2

---

/ — Landing Page

Section 1 — Hero

Purpose: Answer "what is this?" in 5 seconds.

Layout: Full-width, centered. Heading + subheading + two CTAs + hero screenshot below.

Heading:

Network orchestration
for heterogeneous infrastructure.

(text-slate-100 for first line, second line in text-sky-400 or keep both text-slate-100 — designer decides.)

Subheading:

netOrk discovers, monitors, and manages your routers, switches, access
points, firewalls, and servers from a single UI — regardless of vendor.
No SaaS dependency. Runs on your infrastructure.

CTAs:

• Primary: Get started → → /docs/getting-started
• Secondary: View features → /features

Hero visual: Full-width screenshot of the device inventory page (dark UI visible, framed with the browser chrome component from DESIGN.md).

---

Section 2 — Problem Statement

Purpose: Make the pain relatable.

Layout: Single centered paragraph or short 3-column stat row.

Copy:

Managing a mixed network means juggling a different admin UI for every
vendor — one for OPNsense, one for HP ProCurve, one for OpenWRT, one for
Proxmox. Config changes happen directly on devices with no audit trail.
You find out something drifted when it breaks.

---

Section 3 — Core Capabilities (3-up)

Purpose: Communicate the three main things netOrk does.

Layout: 3 columns, each with icon + heading + 2–3 sentences.

Card 1 — Discover & Inventory

• Icon: MagnifyingGlassIcon
• Heading: Discover everything on your network
• Copy: ICMP sweep, SNMP scan, and HTTP probing find devices before you add them. Fingerprinting identifies vendor and platform automatically. Adopt results into your inventory with a single click.

Card 2 — Monitor & Alert

• Icon: ChartBarIcon or SignalIcon
• Heading: Poll device state continuously
• Copy: Every device is polled on a configurable interval via NAPALM. Interface status, ARP tables, DHCP leases, VLAN membership, Docker containers, and SNMP health metrics — all in one place.

Card 3 — Configure & Enforce

• Icon: WrenchScrewdriverIcon
• Heading: Detect drift. Fix it.
• Copy: Define desired state in netOrk. On every poll, device config is compared against it. Drifted devices get a warning; a one-click fix stream applies the correction and shows you live SSH output.

---

Section 4 — Driver Grid

Purpose: Show breadth of vendor support.

Layout: Centered heading + wrapping badge grid.

Heading: Works with your hardware

Subheading:

netOrk ships with custom NAPALM drivers for 11 device types, plus all
built-in NAPALM drivers. New drivers follow a documented registration
pattern.

Badge list (see docs/PRODUCT.md — driver table): OpenWRT, OPNsense, Proxmox VE, Linux, HP ProCurve / Aruba, TP-Link Jetstream, Netgear, Fritz!Box, Zyxel, OpenMediaVault, Sonos, Cisco IOS, Arista EOS, Juniper JunOS

Each badge uses the Driver / Integration Badge component from DESIGN.md.

---

Section 5 — Screenshot Walkthrough (alternating)

Purpose: Show the UI concretely. Three alternating image + text rows.

Row 1 — Left text, right screenshot

• Heading: Device detail at a glance
• Copy: Hostname, IP, vendor, OS version, last poll time, and active warnings on one card. Tabbed detail view for interfaces, LLDP neighbors, ARP table, VLAN membership, packages, services, and scheduled jobs.
• Screenshot: DeviceDetailPage

Row 2 — Right text, left screenshot

• Heading: Intent-based VLAN and SSID management
• Copy: Define VLAN names and SSID settings once. netOrk compares them against every polled device and pushes corrections automatically via UCI (OpenWRT) or the device's native API.
• Screenshot: VlansPage or WirelessPage

Row 3 — Left text, right screenshot

• Heading: Security visibility per device
• Copy: Wazuh agent status, CVE counts by severity, and recent alerts — all linked to the device record. One-click agent install if the agent is missing. Graylog syslog forwarding status with auto-fix.
• Screenshot: SecurityTab inside DeviceDetailPage

---

Section 5b — NIS2

Purpose: Hook for organizations evaluating netOrk in a NIS2 context.

Layout: Left column — label + Art. 21 mapping list. Right column — mock compliance overview UI.

Label (eyebrow): NIS2 · Art. 21 (sky-500, uppercase, tracking-widest)

Heading: Evidence, not paperwork.

Copy:

NIS2 Art. 21 mandates asset inventory, patch management, access control,
and audit trails as baseline technical measures. netOrk doesn't bolt on a
compliance layer — these are its day-to-day outputs.

Art. 21 mapping (4 rows, icon = monospace article ref in sky-500):

• Art. 21 (2e) → Patch & vulnerability management — Per-device update status, Wazuh CVE counts by severity
• Art. 21 (2h) → Asset management & access control — Full device inventory, RBAC with four roles, complete audit log
• Art. 21 (2a) → Risk analysis baseline — Config drift detection, SNMP health metrics, security agent coverage
• Art. 21 (2b) → Incident detection — Wazuh alert history, CrowdSec decisions, Graylog syslog per device

Mock UI (right column): MockCompliance — per-site checklist with ✓/⚠ rows, each showing label + detail stat. Label: netork.local / compliance / HQ.

---

Section 6 — Plugin System (brief)

Purpose: Signal extensibility without going deep.

Layout: Dark card, left-aligned.

Heading: Built to extend

Copy:

Integrations (Wazuh, Graylog, CrowdSec, apt-cacher-ng) are plugins
that register into the plugin system — they can be enabled or disabled
per deployment without code changes. Adding a new integration follows
a documented pattern with a hook bus, typed metadata, and a plugin
registry.

CTA: Plugin system docs → → /plugins

---

Section 7 — Deployment (quick)

Purpose: Answer "how do I run this?" without going into detail.

Layout: Code block + short description.

Heading: Self-hosted. One command.

Copy:

netOrk runs in Docker Compose. Five containers: API, two worker pools,
a Beat scheduler, and an nginx UI server. No external dependencies beyond
Redis and PostgreSQL.

Code block:

# Clone + configure
git clone https://gitea.example.com/netork/netork.git
cp .env.example .env
# edit .env (DB URL, Redis password, secret key)

# Deploy
bash scripts/deploy.sh 192.168.1.10

---

Section 8 — CTA Footer

Layout: Centered, full-width dark section.

Heading: Start managing your network.

CTA: Read the docs → → /docs/getting-started

---

/features — Full Feature List

Purpose: Comprehensive reference for people who want to evaluate in depth.

Layout: Vertical list of expandable sections (or just long-scroll with sticky section nav). One section per capability area.

Sections (map directly to feature list in docs/PRODUCT.md):

1. Device Management
2. Discovery
3. Supported Drivers (full table)
4. Networking & Inventory
5. Configuration Management & Drift
6. Scheduled Operations
7. Monitoring & Health
8. Security Integrations
9. DNS Management
10. Access Control (RBAC)
11. NetBox Sync
12. Developer Experience

Each section: text-xl font-semibold text-slate-200 heading + feature items as a clean list with text-slate-400 body.

---

/drivers — Supported Devices

Purpose: One-page reference for "does netOrk support my device?"

Layout: Full table + short description per driver.

Table columns: Driver name | Device type | Capabilities | Status

Capabilities — checkmarks or tags for:

• get_facts get_interfaces get_lldp get_vlans get_ssids get_health_metrics get_docker scheduled_reboot config_push

Status: stable / beta / community as a badge.

---

/docs/getting-started — Installation

Purpose: Get someone from zero to a running instance.

Sections:

1. Prerequisites

   • Docker + Docker Compose
   • A PostgreSQL instance (or use the bundled profile)
   • Redis
   • A Linux host reachable by SSH from the server

2. Quick start

   git clone ...
   cp .env.example .env
   # Edit .env
   bash scripts/deploy.sh <server-ip>
   

3. First run

   • Navigate to http://<server-ip>
   • Complete the setup wizard (creates admin user)
   • Add your first device

4. Adding a device

   • Fill in hostname/IP, driver, and credentials
   • Click Poll to verify connectivity
   • Set a poll interval for continuous monitoring

5. Next steps

   • Configure NetBox sync
   • Set up Wazuh integration
   • Enable scheduled reboots for OpenWRT APs

---

/roadmap — Roadmap

Purpose: Show what's being built and what's under consideration. Signal NIS2 investment clearly.

Layout: Page header + two vertical groups ("Planned" / "Under consideration"), each a list of items.

NIS2 badge: NIS2 monospace tag (sky-500/10 bg, sky-400 text, sky-500/20 border) inline next to item title.

Intro copy:

What's being built and what's being evaluated. Items tagged NIS2 directly 
address NIS2 Art. 21 technical baseline requirements.

Planned items (NIS2-tagged):

• CVE tracking per device — NVD / OSV cross-reference
• Configuration backup & versioning — git-backed snapshots, change detection
• Compliance dashboard — per-site Art. 21 checklist view
• Audit log export — PDF / CSV with filters

Planned items (general):

• Webhook engine — outbound events with HMAC signing
• Live job log streaming — WebSocket for all long-running tasks
• NetBox sync — manual trigger + status view

Under consideration (NIS2-tagged):

• Incident workflow — structured record + NIS2 Art. 23 Fristen-Tracker
• EOL tracking — endoflife.date integration for firmware / OS
• MFA (TOTP) — second factor for netOrk logins

Under consideration (general):

• mDNS scanner — media device discovery
• Prometheus + Grafana — metrics and dashboards
• Kubernetes Helm chart

---

/docs/architecture — Technical Overview

Purpose: Give engineers the mental model before they look at code.

Content: Essentially the one-paragraph summary from docs/PRODUCT.md expanded into a readable overview with the architecture diagram (ASCII or SVG).

Sections:

1. Overview (request → FastAPI → DB / Celery worker)
2. Driver system (NAPALM + custom drivers + registry)
3. Task queues (which queue does what)
4. Plugin system (register → hook bus → router mount)
5. Data model (UUID PKs, JSONB snapshots, intent-vs-state)

---

/plugins — Plugin System

Purpose: Explain extensibility to potential contributors.

Sections:

1. What is a plugin? (metadata, router, tasks, hooks)
2. Built-in plugins (Wazuh, Graylog, CrowdSec, apt-cacher)
3. Writing a plugin (step-by-step with code snippets)
4. Hook bus (fire / call / transform)
5. Plugin registry and enable/disable

---

Global Layout

Navigation (all pages)

[ netOrk ]    Features    Drivers    Docs ▾    Plugins        [ Get started ]

Docs is a dropdown: Getting Started / Architecture

Footer

netOrk — self-hosted network orchestration

Links:          Resources:        Legal:
Features        Getting Started   MIT License
Drivers         Architecture      Privacy (none collected)
Plugins         Changelog

Footer background: bg-slate-900 border-t border-slate-800 Footer text: text-sm text-slate-500