Entire Launches Free Private Repository Hosting, Adds AI Review and Cross-Session Memory

On October 26, 2026, Entire added a feature to "Entire," its development platform for collaboration between people and AI agents, that directly hosts private repositories for free. In addition to the existing GitHub mirroring, it became possible to use the platform without keeping the original repository on GitHub. It also provides features such as code review by agents, and a function that lets AI agents in a new session refer to policies decided and approaches tried in previous sessions. Hosting is free, and agents run on the service are charged according to AI model usage.

Co-founder and CEO Thomas Dohmke, in an X post accompanying the announcement, said that agents have changed how code is made and transformed half of development tools and workflows, and that it is time for the remaining half to catch up. In a following post, he introduced decentralization of Git hosting, sharing of session records between agents, and a mechanism for using review results in the next round of fixes. He said Entire itself has also been developed using Entire.

Agents reinvented how we produce code. It changed our tools and half of our workflow. It’s time for the other half to catch up. Today, we’re shipping Entire: the Git forge for agent-human collaboration. We’ve built @GoEntire using Entire. Now we want to see what you'll build with it.

Here’s why and what’s different. 🧵— Thomas Dohmke (@ashtom) October 26, 2026

From CLI and GitHub mirroring to an independent development foundation

On February 10, 2026, Entire announced as a new company its vision for a development platform where people and AI agents collaborate. At the same time, it released the open-source Entire CLI as its first product. A feature called Checkpoints links session information such as prompts and tool calls to Git commits, making it possible to trace the history of changes.

In its July 8 announcement, it introduced a feature to mirror public and private GitHub repositories to Entire. With GitHub as the original storage location, a copy is placed on Entire in a region selected by the user, making it possible to retrieve code from that copy. And with this latest announcement, an option was added to host repositories solely on Entire without keeping the original repository on GitHub.

Hosting private repositories for free

Repositories on Entire can be created from the web interface or the CLI. Users choose a primary region and, if necessary, place replicas in other regions. As of the October 26 announcement, the service is available in the United States, Europe, India, and Australia. The target for direct hosting is private repositories, with support for public repositories also planned.

According to the repository description, whereas a normal push to a GitHub mirror is forwarded to GitHub, when hosting directly on Entire, both reads and writes are processed within Entire.

According to the pricing explanation, Entire charges only for AI model usage by agents run on the service, and other features such as hosting can be used for free. Using agents requires prepaid credits[1].

EntireDB supporting distributed Git hosting

On October 27, Entire explained the design of EntireDB, which handles repository storage and Git reads and writes. The company cites as a challenge the concentration of read requests on the original storage location when many agents clone repositories, for example. EntireDB places a complete copy of each repository in each deployment region, and each copy responds to clone and fetch requests. This is said to avoid read requests concentrating on a single storage location.

In each region, repositories are managed in units called cells, which combine a PostgreSQL database and multiple storage nodes (hereinafter "nodes"). For each repository, multiple nodes within the same cell are assigned as storage destinations. Git objects, which record file contents and commits, are replicated and stored on those nodes. Since the contents of Git objects do not change after creation, they can be received in parallel by multiple nodes. On the other hand, the references of branches and tags, which are updated, are managed in PostgreSQL, and when updates to the same branch, etc. overlap, they are processed in order.

During a push, the client sends data bundling Git objects, and the receiving node forwards it in parallel to other nodes that store the same repository. Then, after validating and persistently storing the data, it updates references such as branches[2]. For reads, even if the responding node does not have the necessary data, it can be obtained from another node in the same cell that stores that repository. Therefore, there is no need to make reads wait until replication to all nodes that store the repository is complete.

When replicating a repository to other regions, data is synchronized between cells. However, the location where writes are committed is fixed to one per repository. For repositories hosted directly on Entire, that location is called the home cell, and pushes received in other regions are also forwarded there. While reads can be served from copies in each region, there may be a delay before changes committed in the home cell are reflected in copies in other regions.

The company also plans to open-source EntireDB itself within the next few months.

Trails consolidate review results and merge conditions

For code review, Trail is introduced as a mechanism replacing pull requests. A single Trail can consolidate the purpose of the work, code changes, agent sessions, and review results, and can also handle changes across multiple repositories involved in the same work. Using review agents is optional, and humans can also check the diff and approve/merge.

When a review agent is enabled, a push to a Trail can trigger automatic evaluation of code quality, security, and so on. This evaluation incurs charges according to the AI model usage. Evaluation items can be customized, and results show scores, reasons, and individual findings. Developers can pass the findings to a coding agent and repeat fixes and re-reviews. The screen displays the evaluation results from the current and past five runs, allowing developers to decide whether to merge based on the trend of evaluations and unresolved findings. A feature called Gates for managing merge conditions allows setting conditions such as resolution of findings, human approval, and CI success.

CI integration supports Buildkite and Depot and is offered in public preview. Both services also provide mechanisms to convert and migrate existing GitHub Actions workflows. When pushing to a repository with integration configured, the CI service runs builds and tests and returns the results to the Trail. Using CI is subject to each CI service's pricing.

Continuous Memory leveraging information from previous sessions

With Continuous Memory, the AI agent in a new session can search and reference the reasons for implementation choices and the approaches tried in previous sessions, and proceed with work based on that history.

This feature uses entire-graph and entire-brain in combination. entire-graph organizes definitions and call relationships in the code, and entire-brain links sessions recorded in Git history by the Entire CLI with that structure. For example, when revisiting how to retry failed requests in software under development, it can find the retry policy decided in a previous session and modify the code based on that history.

entire-graph and entire-brain are open source and are intended primarily for local use. Knowledge and decisions recorded in entire-brain are also stored on the local machine by default. To share them with a team, connect to a repository on Entire and enable synchronization. After an initial synchronization upon connection, synchronization continues in the background, allowing knowledge and decisions accumulated on each person's machine to be shared.