Weftra

Appearance

What Weftra is, and is not ​

This page says what Weftra does today and what it does not. Each claim about behavior names the file that makes it true, so you can check it rather than take our word for it.

What Weftra is today ​

Weftra is self-hosted and single-tenant per instance: you run one instance on infrastructure you control, and it serves one operator's scope. It is Claude-first. Claude Code is the validated engine, and other engines are reached through declared engine profiles (see ENGINES.md).

A feature moves through one pipeline: a spec is submitted, the agent asks clarifying questions when the request is ambiguous, an approver signs off according to the project's autonomy mode, the implementation runs in a sandbox, Weftra runs the project's declared tests itself, reviewers check the change, a draft pull request is opened, and every step is written to a hash-chained run ledger. The lifecycle is described in USER_GUIDE.md.

Where the agent runs, and who can make it run ​

  • Agent runs execute in a Docker sandbox by default. The default is set in src/config.ts and the container is built by src/services/runtime/docker-runtime.ts.
  • RUNTIME=local is a development-only opt-out. It has no containment: the agent runs on the host. Weftra refuses to start in that mode unless you acknowledge it explicitly (src/services/runtime/local-runtime-startup-guard.ts), and the trust page records it as a non-claim (docs/current/trust.md, section 9).
  • A project API key is a tenant credential. It can submit work. It cannot approve work, and it cannot make anything run on the host. The guards that enforce this are in src/middleware/auth.ts, and the authorization surface is listed route by route in docs/security/authz-surface.json.
  • A feature's own submitter cannot approve it. The rule and its project-level policy live in src/services/separation-policy.ts.
  • The approval gate is part of the core, not a paid tier. Every submission passes through the project's autonomy mode (full_auto, auto_safe or po_approval), described in docs/USER_GUIDE.md.

Running it on your own ​

You do not need a team to get value from Weftra. When one developer approves their own work, the value is the evidence, not the ceremony: sandboxed runs, tests Weftra ran itself, review passes, and a tamper-evident ledger. The setup is described in the quickstart section Running it on your own: evidence, not ceremony.

How sure we are ​

We grade each control on a five-level maturity scale:

  1. L1, designed. A spec, a doc or a comment describes it. Nothing enforces it.
  2. L2, implemented. The code exists.
  3. L3, tested. A test exercises the code and fails if it breaks.
  4. L4, enforced in the default path. A default install runs it without anyone opting in.
  5. L5, shown to hold under attack. Someone made a deliberate attempt to defeat it and it held.

No control is claimed at L5. The adversarial review coverage that does exist, and what that coverage does and does not mean, is on the trust page under "Adversarial review coverage". We point there instead of copying a number here, because a copy would drift.

What Weftra is not (yet) ​

These are not shipped. We do not give dates for them.

  • No BYOC packaging beyond running Docker yourself.
  • No hosted SaaS.
  • No Postgres-backed storage. The database is SQLite.
  • No multi-tenant hosting. One instance serves one operator.
  • No certifications: no SOC 2, no ISO 27001, no ISO 42001.
  • No recorded containment tier. A formal multi-tier containment taxonomy is design-only, and no run record carries a tier (see the "Containment Tiers" section of docs/operations/security-model.md).

Where to go next ​

Released under the MIT License.