TrueForge runs the agent loop and exposes it as UI, API and embedded SDK

One npx command, a Node 22.14 floor, and two storage choices

The quickstart entry point is a single command, and the runtime floor behind it is not negotiable. The workspace package.json pins node >=22.14.0 under engines. Behind that sit two modes with different storage. Local mode is a single process with SQLite and no extra infrastructure, meant for personal use and for a first look. Hosted mode replaces SQLite with Postgres, adds Redis, and is the mode described as fit for teams and multi-replica work, run through Docker Compose, Helm, or Railway. For anyone building from source the workspace is pnpm based, with packageManager pinned to [email protected] and pnpm-workspace.yaml plus pnpm-lock.yaml at the root. Two scripts show the shape of the dev loop:

"dev:infra": "docker compose -f docker-compose.dev.yml up",
"dev": "cross-env STANDALONE=false NODE_ENV=development pnpm --parallel --filter @truefoundry/trueforge-core --filter @truefoundry/trueforge --filter frontend dev"

Local mode has no login and is not built for a second machine

The project states the limits of the quick path plainly. Local mode is for your machine only: there is no login by default, data lives in a local SQLite file, and the instruction is to keep it on localhost. Exposed to a network it has nothing in front of it, and the stated position is that the team cannot take responsibility for data loss or unauthorized access once local mode is used beyond a personal setup. Shared or production deployments are pushed to hosted mode instead, and the documentation carries a separate setup-login page for optional OIDC on shared deployments. The difference is more than the STANDALONE flag: it is a different storage backend, an added Redis service, and a different deployment path, so a team that evaluates the harness on a laptop and then puts it on a server has changed more than a hostname.

Redis is there for the cross-replica turn cancel, not for caching

Hosted mode brings in two services that local mode does not need, and the compose file says what each one is for. Postgres 17 holds the data, with a healthcheck running pg_isready every five seconds and a volume mounted at ./data/postgres. Redis 7 alpine is shared by all server replicas and carries executor peering, which the comments describe as cross-replica turn cancel over request-reply, so a cancel issued on one replica can reach a turn running on another. That is why the compose file runs a single replica but keeps peering switched on, so the path stays exercised. A single-process deployment can set STANDALONE=true and drop redis, and STANDALONE=false is what selects Postgres plus Redis. Port handling is the other trap, and it is written into the file:

    ports:
      - '8791:8790'
    environment:
      NODE_ENV: production
      PORT: 8790
      PUBLIC_BASE_URL: http://localhost:8791
      POSTGRES_HOST: postgres
      POSTGRES_PORT: 5432

Host port 8791 exists to stay clear of a dev server on 8790, and PUBLIC_BASE_URL is the mapped port rather than the container port because MCP OAuth callbacks come back to it. The server image itself is built from the root Dockerfile as truefoundry-server:latest, serving both API and UI on one port, and it reads secrets from packages/trueforge/.env, which the compose file marks as required.

Resources are configured once and agents pick from the connection

Setup is treated as a catalog problem rather than a code problem. Models, MCP servers, skills and the sandbox are connected once through the initial setup pages, and after that agents select from whatever is already connected. Presets arrive as shipped YAML catalogs you can customize, and the same pages carry the overrides, so the intended workflow is to edit configuration in one place and let many agents inherit it. Remote MCP servers are supported with header auth or OAuth, including authorization handled inside the chat rather than only at setup time, which matters when the person approving a tool call is not the person holding the credentials. Model choice is deliberately open: OpenAI and Anthropic are named directly, other providers come through the catalogs, and any OpenAI-compatible endpoint is accepted.

The sandbox is provisioned on demand, and only on Daytona today

Code execution is a capability the harness hands to an agent as a tool, not a mode you switch on for the whole server. The sandbox covers isolated code and file execution, it is provisioned only when needed, and secrets stay inside the harness instead of being handed to the sandbox. The provider list is short: Daytona today, with more providers planned. That is the dependency worth noticing early, because a planned provider is not a swappable one, and anything that pins the isolation layer to Daytona settles a deployment decision before the first agent is written. Skills ride on the same mechanism. They are git-backed SKILL.md instruction packs loaded on demand inside the sandbox, so their loading cost follows the task rather than the startup path.

Context control is a menu of five separate mechanisms

Context handling is where a harness either holds up or gives way, and TrueForge splits it into named pieces. Subagents let a turn branch into delegated work. Deferred tool loading keeps tools out of the context until a call needs them. Large-result offloading moves bulky outputs somewhere other than the conversation, and compaction shortens the history that has already accumulated. Sitting between models and sessions are the human checkpoints: tool approval, ask-user-questions, and Generative UI rendered in chat, which is what keeps a running agent from acting on your behalf without a person in the loop.

The benchmark is self-reported and the sandbox list is short

Two things deserve your own verification rather than a repeat. The benchmark compares TrueForge against Claude Managed Agents and deepagents on the same tasks, tools and model, and the project states the outcome as the same accuracy at lower cost. The code sits in the benchmark directory so a reader can reproduce it, and the write-up lives on the docs site, but it is a comparison the project runs against its own stack. The release picture looks active without being finished: three packages moved together on November 2, 2026, with @truefoundry/trueforge-ui at 0.183.0-rc.4, @truefoundry/trueforge at 0.183.0-rc.3 and @truefoundry/trueforge-sdk at 0.183.0-rc.1, and the main branch was last pushed on November 2, 2026. The license is MIT. Version numbers below 1.0 across three packages mean interfaces can still move, and fork pull requests are asked to change source only because maintainers regenerate parts of what gets published. Release plumbing follows the same shape, with a .changeset directory at the root, a script that regenerates the SDK, and a Helm chart under charts/trueforge that is linted and templated against its own ci values file.

Editorial conclusion

Adopt it if your team wants the loop, the tool connections and the chat surface owned by one runtime, and can accept Node 22.14 as the floor (plus pnpm for building from source). Skip it if you need a second sandbox provider today or an independent benchmark, because neither exists in the repository.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. truefoundry/trueforge on GitHub