Deft puts agent proposals behind an approval queue, and ships the whole thing as Compose files

A workspace where the agent proposes and a person approves

Deft is a self-hostable, open-source workspace where people and AI agents share chat, tasks, knowledge, calendar context, approvals, and action history. The README puts the intended use in a single sentence: capture a team discussion into knowledge, ask Defty to propose a task using that context, review and approve the proposal, and keep the agreed details in the resulting task.

The core loop has four steps, and each one is a governance step rather than a feature.

First, capture the discussion. You save useful decisions and references in Knowledge with links back to their source conversation, which is what makes the later step possible.

Second, ask Defty for a task. With an AI provider configured, Defty can use workspace context to propose the title, owner, dates and description of the work.

Third, review and approve. Under a policy requiring review, you inspect the proposed details before approving, and trust settings can permit some actions to execute automatically.

Fourth, keep the agreed details. The task stores the approved content, and governed agent actions have approval history and receipts to inspect.

That last step is the one that distinguishes this from a chat window with an assistant attached. The record of what was proposed, who approved it and what was executed is part of the data model rather than a log you read afterwards.

The licence is AGPL-3.0-only, the homepage is deft.ing, and the last push was on 2026-10-20, with releases v0.3.0-preview.129, .128 and .127 all on that day.

Two authority models, and the difference is not cosmetic

The README draws a distinction that most agent platforms gloss over, and it is the part an adopter should read first.

Personal MCP connections use a different authority model. ChatGPT and other personal clients act as the authorizing user within their granted scopes and normal permissions. Their writes do not automatically enter Deft's agent approval queue. Defty and Agent Employees use agent identities and policy-based approval flows.

So a write from a personal client is a write as you, with your permissions, outside the queue. A write from Defty is an action by an agent identity, and it lands in the policy-based approval flow where a human reviews it.

That is a meaningful design distinction and it cuts both ways. For a personal client the ergonomics are good, because you are not approving your own keystrokes. For anything an autonomous agent does, the queue is where the control lives, and the README points at the MCP access and agents section of the self-hosting guide for the details.

The feature list also distinguishes the agent side. There are built-in Defty workflows for workspace questions and governed native actions, and personal MCP access for Codex, Claude, ChatGPT and streamable HT.

What ships today for people is substantial and worth noting, because the risk with a project at preview stage is that the human half is a demo. It is not: real-time chat with spaces, DMs, threads, mentions, reactions, files, presence and rich text, task management with Board, Table, Timeline, Calendar and personal views, notes and company knowledge with channel memory and a knowledge graph, native calendar events plus read-only ICS subscriptions, and a dashboard with inbox, notifications, people, teams, roles and profile management.

That is a working collaboration product with an agent layer attached, not a prototype with a chat box.

Running it from Compose files with four generated secrets

The quick start avoids building anything. You use the prebuilt v0.3.0-preview.15 release for evaluation, which targets Linux amd64 and needs Docker Desktop or Docker Engine with Compose v2. An AI provider is optional, and no source build, Node.js or pnpm is needed for that path.

You download four files from the release into a new directory: docker-compose.yml, compose.prod.yml, compose.release.yml and default.env.example. Then you create your environment file and generate the secrets.

cp default.env.example .env
openssl rand -hex 32  # POSTGRES_PASSWORD
openssl rand -hex 32  # JWT_SECRET
openssl rand -hex 32  # JWT_REFRESH_SECRET
openssl rand -hex 32  # ENCRYPTION_KEY

Each of the four is pasted independently into its corresponding .env variable, and all four are required for Docker including local evaluation. The README adds two instructions that matter operationally: keep the encryption key with your backups, and leave the AI keys empty and OLLAMA_URL commented unless you intend to configure a provider.

Then the image is pinned by digest rather than by tag.

DEFT_IMAGE=ghcr.io/maneek21/deft@sha256:665a66083adaaf9db876fa815203c854509c5fdde72b89a0db212fe2e07d398b

And the bring-up sequence runs the compose files in order.

docker compose -f docker-compose.yml -f compose.prod.yml -f compose.release.yml up -d postgres
docker compose -f docker-compose.yml -f compose.prod.yml -f compose.release.yml run --rm init
docker compose -f docker-compose.yml -f compose.prod.yml -f compose.release.yml up -d deft
docker compose -f docker-compose.yml -f compose.prod.yml -f compose.release.yml run --rm doctor
docker compose -f docker-compose.yml -f compose.prod.yml -f compose.release.yml run --rm smoke

The doctor and smoke steps are worth noting, because they are the difference between a deploy script and a verified one. The init step is used only with a fresh database, and the README says so explicitly, which is the sort of warning that saves someone a restore.

Configuration is baked at build time, and that is a real constraint

The compose file makes one architectural decision visible, and it has consequences for self-hosting.

The NEXT_PUBLIC_ variables must be present at build time, because Next.js bakes them into the client JS bundle. Compose interpolates them from the host .env automatically, and the compose file passes them as build args.

      args:
        NEXT_PUBLIC_APP_URL: ${NEXT_PUBLIC_APP_URL:-http://localhost:3000}
        NEXT_PUBLIC_API_URL: ${NEXT_PUBLIC_API_URL:-http://localhost:3001}
        NEXT_PUBLIC_WS_URL: ${NEXT_PUBLIC_WS_URL:-http://localhost:3001}

The Dockerfile repeats the warning in a comment: docker-compose passes these as build args, and you have to declare and export them before `next build` so self-hosted installs on custom domains and ports do not silently fall back to localhost:3001.

That last phrase is the one to hold on to. The failure mode is a workspace that starts, looks healthy, and then points its browser bundle at localhost:3001 regardless of what you configured, which is the kind of bug that costs an afternoon.

The stack itself is Next.js for the web app, an API on a separate port, Postgres with a vector extension for the knowledge graph, and a websocket endpoint. The repository topics name the pieces: nextjs, hono, drizzle-orm, postgres, pgvector, mcp, claude, byoa and ai-agents. The packages/ directory holds app-kit, db, shared and mcp, and the Dockerfile copies their manifests separately to make the dependency layer cache well.

The ports are configurable through the compose file, with the web port defaulting to 3000 and the API to 3001.

Alpha status, and the honesty about the demo data

The status badge is Alpha, and the README attaches a specific definition to it rather than leaving the word to do the work.

For technical evaluation and controlled pilots. The walkthrough uses seeded demo data, and it is not evidence of a live customer workspace or an active external agent runtime.

That sentence is worth taking seriously, because a walkthrough video is the most persuasive artefact a project like this has, and the README is saying that the video does not demonstrate a live system. It demonstrates the interface and the flow.

There is also a documentation pointer that is more useful than the video: the current availability map, which you are told to consult before enabling an experimental feature. Given the feature flags in the compose file, with NEXT_PUBLIC_FEATURE_HUDDLES, APPS, APP_RESOURCE_SYNC and APP_ATTACHMENT_BROKER all defaulting to false, the product has clearly moved past a single coherent feature set and the flags are how you navigate that.

On versioning, the release numbers are the tell. The three most recent are v0.3.0-preview.129, v0.3.0-preview.128 and v0.3.0-preview.127, all on 2026-10-20, and the quick start points at v0.3.0-preview.15 while the Dockerfile names v0.3.0-preview.16. That is a project shipping many previews a day.

The repository also carries a DEMO-WALKTHROUGH.md, an FEATURES.md, a ROADMAP.md, a SECURITY.md, a SUPPORT.md and a RELEASING.md, and the docs directory holds the self-hosting guide, the getting started pages, the product status map and the current limitations document, which is linked from the README as the place to find what does not yet work.

Where Deft is the wrong choice

Three cases, and each is stated in the repository rather than inferred.

The first is if you need something stable. Alpha status with preview numbering in the hundreds is a project in active development, and the licensing history makes the direction explicit: historical releases through v0.2.0-preview.4 retain their shipped BSL 1.1 licence, and the selected release is AGPL-3.0-only. The project changed licence, which is a reasonable thing for a pre-1.0 project to do and a strong signal that the earlier terms should not be relied on.

The second is if you want an agent that acts without a human in the loop for anything meaningful. The core loop puts a review step in the middle, trust settings can permit some actions to execute automatically, and governed agent actions keep approval history and receipts. That is the right default for a system that touches shared workspace state, and it is the wrong default if you want an assistant that just gets on with the job. The personal MCP route is the escape hatch, and it comes with the authority model described earlier.

The third is if your environment is not Docker on Linux amd64. The prebuilt path targets Linux amd64 with Docker Desktop or Docker Engine with Compose v2, and everything else, custom ports, public URLs, image verification, source builds, backups and upgrades, is in the self-hosting guide rather than the quick start.

One operational caveat to plan for. The README says to keep the encryption key with your backups, and the .env.example is explicit that ENCRYPTION_KEY is the symmetric key for encrypting per-organisation BYOK API keys at rest, that production needs distinct non-template keys of at least 32 characters with no surrounding whitespace, and that Docker runs in production mode including local evaluation. That last detail is the one people get wrong: a local evaluation install is not a relaxed mode, and a placeholder key there is a real risk rather than a harmless shortcut.

Editorial conclusion

Adopt Deft if you want a self-hosted workspace where an assistant can propose work into an approval queue and you can inspect the receipts afterwards, and you have Postgres and Docker to host it. Do not adopt it if you need a stable product, because it is alpha and the releases are numbered v0.3.0-preview, and note that the walkthrough you will read uses seeded demo data rather than a live workspace. Verify first which authority model your client falls under, since personal MCP connections write as you and bypass the agent approval queue entirely.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Maneek21/Deft on GitHub
3. Project website
4. README
5. Releases