---
version: alpha
name: "NGINX"
description: "NGINX presents infrastructure through an extremely direct white documentation page, black text, a compact black announcement strip, square content blocks, and the NGINX green wordmark. Keep configuration, downloads, security notices, and documentation closer than marketing."
colors:
  bg: "#ffffff"
  surface: "#f2f2f2"
  text: "#000000"
  brand: "#009639"
  on-brand: "#ffffff"
  border: "#d9d9d9"
  text-soft: "#555555"
  link: "#0066cc"
  dark: "#1f1f1f"
  on-dark: "#ffffff"
typography:
  display:
    fontFamily: "Inter"
    fontSize: "34px"
    lineHeight: 1.5
    letterSpacing: "0"
  body:
    fontFamily: "Inter"
    fontSize: "16px"
    lineHeight: 1.5
  mono:
    fontFamily: "SFMono-Regular"
rounded:
  button: "3px"
  card: "4px"
  pill: "9999px"
spacing:
  xs: "0px"
  sm: "4px"
  md: "12px"
  lg: "32px"
  xl: "64px"
---

## Overview

## Overview

NGINX is spare, high-contrast, and operational. The green wordmark anchors a white page where news, documentation, downloads, security advisories, and project information are separated by simple headings and rules. A black notice strip can carry urgent project context without redesigning the whole page.

The extraction should feel fast because it avoids ornamental work. Preserve the square, utilitarian structure and do not substitute a generic infrastructure dashboard.

**Key Characteristics**
- NGINX green identity on white
- Black high-priority notice band
- Plain sans-serif technical copy
- Square sections with thin rules
- Documentation and security routes near the top
- Minimal radius, shadow, and animation
- Mobile navigation that collapses without overflow

## Colors

Use #009639 for the wordmark, primary action, selected state, and key project link. White is the dominant page and reading surface. Black supports body copy and urgent notice bands; #f2f2f2 groups secondary content. Blue remains available for conventional inline links where green would blur identity and navigation.

## Typography

Arial or Helvetica provides the compact documentation voice. Use 26-34px for page-level headings, 18-22px for section titles, and 16px for body copy. Monospace is required for directives, file paths, ports, headers, and configuration. Keep zero tracking and conventional sentence case.

## Layout

Use a 1040px centered shell and 760px prose measure. Keep the wordmark, major project routes, and current notices visible early. Dense lists may use two columns on desktop and one on mobile. Separate sections with rules and spacing instead of large decorative bands.

Below 900px, stack multi-column project lists. Below 640px, collapse navigation, keep the NGINX mark visible, allow code to scroll inside its own region, and preserve 16px body text. The source audit showed no horizontal overflow; implementations should maintain that behavior.

## Elevation & Depth

Keep the main page flat. Use no card shadows. A temporary menu or modal may use a small shadow and a clear border, but technical content should remain aligned to the page plane.

## Shapes

Use 0px for documentation groups and notices, 2px for controls, 3px for compact menus, and at most 6px for a modal. Pills are reserved for release or severity metadata.

## Components

Primary buttons are rectangular green actions. Secondary actions use a 1px border; tertiary actions are underlined links; dangerous operations use a separate red semantic token and confirmation. Documentation groups remain flat rows or columns, not floating cards. Notices use black or light gray bands with explicit severity text. Inputs are square and labeled. The mobile menu uses a familiar menu icon with an accessible name.

Use immediate link feedback, 80ms button states, and 140ms menus. Focus is a 2px green or black outline with 2px offset depending on surface contrast. Reduced motion removes smooth scrolling and menu transforms.

Black on white provides strong reading contrast. Green actions need sufficient weight and white labels; inline links need underlines. Advisories must include severity and date in text. Configuration examples require accessible labels and copy controls. Preserve semantic lists, headings, skip links, and 44px mobile targets.

Use operational verbs: "Read documentation", "Download NGINX", "View security advisories", and "Open source". State versions, affected branches, file names, and commands. Avoid vague performance claims without a linked technical basis.

The audited homepage is light-only with a black announcement surface. A dark reader mode requires explicit background, text, green, link, code, border, and advisory tokens. Do not extend the black notice band into a one-note dark theme.

NGINX follows Unix daemon documentation, web-server manuals, and long-lived open-source project indexes. Its recognizable system comes from a single green identity color attached to direct technical information, not from decorative infrastructure imagery.

## Do's and Don'ts

**Do**
- Keep NGINX green restrained and consistent.
- Surface security and release context.
- Make configuration copyable.
- Use rules and spacing for hierarchy.
- Keep controls square and labeled.
- Preserve conventional links.
- Stack lists cleanly on mobile.
- Keep notices explicit.

**Don't**
- Do not create a glossy SaaS dashboard.
- Do not put every link inside a card.
- Do not use black for ordinary body surfaces.
- Do not use green as the only status cue.
- Do not animate server diagrams continuously.
- Do not hide version information.
- Do not clip directives.
- Do not use large rounded containers.

**Quick colors:** background #ffffff; text #000000; NGINX green #009639; surface #f2f2f2; border #d9d9d9; notice #1f1f1f; link #0066cc.

**Example prompts**
- Create an NGINX documentation index with a white ground, green identity, and square project lists.
- Design a black security notice band with explicit severity, version, and one text action.
- Build a configuration reference with copyable directives and restrained gray separators.
- Create a responsive download page that stacks cleanly below 900px.

**Iteration guide:** order technical routes first; apply the green identity; set square spacing and rules; add advisory state; verify mobile and code overflow; then remove unnecessary radius and shadow.