Wooven docs

Connect a Git repository, push code, get a live URL. Wooven handles the build, the routing, the TLS, and the rollback path — on our managed runners or on hardware you own.

If you have used Vercel, Netlify, or Render, the dashboard will feel familiar. Two things to know up front:

  • Sovereign by default. Your code and runtime can run on infrastructure you own. Use our managed runners when you want zero ops; switch to your own server when you are ready. If you cancel, your BYOS deployments keep running.
  • No compute meter. Builds, traffic, and runtime are bounded by per-tier wall-clock and bandwidth limits, not a per-minute clock. Billing meters only the things that scale with you: extra custom domains and extra seats.

Deploy from GitHub

From the dashboard, click New project:

  1. Connect GitHub. Authorize the Wooven GitHub App on the repos you want to deploy. We only see the repos you select and we never push or modify code.
  2. Pick a repo. Wooven scans the root, identifies the framework, and proposes install + build + start commands. You can override any of them in project settings.
  3. Deploy. The default branch becomes production; every other branch and every pull request gets its own preview URL automatically.

That is it. The dashboard streams live build logs while the app is shipping. Most apps go from first connect to live previewin under a minute.

Supported stacks

Stack auto-detection works for these out of the box:

  • JavaScript / TypeScript: Next.js, React, Svelte, Astro, Vite, Bun, Deno, Fastify, Express.
  • Python: FastAPI, Flask, Django.
  • Other: Laravel (PHP), Rust (axum, actix), and any static output (HTML / CSS / JS).

Detection reads framework manifests like package.json, pyproject.toml, or Cargo.toml. If your stack is not on the list, override the install, build, and start commands in project settings and it ships the same way. The framework catalog is expanding — see the live list on the home page.

Preview deploys

Every pull request and every non-production branch gets its own preview URL of the form {slug}-{sha7}-{deploymentId}.preview.wooven.dev. The URL is stable for the lifetime of that build — opening it two weeks later still works as long as the deployment has not been cleaned up.

PR previews update on every push. Closing or merging the PR schedules cleanup a few hours later. Each branch with a READY deployment also gets a stable alias: {branch}--{slug}.preview.wooven.dev (latest READY on that branch). The project Domains tab lists these under Preview URLs.

Custom domains are separate: they only update when your routing mode points at that branch (usually Production → default branch).

Environment variables

Add env vars from Project → Settings → Environment Variables. Each value is scoped to one of three environments: Production, Preview, or Development. Build-time values (for example NEXT_PUBLIC_*) are baked into the artifact; runtime values are injected into the running process.

Values are encrypted at rest and never printed in build or runtime logs. After editing, click Redeploy on the deployment you want to apply the change to.

Logs and rollback

Each deployment has its own log stream split into build, start, and runtime. Search by deployment id, by date, or by error level. Production logs are retained 30 days; preview logs 7 days.

To roll back: open Deployments, find a previous green build, and click Promote to production. The swap is instant — same Git SHA, same artifact, no rebuild. The rolled-back deployment stays in your history so you can reverse the rollback the same way if needed.

Custom domains

Add a custom domain from Project → Domains (or the workspace Domains view). Wooven shows your account quota (included, used, remaining) at the top of the page. Removing a domain frees a slot immediately for another hostname on any project.

Wooven gives you a CNAME target like proj-1-k8f3nx2p9q4m.dns.wooven.dev (project id + random slug). At your DNS provider, create a CNAME record pointing your domain (for example app.example.com) to that target.

Within a few minutes — usually under five — we issue a TLS certificate, attach it to the edge, and your domain goes live. Renewal is automatic; there is nothing to manage. Wooven proxies traffic through Cloudflare for DDoS protection and global TLS termination before forwarding to your runner.

For an apex domain (for example example.com rather than www.example.com), use an ALIAS or ANAME record if your DNS provider supports it. Otherwise point www and redirect apex traffic from your DNS provider.

Each tier includes a quota of custom domains (Hobby 1, Growth 4, Business 8); additional domains beyond the included count are 1 CHF per month each when metered billing is enabled. See plans & billing.

Domain routing

Each custom hostname has a routing mode (editable via Edit routing on the Domains table):

  • Production(default) — serves the latest READY deployment on the project's default branch (usually main). Adding labor5020.ch with no override uses this mode.
  • Branch — latest READY on a specific branch (for example staging.example.com → develop).
  • Deployment — frozen pin to one deployment id (rollback / debug); newer builds do not change what the hostname serves.

Only deployments with status ready are served on custom domains. Failed or in-progress builds are skipped. Branches without a custom mapping stay on Wooven preview URLs only. Operators: see fullstack_application/infraConfiguration.md (application routing subsection) in the repo.

BYOS overview

BYOS means bring your own server. Instead of running your build and runtime on Wooven's hardware, you attach a machine you own — a VPS, bare metal, a Mac mini under your desk — and Wooven's control plane treats it as a deploy target.

The control plane still owns the user-facing work: it tracks deployments, owns routing, issues TLS, and surfaces logs. The expensive parts (CPU, memory, network) live on your hardware. The payoff:

  • No compute lock-in. If you cancel Wooven, your app keeps running on your machine. Git, Docker, your runtime — all still yours.
  • Sovereign data. Your runtime data never leaves your network. Useful for GDPR, FINMA, or any policy that prohibits processing on third-party hardware.
  • Mix freely. A project can use managed runners for previews and BYOS for production — or the reverse.

Attach a runner

The runner is the Wooven agent that runs on your hardware. To attach one:

  1. From Settings → Runners, click New runner. We generate a one-time enrollment token.
  2. SSH to the machine you want to attach and run the installer with that token:
    terminal
    curl -fsSL https://wooven.dev/runner/install.sh | bash -s <token>
  3. The runner registers, reports its health, and appears in your dashboard a few seconds later.

From there, let Wooven schedule deployments to it automatically (matched by labels you set on your projects) or pin specific projects to specific runners. One runner can host many projects; a project can spread across many runners.

The runner handles its own updates and reconnects automatically on network blips. If a runner stops reporting for more than 90 seconds, Wooven re-queues any in-flight build on another available runner so deploys do not get stuck.

wooven CLI

The CLI uses the same API as the dashboard. Install:

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

Authenticate once:

terminal
wooven login

Common commands:

terminal
wooven deploy                       # deploy current directory
wooven projects                     # list your projects
wooven logs <project>               # stream logs
wooven rollback <project> --to <id> # promote a previous deployment
wooven env <project>                # manage environment variables
wooven domains <project>            # manage custom domains
wooven doctor                       # diagnose runner / network issues

Use the CLI from CI pipelines, scripts, or as a daily driver if you prefer the terminal. Personal access tokens are issued from Settings → Tokens.

MCP for agents

Wooven exposes a Model Context Protocol (MCP) server so AI assistants like Claude or Cursor can drive your deployments directly. Configure your assistant to point at Wooven's MCP endpoint with a personal access token.

  • Trial and Hobby: read-only MCP — inspect projects, deployments, logs.
  • Growth and Business: full MCP — deploy, manage envs, roll back, control runners.

Setup guides for Claude Desktop, Cursor, and Windsurf ship with the MCP launch. The CLI auth flow is reused for MCP tokens, so the same wv_pat_ token works in both places.

wooven-publish

For static files only — no build step, no project record — there is wooven-publish: a free, open-source one-shot publisher. It puts a folder of HTML / CSS / JS at a public URL in seconds. Perfect for sharing AI-generated prototypes, design demos, or one-off landing pages.

terminal
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; sign in to claim a slug permanently.
  • Current limits: 200 files, 10 MB per file, 25 MB total.

Support

Hobby and Growth plans use community support and email at [email protected]. Business plans get priority email plus a private Slack channel with a 48-hour response SLA. A public status page will publish alongside billing GA. For pricing, see plans & billing.