Wooven docs

Wooven starts as an open source CLI for instant static publishes and grows into a sovereign deployment control plane: Git-connected previews, BYOS runners, distributed compute, and optional self-hosting.

CLI publish

The current public surface is wooven-publish: a tiny CLI that publishes static files to *.wooven.dev. It works well for AI-generated prototypes because the contract is narrow: folder in, URL out.

curl -fsSL https://wooven.dev/skill/install.sh | bash

wooven-publish ./build
# ✓ live at https://meadow-aspen-x321fc.wooven.dev/

• The folder must include index.html at the root.
• Anonymous publishes expire after 24 hours.
• Current limits: 200 files, 10 MB per file, 25 MB total.
• Allowed assets include HTML, CSS, JS, JSON, SVG, common images, fonts, text, XML, and web manifests.

How it works

The CLI walks the directory, reserves an unguessable slug, uploads files over HTTPS, finalizes the publish, and stores a local claim token under ~/.wooven/state for future updates.

BYOS theory

BYOS means bring your own server. Wooven should sell orchestration, not force you to buy bundled compute. The control plane tracks projects, deployments, domains, logs, and routing; customer-owned runners do the expensive work.

The same job API should work for Wooven-managed capacity and user-owned nodes. The difference is the scheduler pool: managed, BYOS, or a future shared mesh.

Distributed compute

Distributed compute is the R&D track beyond a single VPS. Runners can report CPU architecture, memory, GPU availability, network class, and region hints. The scheduler can then route static serving, server processes, background jobs, previews, and AI workloads to the node that fits best.

• VPS nodes handle persistent web processes.
• Mac minis and GPU nodes handle local AI or heavier builds.
• Raspberry Pis and edge machines can serve cheap static or regional workloads.
• Browser/WebGPU workers are an R&D path for opt-in ephemeral compute.

Self-hosting

The long-term self-hosting target is a control plane that can run on a team's own infrastructure. That matters for teams that want their Git provider, deployment controller, runners, logs, and model endpoints inside their own trust boundary.

Near-term, the practical self-hosting boundary is the runner. Later, Wooven can support self-hosted console installs, Forgejo as a GitHub escape hatch, and private model adapters such as Ollama, vLLM, LM Studio, or llama.cpp.

GitHub OAuth

Set GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET for production. Callback URL: {API_ORIGIN}/v1/auth/github/callback. OAuth scopes include repo so the import picker can list private repositories. Without credentials, the API uses a development connection profile.

Webhooks

Point your GitHub App at /webhooks/github. With NODE_ENV=production, GITHUB_WEBHOOK_SECRET is required and signatures are verified. In non-production, an empty secret still accepts deliveries for local testing.

Custom domains

Add a hostname, publish the TXT challenge shown in the console, then run Verify DNS. Use MOCK_DNS_ALWAYS_VERIFY=1 on the API for local testing without real DNS.

Roadmap in R&D

The product roadmap moves in layers. The CLI proves instant publishing. GitHub and custom domains make the console useful. BYOS makes Wooven distinct. Distributed compute and agentic flows are the research wedge.