chore(site): fix 404s

Author: NathanFlurry

.gitignore

@@ -46,6 +46,7 @@ frontend/node_modules/
 frontend/.tanstack
 
 # Site
+site/out/
 site/.next/
 site/src/generated/
 site/public/docs/

site/lychee.toml

@@ -4,6 +4,7 @@ exclude = [
     '^https://hub\.rivet\.gg/.*',
     '^https://.*\.rivet\.game/',
     '^https://ph\.rivet\.gg/',
+    '^https://studio\.rivet\.dev/',
 
     # Strict rate limits
     '^https://www\.cloudflare\.com/learning/',
@@ -15,7 +16,7 @@ exclude = [
     '@body\.json',
 
     # Bug parsing `src={xxxx}`
-    '%7B.*%7D$'
+    '%7B.*%7D$',
 ]
 # exclude_all_private = true
 exclude_mail = true

site/public/llms-full.txt

@@ -0,0 +1,18 @@
+#!/bin/bash
+set -euo pipefail
+
+PORT=${PORT:-3000}
+
+# Build the site
+echo "Building static site..."
+pnpm build
+
+# Check if build succeeded
+if [ ! -d "out" ]; then
+    echo "Error: Build failed. The 'out' directory was not created."
+    exit 1
+fi
+
+# Serve the site
+echo "Starting server on port $PORT..."
+cd out && python3 -m http.server $PORT

site/public/llms.txt

@@ -0,0 +1,30 @@
+#!/bin/bash
+set -euo pipefail
+
+URL=${1:-http://localhost:3000}
+
+# Check if lychee is installed
+if ! command -v lychee &> /dev/null; then
+    echo "Error: lychee is not installed."
+    echo "Install with: brew install lychee"
+    exit 1
+fi
+
+# Wait for server to be ready
+echo "Checking if server is running at $URL..."
+for i in {1..10}; do
+    if curl -s -o /dev/null "$URL"; then
+        echo "Server is ready."
+        break
+    fi
+    if [ $i -eq 10 ]; then
+        echo "Error: Server is not responding at $URL"
+        echo "Run: ./scripts/build-serve.sh"
+        exit 1
+    fi
+    sleep 2
+done
+
+# Run lychee
+echo "Running link checker..."
+lychee --config lychee.toml "$URL"

site/scripts/build-serve.sh

@@ -164,7 +164,7 @@ Purely theorizing: a standard for stateful serverless might provide the foundati
 
 I'm the founder of Rivet and have a vested interest in seeing stateful serverless become a standard. Rivet provides an open-source stateful serverless platform that can be easily self-hosted.
 
-We also provide a handful of features in our runtime that don't make sense to be part of a standard, since the best W3C standards build on existing web standards: [Docker containers for non-JavaScript applications](https://rivet.dev/docs/cloud/containers), [HTTP, UDP, and TCP support](https://rivet.dev/docs/cloud/networking), [advanced lifecycle management](https://rivet.dev/docs/cloud/durability), [actor tagging](https://rivet.dev/docs/cloud/api/actors/create) for advanced multi-tenant applications, [advanced control over actor upgrades](https://rivet.dev/docs/cloud/api/actors/upgrade-all) for companies with specific use cases, [fine-grained control over where your actor is running](https://rivet.dev/docs/cloud/api/regions/list), and a developer-friendly REST API for managing Rivet Actors.
+We also provide a handful of features in our runtime that don't make sense to be part of a standard, since the best W3C standards build on existing web standards: [Docker containers for non-JavaScript applications](https://rivet.dev/docs/cloud/containers), [HTTP, UDP, and TCP support](https://rivet.dev/docs/cloud/networking), [advanced lifecycle management](https://rivet.dev/docs/cloud-ee/durability), [actor tagging](https://rivet.dev/docs/cloud/api/actors/create) for advanced multi-tenant applications, [advanced control over actor upgrades](https://rivet.dev/docs/cloud/api/actors/upgrade-all) for companies with specific use cases, [fine-grained control over where your actor is running](https://rivet.dev/docs/cloud/api/regions/list), and a developer-friendly REST API for managing Rivet Actors.
 
 We encourage developers building on Rivet to use [RivetKit](https://github.com/rivet-dev/rivetkit). However, we also provide a [low-level API](https://rivet.dev/docs/cloud/actors) for defining actors: