Related Pages

Related topics: Coding Agent Executors, Workspaces & Session Lifecycle, Frontend Web Apps, UI Library & Kanban Workspace UI, Server, Cloud/Remote API, Relay/Tunnel & Security

Project Overview, Sunset Status & Monorepo Architecture

1. Project Overview

Vibe Kanban is a visual project management tool for developers that integrates git repositories with AI coding agents. The product is positioned around the idea that "software engineers spend most of their time planning and reviewing coding agents" and aims to accelerate both planning and review loops. Source: README.md

The core workflow consists of four stages:

1. Plan with kanban issues — create, prioritise, and assign issues on a kanban board.
2. Run coding agents in workspaces — each workspace gives an agent a branch, a terminal, and a dev server.
3. Review diffs and leave inline comments — feedback is delivered to the agent without leaving the UI.
4. Preview, then open a pull request — a built-in browser with devtools and device emulation supports review; PRs can be opened, reviewed on GitHub, and merged.

The application is launched from any terminal via a single command:

npx vibe-kanban

Source: README.md

The repository advertises support for more than ten coding agents, including Claude Code, Codex, Gemini CLI, GitHub Copilot, Amp, Cursor, OpenCode, Droid, CCR, and Qwen Code. Source: README.md

2. Sunset Status

A prominent banner at the top of the README.md announces:

Vibe Kanban is sunsetting. Read the announcement at <https://www.vibekanban.com/blog/shutdown>.

The pre-release notes for v0.1.42-20260410131124 confirm this:

bloop, the company behind Vibe Kanban is shutting down. Read more: <https://vibekanban.com/blog/shutdown>.

Source: Release v0.1.42

Subsequent tagged pre-releases (v0.1.43, v0.1.44) and issue #3408 titled *"is this project dead?"* indicate that, as of the latest release, community-maintained updates are still being merged (CLI pin bumps, executor version bumps, perf improvements), but the commercial entity behind the project has ceased operations. Issues #3433 and #3396 further note that server-dependent features (Cloud, Remote, Projects-with-cloud) and the marketing website content are stale or at risk of bit-rot.

2.1 Security Posture After Sunset

Two disclosed vulnerabilities on the hosted Cloud/Remote API underline the importance of self-hosting now that the vendor is gone:

Self-hosting the Docker image (see the self-hosting guide) is the recommended path for users who need these endpoints. Source: README.md

3. Monorepo Architecture

The repository is a pnpm workspace monorepo (also containing Rust crates for the desktop/server backends). The root manifest declares:

"packageManager": "[email protected]",
"engines": { "node": ">=20", "pnpm": ">=8" }

Source: package.json

The npx vibe-kanban launcher is published from the npx-cli workspace, which advertises the following stack on its README: *"Backend: Rust with Axum web framework, Frontend: React with TypeScript, Database: SQLite for local data storage, Git Integration: Native git operations, Process Management: Tokio-based async execution monitoring."* Source: npx-cli/README.md

3.1 Workspace Layout

graph TD
  Root["vibe-kanban (pnpm monorepo)<br/>Root package.json<br/>[email protected], node>=20"]
  Npx["npx-cli/<br/>Publishes 'vibe-kanban' to npm"]
  Wc["packages/web-core<br/>Shared React + TS lib<br/>(@vibe/web-core)"]
  Ui["packages/ui<br/>Component library"]
  Rw["packages/remote-web<br/>Remote/Cloud dashboard"]
  Cargo["crates/* (Rust)<br/>server, remote, tauri-app"]
  Tauri["crates/tauri-app<br/>cargo tauri build"]

  Root --> Npx
  Root --> Wc
  Root --> Ui
  Root --> Rw
  Root --> Cargo
  Cargo --> Tauri
  Ui --> Wc
  Rw --> Wc
  Npx -. ships .-> Tauri

Key packages observed in source:

3.2 Frontend Technology Highlights

• Editor: Lexical v0.36.2 (code, link, list, markdown, react, rich-text, table packages). Source: packages/web-core/package.json
• State & data: TanStack React Query, Electric DB collection, Zustand v4. Source: packages/web-core/package.json
• Diffing: @pierre/diffs 1.1.4 and @git-diff-view/* for the in-app diff viewer (notably the perf release for 300+ file PRs in v0.1.39). Source: packages/web-core/package.json
• Local DB: wa-sqlite 1.0.0. Source: packages/web-core/package.json
• Networking: react-use-websocket, with WebRTC direct tunneling + relay fallback introduced in v0.1.37.
• Syntax highlighting: shared Prism-style token classes via packages/ui/src/lib/code-highlight-theme.ts, and an extension-to-language map at packages/web-core/src/shared/lib/extToLanguage.ts.

3.3 Backend / Desktop

The Rust toolchain ships a server (crates/server), a remote/Cloud backend (crates/remote), and a Tauri-wrapped desktop app (crates/tauri-app). The root package.json exposes the Tauri build entry point as "desktop:build": "cd crates/tauri-app && cargo tauri build". Source: package.json. Process supervision is Tokio-based, with native git operations driving worktree creation, rebasing, and merging. Source: npx-cli/README.md

4. Community Topics That Affect Users Today

Several high-engagement threads describe friction with the current state of the project:

• #2687 "Bring back old UI" — older releases (≤ 0.1.7) had a more kanban-centric UI and persisted tasks/projects differently; upgrading past 0.1.9 reportedly caused data loss for some users.
• #3396 "Support for self-hosted projects and better export" — Projects and Remote features depend on server infrastructure that is now in maintenance limbo after Bloop's shutdown.
• #765 "Configurable automatic cleanup of worktrees" — long-running installs accumulate git worktrees; no in-Settings retention policy exists yet.
• #1697 "Add self-hosted GitLab support" — git operations are GitHub-oriented out of the box.
• #1946 "Ralph Wiggum mode" — repeated, self-correcting agent loops are not yet first-class.
• #2463 "Support Kimi CLI" — community contribution PR #2845 is the most likely path to land ACP-based agents such as Kimi Code.

See Also

• README.md — official entry point and sunset notice.
• Sunset announcement blog post — referenced from the README banner and pre-release v0.1.42 notes.
• Self-hosting Docker guide — recommended path forward given the security disclosures in issues #3429 and #3430.
• Release v0.1.44 — latest tagged release at time of writing.

Related Pages

Related topics: Project Overview, Sunset Status & Monorepo Architecture, Frontend Web Apps, UI Library & Kanban Workspace UI

Coding Agent Executors, Workspaces & Session Lifecycle

1. Overview and Purpose

Vibe Kanban is a developer-focused project management tool that pairs a kanban planning surface with an "agent execution" surface. Its purpose is to compress the two most expensive phases of modern software work — planning and reviewing AI-generated code — into a single UI. Within that product, the Coding Agent Executor, Workspace, and Session Lifecycle subsystems are the runtime that turns a kanban card into a running agent, a live diff, and (optionally) a merged pull request.

The README frames this contract directly: a workspace gives an agent a branch, a terminal, and a dev server, while the UI lets the user review diffs, leave inline comments, and ship a PR (README.md). The npx CLI reinforces the same model: each task attempt is run in an isolated git worktree, with execution monitoring, follow-up runs, rebase, and merge all part of the lifecycle (npx-cli/README.md).

A single API façade in web-core exposes the union of all workspace, session, executor, approval, and PR operations to both the local and remote front-ends (packages/web-core/src/shared/lib/api.ts).

2. Coding Agent Executors (Adapter Layer)

The ExecutorConfig and BaseCodingAgent types in the shared API surface describe the adapter contract that every supported CLI must satisfy (packages/web-core/src/shared/lib/api.ts). The README enumerates the supported adapters:

The CLI documentation describes three agent roles: Claude (advanced), Amp (powerful), and Echo (simple testing/debugging), with RunAgentSetupRequest and RunAgentSetupResponse used to bootstrap agent credentials and GhCliSetupError / RunScriptError types for setup failure reporting (npx-cli/README.md, packages/web-core/src/shared/lib/api.ts).

Release v0.1.44 (2026-04-24) notes that the Claude Code CLI pin and the Codex executor surface are bumped per-release to track upstream changes (Release v0.1.44). Community discussion #3417 also tracks an upstream Anthropic change effective June 15, 2026, where claude -p and the Agent SDK draw from a separate credit pool, which affects how the Claude adapter should be budgeted.

3. Workspace and Session Lifecycle

A Workspace is the persistent unit that ties a project, a target branch, and a sequence of execution attempts together. A Session is the live state of one or more agent runs inside that workspace. The WorkspaceWithSession and createWorkspaceWithSession helpers are imported directly from @/shared/types/attempt, indicating the workspace/session pair is a first-class DTO in the front-end (packages/web-core/src/shared/lib/api.ts).

stateDiagram-v2
    [*] --> Draft
    Draft --> Running: createAndStartWorkspace
    Running --> Reviewing: agent finished
    Reviewing --> Running: follow-up attempt
    Reviewing --> Rebasing: rebaseWorkspace
    Rebasing --> Reviewing: rebase complete
    Reviewing --> Pushing: pushWorkspace
    Pushing --> PrOpen: createPr
    PrOpen --> Merging: mergeWorkspace
    Merging --> [*]
    Running --> [*]: abort / stop

The request/response types confirm the verbs the API supports around this lifecycle: CreateAndStartWorkspaceRequest, CreateAndStartWorkspaceResponse, CreateFollowUpAttempt, DraftFollowUpData, MergeWorkspaceRequest, PushWorkspaceRequest, RebaseWorkspaceRequest, ContinueRebaseRequest, AbortConflictsRequest, RenameBranchRequest, ChangeTargetBranchRequest, and StartReviewRequest (packages/web-core/src/shared/lib/api.ts).

For review gating, the API exposes ApprovalStatus and ApprovalResponse so the UI can pause execution until a human approves a tool call, and StartReviewRequest / ReviewError for the review session itself. PR hand-off is modeled with CreatePrApiRequest, PrError, PrCommentsResponse, MergeWorkspaceRequest, plus LinkPrToIssueRequest and AttachExistingPrRequest for linking to existing GitHub PRs (packages/web-core/src/shared/lib/api.ts).

The remote front-end route tree shows how workspaces are addressable per host: HostsHostIdWorkspaces, HostsHostIdWorkspacesWorkspaceId, and the nested ProjectsProjectIdIssuesIssueIdHostsHostIdWorkspacesWorkspaceId route, which means each workspace is host-scoped so that a user can pair the same browser with multiple execution machines (packages/remote-web/src/routeTree.gen.ts).

4. Process, Logs, and Storage

Each attempt is materialised as an ExecutionProcess with an associated ExecutionProcessRepoState. The splitMessageToTitleDescription helper in the shared string utilities shows how a free-form user message is split into a kanban-card title (≤ 100 chars, word-boundary aware) and an overflow description, which is the input that ultimately creates a workspace and its first session (packages/web-core/src/shared/lib/string.ts).

Release v0.1.41 reverted execution processes from a global Zustand store back to a React Context, to fix a conversation-history leakage bug between sessions (PR #3314). v0.1.41 also "aligns workspace session invalidation with host-scoped query keys" so cache invalidation respects the same per-host scoping that the route tree already encodes (Pre-release v0.1.41). v0.1.44 adds "pre-register execution log stores before streaming normalized logs", which guarantees a log store exists for a process before any output is streamed, avoiding late-binding race conditions (Release v0.1.44).

For environments where the local dev box is not directly reachable, v0.1.37 introduced WebRTC direct tunneling with relay fallback so a workspace session on a remote host can still stream logs back to the browser (PR #3139, Pre-release v0.1.37). The remote API surface for this is PairRelayHostRequest, PairRelayHostResponse, RelayPairedHost, ListRelayPairedHostsResponse, and the symmetric RelayPairedClient types (packages/web-core/src/shared/lib/api.ts).

5. Failure Modes and Community Concerns

• Cross-session leakage — the v0.1.41 Zustand→Context revert is a direct response to conversation history leaking across sessions (PR #3314).
• Bursty diffs — v0.1.39 swapped TanStack Virtual for the Pierre virtualizer and "self-corrected" the live diff stream to handle 300+ file PRs (Pre-release v0.1.39).
• Worktree sprawl — issue #765 requests a configurable retention policy for worktrees in Done or Cancel state; the executor layer has no built-in cleanup hook today.
• External host integration gaps — issue #1697 requests self-hosted GitLab support, which is bounded by the same git/PR verbs (createPr, pushWorkspace, mergeWorkspace) modeled in the API.
• Agent roster expansion — issue #2463 (with PR #2845) proposes adding Kimi Code via the Agent Communication Protocol, which would require a new BaseCodingAgent implementation but no changes to the workspace/session lifecycle.

See Also

• Remote Web Routes & Host Pairing (route tree, relay pairing)
• PR & GitHub Integration (PR create / merge / link types)
• Self-Hosting Guide (Docker deployment for the same backend)

Related Pages

Related topics: Project Overview, Sunset Status & Monorepo Architecture, Coding Agent Executors, Workspaces & Session Lifecycle, Server, Cloud/Remote API, Relay/Tunnel & Security

Frontend Web Apps, UI Library & Kanban Workspace UI

Overview

Vibe Kanban's frontend is delivered as a monorepo of TypeScript/React packages that share a common design system and a core web module. The npx vibe-kanban entry point launches a local web app for self-hosted use, while a parallel remote-web app drives the cloud/hosted experience. Both apps consume the same shared UI primitives and core pages, so the kanban, workspace, and diff-review surfaces behave consistently across local and hosted deployments. Source: README.md:1-80

The repository also contains a Tauri-based desktop shell (crates/tauri-app) that wraps the local web build, but the primary UI surface is React. The monorepo is pnpm-managed and requires Node ≥ 20. Source: package.json:1-30

Package Structure

The frontend is split into four cooperating packages. Each has a tightly scoped exports map that prevents cross-package leakage of internal modules.

Source: packages/ui/package.json:1-20, packages/web-core/package.json:1-15, packages/local-web/package.json:1-20

UI Library (`@vibe/ui`)

The @vibe/ui package is the canonical design system. It exposes components via wildcard exports (./components/* and ./lib/*) so consumers import from @vibe/ui/components/KanbanBoard rather than deep internal paths. Source: packages/ui/package.json:1-20

Notable building blocks include:

• Radix UI primitives for accessible behaviors (dialog, popover, dropdown, tooltip, switch, toggle-group, accordion, select). Source: packages/ui/package.json:1-50
• Lexical editor for rich-text task descriptions and inline diff comments (code, link, list, markdown, table, rich-text modules). Source: packages/ui/package.json:1-50
• @pierre/diffs 1.1.4 and **@git-diff-view/*** for the side-by-side and inline diff renderers used in workspace review. Source: packages/ui/package.json:1-50
• @hello-pangea/dnd plus @dnd-kit/* for kanban drag-and-drop and reordering. Source: packages/ui/package.json:1-50
• @phosphor-icons/react and lucide-react for iconography. Source: packages/ui/package.json:1-50
• Shared code-highlight theme mapping Prism token types to CSS variables (e.g. keyword → --syntax-keyword, comment → --syntax-comment italic) so Lexical code blocks and inline code nodes stay visually consistent across the app. Source: packages/ui/src/lib/code-highlight-theme.ts:1-30

The ui package declares "sideEffects": false, enabling tree-shaking for production bundles. Source: packages/ui/package.json:1-20

Web Core Package (`@vibe/web-core`)

@vibe/web-core is the shared application layer. It owns:

• The API client surface — a single api.ts module re-exports every DTO and response type the frontend needs (projects, repos, execution processes, organizations, invitations, OAuth tokens, PR comments, scratches, MCP server queries, etc.). This keeps local-web and remote-web typed against the same contract. Source: packages/web-core/src/shared/lib/api.ts:1-40
• Shared pages, including the kanban entry point consumed by both apps.
• Project routes — including a project-fallback-page export and a project-search module used by command-bar style navigation. Source: packages/web-core/package.json:1-15
• Cross-cutting libraries, for example colors.ts defines a 12-entry PRESET_COLORS palette in HSL plus a getRandomPresetColor() helper used for project/tag color assignment. Source: packages/web-core/src/shared/lib/colors.ts:1-30
• File-extension → language map for syntax highlighting in diffs and editors, covering web (ts, tsx, js, jsx, html, css, scss, json, yml), systems (c, cpp, rs, go, swift), JVM (java, kt, scala), and scripting (py, rb, lua, sql). Source: packages/web-core/src/shared/lib/extToLanguage.ts:1-30

Local vs. Remote Web Apps

Both local-web and remote-web are Vite-built React applications. They share the same UI library and web-core pages; what differs is the backend they point at and the routing surface.

The remote web home page illustrates the data-flow pattern. It renders an OrganizationSection per org (showing the org name and project count) and a responsive grid of ProjectCards per section. When no host is configured, the card is a CTA that opens relay settings via the onRequireHost handler. Source: packages/remote-web/src/pages/HomePage.tsx:1-60

The remote project kanban route is a deliberately thin shell that delegates to web-core:

import { ProjectKanban } from "@/pages/kanban/ProjectKanban";

export function RemoteProjectKanbanShell() {
  return <ProjectKanban />;
}

Source: packages/remote-web/src/pages/RemoteProjectKanbanShell.tsx:1-5

This pattern — a per-app shell that delegates to a web-core page — is how both apps render the same kanban, workspace, and diff surfaces without forking behavior. A CenteredCard helper and ProjectCardSkeleton also live in the remote home page for empty/loading states. Source: packages/remote-web/src/pages/HomePage.tsx:1-60

Kanban & Workspace UI

The kanban surface is the project's defining feature. The README describes it as:

Plan with kanban issues — create, prioritise, and assign issues on a kanban board. Run coding agents in workspaces — each workspace gives an agent a branch, a terminal, and a dev server. Review diffs and leave inline comments — send feedback directly to the agent without leaving the UI.

Source: README.md:1-80

Concretely, the workspace UI is built from @vibe/ui primitives (kanban board, command bar, workspaces main panel) wired into web-core pages. The remote home view demonstrates the data-flow pattern: an OrganizationSection consumes OrganizationWithProjects records, a ProjectCard resolves a host, and clicking through lands on ProjectKanban for the full board.

Community Context

Several open community items are relevant to the frontend:

• #2687 "Bring back old UI" (39 comments) — users report that upgrading from 0.1.7 → 0.1.9 removed the option to disable workspaces and surfaced concerns that the new UI is "less kanban" than the previous one, with old tasks and projects appearing to be lost on upgrade.
• #3396 "Support for self-hosted projects and better export" — given the Bloop company shutdown, the community is asking for first-class self-hosting of the remote-web features (organizations, projects) and portable exports of local data.
• v0.1.44 (latest release) shipped the pre-registered execution log store fix and CLI bumps, indicating the frontend is still receiving active maintenance.
• #3408 / #3433 discuss project status post-sunset; while the company's hosted instance is winding down, the open-source frontend remains the focal point for community contribution.

See Also

• Coding Agents & Executors
• Backend API & Project Model
• Local CLI & Tauri Desktop Shell
• Self-Hosting Guide

Related Pages

Related topics: Project Overview, Sunset Status & Monorepo Architecture, Frontend Web Apps, UI Library & Kanban Workspace UI

Server, Cloud/Remote API, Relay/Tunnel & Security

Overview

Vibe Kanban ships as a local-first desktop/server application, but it also exposes a hosted "Remote" Cloud API and a relay/tunnel layer that lets a browser-based client reach a user's self-hosted backend without opening inbound firewall ports. The crates/remote crate hosts the API and web app, while the relay subsystem brokers signed sessions between a remote browser and the local backend over WebRTC with a relay fallback Source: [crates/remote/README.md:1-34]. Self-hosting is documented as a supported deployment path; the Remote README lists required and optional environment variables, including JWT secret, Electric DB role password, OAuth provider credentials, and Loops email template IDs Source: [crates/remote/README.md:3-32].

The project repository is also marked as sunsetting; Bloop, the company behind Vibe Kanban, has announced that the project will continue as open source / community maintained Source: [README.md:1-15]. This status affects cloud-hosted services (Cloud API at api.vibekanban.com, Remote web app, OAuth flows, organization invitations) but does not affect the ability to self-host the open-source codebase.

Architecture

The runtime consists of three loosely-coupled layers:

1. Local backend — Rust/Axum API with SQLite, started via npx vibe-kanban Source: [npx-cli/README.md:14-22, README.md:23-25].
2. Remote API / web app — crates/remote exposes v1 JSON endpoints and the remote-web SPA; it depends on Electric for sync and TanStack Query/Router for the client Source: [packages/remote-web/package.json:1-30, packages/web-core/package.json:1-30].
3. Relay/Tunnel — A WebRTC direct path with relay fallback, wrapped by the WebRtcConnection class on the browser side and a PAKE-based pairing flow on the host side Source: [packages/remote-web/src/shared/lib/webrtc/connection.ts:1-40, scripts/relay-test-client/README.md:24-32].

flowchart LR
  Browser[Remote Web SPA] -->|HTTPS| Remote[Remote API<br/>crates/remote]
  Browser -->|WebRTC<br/>direct or relayed| Host[Local Backend<br/>npx vibe-kanban]
  Host -->|Relay path| Relay[Relay Service]
  Remote -->|OAuth<br/>GitHub/Google| IdP[Identity Providers]
  Host -->|Local FS<br/>SQLite| Disk[(SQLite + git worktrees)]

The shared client API helpers (web-core/src/shared/lib/api.ts) implement a host-aware request router that resolves whether to call the local backend, a scoped host, or the Remote Cloud API depending on hostScope Source: [packages/web-core/src/shared/lib/api.ts:1-25]. The Remote SPA reuses the same kanban components as the local app via a thin shell component Source: [packages/remote-web/src/pages/RemoteProjectKanbanShell.tsx:1-5].

Remote API & Auth

The Remote API uses JWT for authenticated sessions. The self-hosting setup requires VIBEKANBAN_REMOTE_JWT_SECRET (an openssl rand -base64 48 value) and ELECTRIC_ROLE_PASSWORD Source: [crates/remote/README.md:3-14]. Auth providers are pluggable: GitHub OAuth, Google OAuth, or a bootstrap local-auth email/password pair for self-hosted deployments Source: [crates/remote/README.md:16-22].

Endpoints visible in the typed client surface include v1/invitations/{token}/accept, v1/oauth/web/init, v1/oauth/{provider}/start, v1/oauth/{provider}/callback, and v1/oauth/web/redeem Source: [packages/web-core/src/shared/lib/api.ts:1-90, README.md:1-5]. Organization endpoints (CreateOrganizationRequest, ListOrganizationsResponse, OrganizationMemberWithProfile, Invitation) are strongly typed and include billing status, role management, and invitation lifecycle Source: [packages/web-core/src/shared/lib/api.ts:30-90]. Transactional email is delegated to Loops, with overridable template IDs for invites, review-ready, and review-failed emails Source: [crates/remote/README.md:24-32].

Relay/Tunnel

The relay/tunnel layer connects a browser in the Remote SPA to a self-hosted backend over a NAT-traversing path. The scripts/relay-test-client exercises the full pairing handshake end-to-end:

1. POST {remote_api}/v1/hosts/{host_id}/sessions
2. POST {relay_api}/v1/relay/sessions/{session_id}/auth-code
3. GET {relay_url}/relay/h/{host_id}/exchange?code=…
4. POST {relay_session_prefix}/api/relay-auth/spake2/start
5. POST {relay_session_prefix}/api/relay-auth/spake2/finish
6. Signed GET {relay_session_prefix}/api/task-attempts Source: [scripts/relay-test-client/README.md:21-32].

Once connected, browser HTTP and WebSocket traffic are tunneled through a single reliable/ordered RTCDataChannel. Messages are fragmented using the "SaltyRTC chunked-dc protocol" with a 1-byte header; bit 0 marks end-of-message, bits 1–2 encode the reliable/ordered mode Source: [packages/remote-web/src/shared/lib/webrtc/chunking.ts:1-30, packages/remote-web/src/shared/lib/webrtc/connection.ts:1-30]. A DataChannelWebSocket adapter exposes a standard WebSocket interface on top of the data channel so existing app code works unchanged Source: [packages/remote-web/src/shared/lib/webrtc/dataChannelWebSocket.ts:1-30]. When WebRTC direct connectivity fails, traffic falls back to the relay host API, where requests are HMAC-signed via buildSignedHeaders against the paired host context Source: [packages/remote-web/src/shared/lib/relay/http.ts:1-30].

Security Considerations

Two high-impact security findings have been disclosed against the hosted Cloud service:

• OAuth return_to takeover (CVSS 8.8) — unvalidated return_to parameter on POST /v1/oauth/web/init plus the OAuth start/callback/redeem flow enables one-click account takeover of any user [Source: community issue #3429].
• Invitation redemption by any account (CVSS 6.3) — POST /v1/invitations/{token}/accept does not bind the token to the invited email, so any authenticated account can redeem it and join with the invited role, including Admin [Source: community issue #3430].

For self-hosted deployments, the practical hardening checklist derived from the configuration surface is: generate a fresh VIBEKANBAN_REMOTE_JWT_SECRET, set ELECTRIC_ROLE_PASSWORD to a strong value, configure at least one real OAuth provider rather than relying on SELF_HOST_LOCAL_AUTH_*, set PUBLIC_BASE_URL to the publicly-reachable origin, and override the Loops template IDs only when using a custom Loops account Source: [crates/remote/README.md:3-32]. The relay pairing code displayed in the local backend logs (Relay PAKE enrollment code ready) should be treated as a short-lived secret and rotated by re-pairing the host Source: [scripts/relay-test-client/README.md:15-20].

See Also

• Remote Project Kanban Shell source
• WebRTC chunking protocol
• Relay test client script
• Community issue #3396 — request for self-hosted projects and better export support

Doramagic Pitfall Log

Found 9 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Configuration risk - Configuration risk requires verification.

1. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.host_targets | https://github.com/BloopAI/vibe-kanban

2. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/BloopAI/vibe-kanban

3. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/BloopAI/vibe-kanban

4. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/BloopAI/vibe-kanban

5. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/BloopAI/vibe-kanban

6. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/BloopAI/vibe-kanban/issues/3430

7. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/BloopAI/vibe-kanban/issues/3429

8. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/BloopAI/vibe-kanban

9. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/BloopAI/vibe-kanban

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using vibe-kanban with real data or production workflows.

• Website content appears outdated after project sunset - github / github_issue
• is this project dead? - github / github_issue
• Title: Organization invitation can be redeemed by any account, not just - github / github_issue
• Title: Unvalidated OAuth return_to enables one-click account takeover of - github / github_issue
• After June 15, claude -p will draw from a separate credit pool — how i - github / github_issue
• Support Kimi CLI - github / github_issue
• Release v0.1.44 - github / github_release
• Release v0.1.43 - github / github_release
• Pre-release v0.1.42-20260410131124 - github / github_release
• Pre-release v0.1.41-20260403182044 - github / github_release
• Pre-release v0.1.40-20260401153532 - github / github_release
• Pre-release v0.1.39-20260331145823 - github / github_release