Skip to main content

Choose Your Track

Most first-time users arrive with one of two goals:

Embedded Track​

Choose this path if you want Transit as a Rust library inside your own process.

Typical signs:

  • you want local append and replay first
  • you care about branch and merge semantics in-process
  • you want to understand tiered publication and restore without a network hop

Start with:

Server Track​

Choose this path if you want to run Transit as a daemon and access it over the network.

Typical signs:

  • you want a remote append/read/tail surface
  • you need client/server separation
  • you need a producer/consumer workload that can raise hosted I/O timeouts without changing record semantics
  • you want the same shared engine semantics exposed through a server boundary

Start with:

  • transit proof networked-server --root target/transit-docs/networked --server-connection-io-timeout-ms 5000 --client-io-timeout-ms 5000
  • transit proof hosted-authority --root target/transit-docs/hosted-authority --server-connection-io-timeout-ms 5000 --client-io-timeout-ms 5000
  • Capabilities
  • the networked server proof in the CLI output
  • Server First Run

For downstream cutover work, the canonical target is the hosted pair of transit-server plus transit-client. Do not preserve a repo-local hosted adapter layer once those upstream surfaces replace it.

Those timeout flags tune transport behavior only. They do not change append, replay, batch append, or tail semantics.

How To Decide Quickly​

Use the embedded track when your application wants direct engine calls and local storage semantics first.

Use the server track when you want a network boundary, remote clients, or a daemon process that exposes the same model over RPC-like CLI commands and client libraries.

Current State​

This site ships both the public onramp and the core foundations. When you want the model behind the narrative pages, continue into Foundations.