Skip to content

DEPLOY.adoc

Latest commit

 

History

History
144 lines (106 loc) · 3.64 KB

DEPLOY.adoc

File metadata and controls

144 lines (106 loc) · 3.64 KB
Raw

Project Wharf — Deployment Guide

Table of Contents

Prerequisites

  • A Linux server (Debian 12+, Ubuntu 22.04+, Fedora 38+, or any distro with podman)

  • podman or docker installed

  • At least 2 GB RAM, 10 GB disk

  • Ports 8080, 8443, 9001 available

Quick Start (5 minutes)

# Clone the repo
git clone https://github.com/hyperpolymath/project-wharf.git
cd project-wharf/deploy

# Run the setup script
sudo ./setup.sh --domain example.com

# Start the stack
sudo podman compose -f ../infra/selur-compose.yaml up -d

# Verify
curl http://localhost:9001/health
# → {"status":"ok","moored":false,...}

What Gets Deployed

Service Purpose Port

yacht-agent

Security enforcer (DB proxy, integrity, mooring API)

3306, 9001

yacht-nginx

Reverse proxy (TLS termination, static files)

8080, 8443

mariadb

Database (shadowed behind yacht-agent proxy)

33060 (internal)

Architecture

Internet → nginx:8080/8443 → PHP-FPM → yacht-agent:3306 → MariaDB:33060
                                              ↑
                                     AST-aware SQL filter
                                     (blocks injection)

WordPress connects to the database on port 3306, which is the yacht-agent’s proxy. The agent parses every SQL statement’s AST and enforces table-level write policies.

Managing Your Site

From Your Local Machine (The Wharf)

# Install the wharf CLI
cargo install --path bin/wharf-cli

# Initialize your fleet
wharf init --adapter wordpress

# Push changes to the yacht
wharf moor example.com

# Verify remote integrity
wharf integrity verify --remote example.com

On the Server (The Yacht)

# Check agent status
curl http://localhost:9001/stats

# View metrics (Prometheus format)
curl http://localhost:9001/metrics

# Check health
curl http://localhost:9001/health

Local Development (Podman Compose)

For a quick local proof-of-concept with WordPress behind the SQL proxy:

cd deploy

# Automated: downloads WordPress, generates wp-config.php, builds + starts stack
bash local-test.sh

# Visit WordPress setup wizard
# http://localhost:8080

# Prove SQL injection is blocked (6 tests)
bash verify-sqli.sh

# Check agent stats
curl http://localhost:9001/stats

# Tear down
podman compose down
rm -rf wharf-local/    # removes all data

Local Stack Architecture

Browser :8080 → OLS (web) → PHP/WordPress → agent:3306 → db:3306 (MariaDB)
                                                ↑
                                       AST SQL parser (sqlparser 0.39)
                                       Blocks writes to wp_users, wp_options, wp_posts
                                       Blocks DROP/ALTER/TRUNCATE always

Services

Service Purpose Port

db

MariaDB 10.11 (hidden, no host exposure)

3306 (internal)

agent

yacht-agent SQL proxy + API

3306 (proxy), 9001 (API)

web

OpenLiteSpeed 1.8.5 + PHP 8.3

80→8080 (host)

Security Notes

  • The default signature scheme is ml-dsa-87-only (FIPS 204, post-quantum safe)

  • To enable hybrid Ed448+ML-DSA-87 signatures (not yet audited): set signature_scheme = "hybrid" in yacht-agent.toml

  • WordPress is configured with DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS

  • All code changes go through the mooring protocol (cryptographically signed)

  • The database proxy blocks writes to wp_users, wp_options, wp_posts tables

  • DROP TABLE and ALTER TABLE are always blocked regardless of table