Backplane

Shared context for projects that outlive a coding session.

🏠 Self-hosted   ·   🔌 Bring your own agents   ·   🧭 Your methodology

Start every new coding session with an organized, coherent and updated context

Backplane is a shared workspace for your team and coding agents. Keep tasks, project definitions, notes, and decisions together, so the next person or agent can pick up the work with the context behind it. Shared skills preserve how your team works, ready to reuse across projects.

🏠 Self-host Backplane · 🔌 Connect your agent · 🌐 Website, Cloud & support

Your workshop · Skills · Runner TUI · Screenshots · Documentation · Report an issue

[!NOTE] Open Source Preview. Start with Self-hosting for an instance with password login. Bring your own agents whenever you're ready.

APIs and workflows may evolve. Runners are experimental; review the known limitations before planning a deployment.

See the project at a glance. Keep the details within reach.
_{Tidewatch demo project · Open full size: Light / Dark}

Your workflow belongs here

A shared workshop. Your way of building.

Think of Backplane as a well-equipped garage for your projects. The plans are on the wall, the tools are within reach, and the work is ready for whoever walks in next: you, a teammate, or your agent.

Your team defines the method. Backplane gives it a shared home. Keep the what and when on your boards, the context in notes and resources, and the how in reusable skills.

There is no prescribed project methodology. Start from optional templates, bring your own conventions, and choose how the tools work together. That freedom takes some setup. You can also build a more guided experience on top of Backplane.

The workshop is ready. The way you build is yours.
_{A map of the tools, not a fixed sequence. Open full size: Light / Dark}

Three ways to use Backplane

	Organize the work, keep the context Tasks, definitions, notes, and decisions give you and your team a shared place to plan, track progress, and preserve why a decision was made. Start here. Useful on its own, without an agent.
	Let your agent join the project Connect through MCP to read and update boards, cards, and notes from the coding tools you already use. Your agent, your credentials. No runner required.
	Make delegated work observable Add optional runners for configured workflows. Choose roles, providers, budgets, and approval gates, then follow progress, results, and costs. Experimental. Configure the process around your team.

Skills: share the how

Boards, notes, and resources keep the what and when. Skills carry the how.

Turn a useful method into a shared, reusable skill: your release checklist, debugging approach, review standards, or team conventions. Keep it in your workspace library and apply it to the project boards that need it.

• 📚 Build your team's playbook. Author your own SKILL.md bundles or start from the built-in catalog. Your methodology stays yours.
• 🔗 Share across projects. Reuse a skill across boards in your workspace. Each board can follow the latest published version or pin a version.
• 🌱 Improve as you learn. Publish new versions as your methods evolve. Runner agents can propose improvements; humans review and approve publication.
• 🔌 Put it to work. MCP-connected agents can read skill files. Configured runners place board skills where Claude Code and Codex discover them.

A good method should survive the session that discovered it.
_{Harborlight demo workspace · September 2026 · Open full size: Light / Dark}

Bring the agent you already use

Your tools can change. Your project context can stay together.

Backplane exposes boards, cards, notes, skills, and project context through MCP. Choose a terminal, editor, or desktop assistant. Familiar clients with local MCP server support include:

Use backplane-mcp over stdio to connect a compatible MCP client, including your own agent, to your instance. Streamable HTTP is also available where the client supports it. Follow the linked client documentation and our MCP setup guide; configuration and available MCP features vary by client.

Connect your agent →

⚙️ Want Backplane to run the work? The optional runner currently executes Claude Code and Codex CLI. Runners are experimental and are a separate setup from connecting an MCP client.

A closer look

📍 Give everyone the same starting point Scope, objectives, and boundaries stay alongside the work they guide. Full size: light · dark

🔎 Follow the work beyond its status Keep the description, dependencies, participants, and linked pull request together. Full size: light · dark

_{Original captures of fictional demo projects, September 2026. Screenshots follow your light or dark theme.}

Want the full tour? Explore more product screens, including notes, resources, approvals, skills, and activity views.

The runner in your terminal

🖥️ Plan in Backplane. Run with your own agents. See what happened.

The optional Backplane Runner takes work from the platform, runs your configured workflow in your repositories, and reports the results. The terminal UI (TUI) guides setup; the console keeps execution visible.

• Choose how to run. Use pipeline assignments or board loops with Claude Code or Codex CLI, on your own machine and credentials.
• Review before launch. Choose the board, agent, model, and MCP configuration in the guided wizard. Review the settings and save a reusable profile.
• Follow the work. See assignments, execution stages, reported costs, and Git outcomes in the console. Runner forge support covers GitHub and Gitea.

Your next run, ready to review before it starts.
_{Local demo TUI capture · August 2026 · Open full size: Light / Dark}

🔎 See a demo execution: assignments, stages, costs, and Git activity

From a card to a recorded result. The console shows the work as it moves through the configured stages, including agent completion and Git activity.

_{Local demo executions captured August 25, 2026. Light and dark show separate runs, so timestamps and reported costs differ. Open full size: Light / Dark.}

Runners are experimental. Start with the runner setup guide and provider guide for current requirements and configuration.

Why I'm building Backplane

When we founded Valaris, I kept coming back to two questions:

• How do we keep a team aligned when everyone works with coding agents?
• How do we stay aware of our projects' context and progress?

Backplane started as our project management tool. It gradually became our shared context manager: the place we use every day to organize work, preserve decisions, and collaborate on our own projects and our customers' projects.

Coding agents are awesome. But over longer projects, their sessions can start to look like Swiss cheese: useful work, with holes in the context between sessions, people, and tools. Those gaps accumulate unless someone actively takes care of them.

"Trust me bro" isn't enough for us. We want to understand what's planned, when and how it should happen, and what happened before.

And we want that information to be easy to share with both people and agents.

Backplane gives us a durable place to keep that context and coordinate the work around it. We built it for ourselves, and we're opening it up because we think others might find it useful too.

Sebastian, cofounder of Valaris

Different sessions. One place to pick up the thread.

 session 01   session 02   session 03
      \           |           /
       +----------+----------+
                  |
            [ Backplane ]
          context that stays

How it fits together

flowchart TB
    H["People"] <-->|Web app| B["Backplane<br/>Project context · Tasks · Skills"]
    A["Your coding agent"] <-->|MCP| B
    B -->|Configured work and context| R["Optional runners<br/>Experimental"]
    R -->|Progress, results, costs| B
    R --> G["Your repositories"]

🧩 Bring the intelligence. Backplane keeps the work connected.

• People and agents share the same project record, through the web app and MCP.
• The platform owns the configuration, scheduling, prompts, and authorization.
• Optional runners execute that contract and report progress, results, and costs.

Runners can work in separate Git branches and open pull requests. They execute agent commands on their host; see Known security posture.

The runner currently supports Claude Code and Codex CLI, with GitHub and Gitea for the pull-request lifecycle. Connecting through MCP does not require a runner.

Self-hosting

🏠 Your infrastructure. Your project context.

Run Backplane with one Compose file: Postgres, backend, and frontend. Local password login is enabled by default, with no cloud dependency.

☁️ Cloud & support: Visit getbackplane.ai for product information and the planned Backplane Cloud offering, including managed hosting, support, and guided onboarding. Cloud is not yet available.

1. Configure and start

git clone https://github.com/Valaris-Studio/backplane.git
cd backplane
cp .env.example .env
# in .env, fill in the two required secrets:
#   POSTGRES_PASSWORD: any strong value
#   OAUTH_STATE_SIGNING_KEY: generate with: openssl rand -hex 32
# browsing from another machine? also set BACKPLANE_URL=http://<host-ip>:8080
docker compose -f docker-compose.prod.yml up -d

2. Create your admin account

Open http://localhost:8080 or your BACKPLANE_URL. The first-run screen creates your admin account; later visits use the normal login page. Use BACKPLANE_HTTP_PORT to override the port.

The first start builds backend and frontend from source, then runs database migrations automatically. There are no published images for these two services and no manual migration step. Allow a few minutes for the first build and startup.

docker compose -f docker-compose.prod.yml logs -f backend

docker compose -f docker-compose.prod.yml ps

3. Explore a populated workspace (optional)

Seed the same demo workspace used in development. Pass the email of your first-run account to give it owner access to the seeded workspace:

docker compose -f docker-compose.prod.yml exec -T backend python -m scripts.seed_demo --email you@example.com

[!IMPORTANT] Putting Backplane on the internet? Follow SECURITY.md and Securing a Self-Hosted Deployment in the in-app documentation for TLS, proxies, and OIDC.

Connect your agent

🔌 Bring your agent into the same project context.

Once your instance is running, connect an MCP-capable coding agent to read context and work with boards, cards, and notes.

1. Create an API key from your account menu under API Keys.
2. Connect your client using the MCP setup guide. Configure backplane-mcp with your instance URL and API key.
3. Start with the default toolset for everyday project work.

The MCP server is available on PyPI and runs through uvx backplane-mcp. The setup guide covers credentials, client configuration, and protecting remote HTTP connections.

💡 Give your agent somewhere to start. Once connected, try:

Read this project's definition and assigned skills, then summarize its goals and working conventions.

Show me the blocked cards and their dependencies.

Record our decision in a project note so the next session can find it.

Use your own prompts and conventions. The shared context stays in Backplane when you switch sessions or tools.

Optional runners

See the terminal UI and demo execution above ↑

⚙️ Ready to let agents pick up work? Add a runner as a separate step. Runners are experimental. You need a coding-agent CLI on PATH and forge credentials.

Open Runner → Runners → Create runner to use the Launch runner wizard:

Identity → Roles → Config → Launch

The wizard ends with the command that starts the binary. For the full guide, see Documentation → Getting Started → Registering a Runner in the app, or runner/README.md. The in-app guide is also available at /documentation without creating a workspace.

[!NOTE] Before your first make dev-runner: if ~/.claude.json does not exist, run touch ~/.claude.json. Otherwise Docker creates a root-owned directory at that path instead of bind-mounting the file.

Quickstart

🛠️ Working on Backplane itself? Start here.

This is the local development setup, with automatic authentication. For an instance with password login, follow Self-hosting.

You need: Docker + Compose, git, make, bash, and curl. The stack runs in containers. Native Python, Node, pnpm, and Go installs are only needed for development outside Docker. Optional lsof improves the health helpers' port checks.

1. Start the stack in Terminal A

# Terminal A
git clone https://github.com/Valaris-Studio/backplane.git
cd backplane
cp .env.example .env      # defaults work for local dev as-is
make dev                  # Postgres :5433 + backend :8000 + frontend :5173

make dev stays in the foreground and streams logs. Wait for Application startup complete from the backend and VITE ready from the frontend. Migrations run automatically, so first boot takes a little longer.

2. Add sample work in Terminal B (optional)

# Terminal B (optional)
make seed-demo            # a sample workspace + populated board

The demo gives you a populated board to explore. It is safe to re-run and refuses to add demo data to an instance that already holds real work. Use FORCE=1 only if you intend to override that protection.

3. Open the app

• App: http://localhost:5173. You are automatically authenticated as dev@valaris.dev, with no signup flow.
• Interactive API docs: http://localhost:8000/api/docs (Swagger UI).

Stop and resume: Ctrl+C in Terminal A stops the stack. Your database stays in a Docker volume, so make dev picks up where you left off.

[!WARNING] make clean deletes your database. It runs docker compose down -v and also removes local node_modules and build output. Use it only when you want to throw everything away.

Documentation

📚 The full guide ships with the app.

Open /documentation on your instance: self-hosted · local development.

It covers core concepts, every pipeline field, operations, and architecture, plus a candid guide to current rough edges.

Find the reference you need:

Need the live API contract? A running instance serves Swagger UI at /api/docs in development and the machine-readable schema at /api/openapi.json. The checked-in export may lag the live schema. Regenerate it with python scripts/export-openapi.py while the backend venv is active.

Known limitations

🚧 Know what fits today and what still needs care.

Authentication works out of the box, but is still young. It has less mileage than the rest of the platform. Verify your first deployment carefully.

Other boundaries to consider:

• Storage: local disk by default, with Google Cloud Storage as an alternative. There is no S3 driver yet.
• Distribution: backend and frontend ship as source, not images; Docker Compose builds them locally. Client artifacts are released separately: the runner as a multi-arch image (ghcr.io/valaris-studio/backplane-runner) and standalone binaries with checksums (darwin/linux/windows × arm64/amd64), and the MCP server through uvx backplane-mcp.
• GitLab PAT connections are supported for repository credentials and backend merge-queue plumbing. The runner forge driver for GitLab does not yet open, review, or merge merge requests. Those lifecycle operations currently support GitHub and Gitea.

Telemetry

🔒 Telemetry is off by default. The endpoint ships empty.

Sending a ping requires both settings:

BACKPLANE_TELEMETRY_ENABLED=true
BACKPLANE_TELEMETRY_ENDPOINT=<your-explicit-endpoint>

• Five fields only: a one-way hashed instance identifier, Backplane version, Python version, user count, and workspace count.
• No project content: no names, emails, workspace slugs, card content, repository URLs, or prompts.

Inspect the payload implementation.

Contributing

💬 Your feedback helps shape Backplane.

Backplane is maintained solely by the Valaris team and is not accepting outside code contributions yet. External pull requests will be closed unreviewed. We have no contributor agreement in place and want you to know before investing time in a patch.

We expect to open contributions once the architecture settles. CONTRIBUTING.md carries the current policy, development loop, Router → Service → Repository → Model layering rules, and test-first expectation.

License

⚖️ Licensing follows the component. See the full map in LICENSES.md.

Third-party dependencies, including the documented non-OSI exception (GSAP), are covered in THIRD_PARTY_LICENSES.md.

Naming

🏷️ The product is Backplane. The valaris MCP namespace and VALARIS_* environment variables remain stable technical identifiers so existing agent configurations keep working.

See the full naming policy.

Keep the next session connected to the work you have already done.
Self-host Backplane · Connect your agent · Explore Backplane, Cloud & support