Ecosystem
The Virtufin platform is a federation of focused repos. Each repo ships its own documentation site; the sites cross-link so a developer can find related material without leaving the platform.
Solid arrows are real dependencies (package/build-time); dashed arrows are "deploys" relationships, not code dependencies. Click any node to open its docs site (or repo page, where no docs site exists).
graph TD
subgraph Foundation
dotnet["virtufin-dotnet<br/>.NET core libraries"]
openspec["virtufin-openspec<br/>domain spec"]
common["virtufin-common<br/>CI/build tooling for all repos"]
end
subgraph "Core services"
api["virtufin-api<br/>API gateway"]
service["virtufin-service<br/>multi-instance coordination"]
wm["virtufin-workmanager"]
wsm["virtufin-websocketmanager"]
end
subgraph "Dev kits"
stratdevkit["virtufin-strategy-devkit"]
execdevkit["virtufin-execution-devkit"]
indicdevkit["virtufin-indicator-devkit"]
end
subgraph "Deployable workers"
strategies["virtufin-strategies"]
execengines["virtufin-execution-engines"]
mdengines["virtufin-market-data-engines"]
workers["virtufin-workers"]
examples["virtufin-examples"]
end
subgraph Frontends
tui["virtufin-tui"]
app["virtufin-app"]
site["site"]
end
subgraph Deployment
helm["helm"]
deploylocal["deploy-local"]
dockercompose["docker-compose"]
end
docs["docs<br/>(this site)"]
service --> api
wm --> api
wm --> service
wsm --> api
wsm --> service
stratdevkit --> dotnet
stratdevkit --> wm
execdevkit --> dotnet
execdevkit --> wm
indicdevkit --> dotnet
indicdevkit --> wm
indicdevkit --> api
strategies --> wm
strategies --> stratdevkit
execengines --> wm
execengines --> execdevkit
mdengines --> wm
mdengines --> api
workers --> wm
workers --> api
examples --> wm
examples --> api
examples --> wsm
tui --> api
app --> api
app --> wm
app --> wsm
helm -.-> api
helm -.-> wm
helm -.-> wsm
deploylocal -.-> api
deploylocal -.-> wm
deploylocal -.-> wsm
dockercompose -.-> api
dockercompose -.-> wm
dockercompose -.-> wsm
dockercompose -.-> app
click dotnet "https://lib.docs.virtufin.com" "virtufin-dotnet docs" _blank
click openspec "https://specs.docs.virtufin.com" "virtufin-openspec docs" _blank
click common "https://git.haenerconsulting.com/virtufin/virtufin-common" "virtufin-common repo" _blank
click api "https://api.docs.virtufin.com" "virtufin-api docs" _blank
click service "https://git.haenerconsulting.com/virtufin/virtufin-service" "virtufin-service repo" _blank
click wm "https://workmanager.docs.virtufin.com" "virtufin-workmanager docs" _blank
click wsm "https://websocketmanager.docs.virtufin.com" "virtufin-websocketmanager docs" _blank
click stratdevkit "https://strategy-devkit.docs.virtufin.com" "virtufin-strategy-devkit docs" _blank
click execdevkit "https://execution-devkit.docs.virtufin.com" "virtufin-execution-devkit docs" _blank
click indicdevkit "https://git.haenerconsulting.com/virtufin/virtufin-indicator-devkit" "virtufin-indicator-devkit repo" _blank
click strategies "https://strategies.docs.virtufin.com" "virtufin-strategies docs" _blank
click execengines "https://git.haenerconsulting.com/virtufin/virtufin-execution-engines" "virtufin-execution-engines repo" _blank
click mdengines "https://market-data-engines.docs.virtufin.com" "virtufin-market-data-engines docs" _blank
click workers "https://workers.docs.virtufin.com" "virtufin-workers docs" _blank
click examples "https://git.haenerconsulting.com/virtufin/virtufin-examples" "virtufin-examples repo" _blank
click tui "https://tui.docs.virtufin.com" "virtufin-tui docs" _blank
click app "https://git.haenerconsulting.com/virtufin/virtufin-app" "virtufin-app repo" _blank
click site "https://www.virtufin.com" "virtufin site" _blank
click helm "https://git.haenerconsulting.com/virtufin/helm" "helm repo" _blank
click deploylocal "https://git.haenerconsulting.com/virtufin/deploy-local" "deploy-local repo" _blank
click dockercompose "https://git.haenerconsulting.com/virtufin/docker-compose" "docker-compose repo" _blank
click docs "https://docs.virtufin.com" "docs site (this site)" _blank
Virtufin repos
| Repo | What it is | Docs site |
|---|---|---|
| virtufin/docs | This site. The central hub — platform overview, concepts, architecture, and this ecosystem map. | docs.virtufin.com |
| virtufin/virtufin-common | Shared infrastructure: cross-build Docker image, the canonical versions.env convention, shared Directory.Packages.props patterns, and the shared docs assets (mkdocs-base.yml, stylesheets/common.css, javascripts/mermaid-zoom.js) that every docs site pulls in at build time. Hosts all eleven reusable CI workflows: docs-common, docs-lint-common, docker-common, nuget-common, nuget-library-common, worker-nuget-common, execution-worker-nuget-common, pypi-common, npm-common, protos-common, test-parity-common — including the docs-common.yaml workflow that publishes each service's site to GitHub Pages. |
(no docs site) |
| virtufin/virtufin-openspec | The platform's normative specifications: cross-cutting rules (API-mediated pub/sub, CloudEvent envelope), per-service specs (API gateway, worker management, WebSocket proxy, multi-SDK), and operational specs (deployment, CI/CD). Scenario-driven (WHEN/THEN/AND) format. | specs.docs.virtufin.com |
| virtufin/virtufin-dotnet | The .NET 10 library layer: Virtufin.Core (EAV framework, contract traits, DecimalAmount), Virtufin.Base (concrete types: Currency, Cash, Position, Metronome<T>), Virtufin.Data (Variant, FlatBuffers, NATS / WebSocket / Valkey IObservable<T>), Virtufin.Util (time, formatting). The "core" the rest of the platform is built on. |
lib.docs.virtufin.com |
| virtufin/virtufin-api | The API gateway. The single mediator through which services talk to Dapr (pub/sub, state). Hosts Gateway.InvokeJson, MethodSchema, the dynamic ServiceClient proxy used by the IGatewayClient managed adapter. |
api.docs.virtufin.com |
| virtufin/virtufin-workmanager | The WorkManager service. The host process for in-process workers. Implements the DotNetDllEngine (managed, via the embedded CoreCLR bridge) and the NativeDllEngine (AOT, via NativeLibrary.Load). |
workmanager.docs.virtufin.com |
| virtufin/virtufin-websocketmanager | The WebSocketManager service. The proxy for external WebSocket connections (Binance, Alpaca, etc.). Workers talk to it via the API gateway's websocketmanager.* methods (Connect, SendRaw, StartPublish, etc.). |
websocketmanager.docs.virtufin.com |
| virtufin/virtufin-strategy-devkit | The strategy development kit: the IDecide coalgebra bridge and reusable pieces that turn a strategy into a WorkManager worker. Producer half of the decide/execute loop. |
strategy-devkit.docs.virtufin.com |
| virtufin/virtufin-execution-devkit | The execution development kit: bridges an IExecutor into a WorkManager worker. Consumer half of the decide/execute loop. |
execution-devkit.docs.virtufin.com |
| virtufin/virtufin-indicator-devkit | Deploys any IIndicator<TSelf, TSample, TValue> as a standalone WorkManager worker. |
(no docs site) |
| virtufin/virtufin-strategies | Deployable strategy workers built on the IDecide coalgebra and virtufin-strategy-devkit (e.g. moving-average crossover, C# + Python variants). |
strategies.docs.virtufin.com |
| virtufin/virtufin-execution-engines | Deployable executor workers (Simulated / Shadow / Live) built on virtufin-execution-devkit. Consumer half of the decide/execute loop's deployed fleet. |
(no docs site) |
| virtufin/virtufin-market-data-engines | Deployable market-data workers (e.g. a Binance order-book maintainer) — ingest and maintain derived market-data state rather than participating in the decide/execute loop directly. | market-data-engines.docs.virtufin.com |
| virtufin/virtufin-workers | Worker source packages — the WebSocketManagerController is the canonical example. Covers the IGatewayClient abstraction, the build pipeline (managed / native / both), the runtime arch check, the bridge between the WM core and per-worker shims. |
workers.docs.virtufin.com |
| virtufin/virtufin-examples | Worked example workers and clients. The Virtufin.Examples.WebSocketManagerController.NativeAot project is the AOT-portable worker that uses NativeApiGateway.InvokeAsync; the dotnet- and Python-level examples are here too. |
(no docs site) |
| virtufin/virtufin-service | Shared multi-instance coordination library (heartbeat/peer-index, InstanceHeartbeatService) consumed by WorkManager and WebSocketManager for peer discovery and liveness. |
(no docs site) |
| virtufin/virtufin-tui | Operator dashboard: a Textual-based Python terminal UI that connects to a virtufin-api endpoint. |
tui.docs.virtufin.com |
| virtufin/virtufin-app | The platform's web app frontend. Consumes the virtufin-openspec domain spec; ships its own Kubernetes deploy config. |
(no docs site) |
| virtufin/site | The public landing page at www.virtufin.com — a single hand-written static page, no framework or build step. | (this is the site itself) |
| virtufin/helm | The Helm chart that deploys the Virtufin microservices platform with Dapr sidecars on Kubernetes. | (no docs site) |
| virtufin/deploy-local | Runs the Virtufin backend services natively via dapr run for local dev — no Docker containers for the services themselves, only Dapr-managed sidecars. |
(no docs site) |
| virtufin/docker-compose | Deploys the full Virtufin microservices platform (API + WM + WSM + infra) locally via Docker Compose, with its own dev.yaml/prod.yaml profiles and the same env-var convention (VIRTUFIN_DOCKER_*, VIRTUFIN_PACKAGES_*, etc.). |
(no docs site) |
How the sites are built
All the docs sites are built with the same toolchain:
- MkDocs Material with the same theme (indigo palette, dark/light toggle, search, code annotations).
- mkdocs_v1.yml is the canonical config filename (mirroring each service's API version, e.g. v1).
- CNAME at the docs root for the per-service domain (e.g. lib.docs.virtufin.com, api.docs.virtufin.com).
- docs-common.yaml in virtufin-common/.github/workflows/ is the reusable publish workflow — each service's .github/workflows/docs.yaml calls it with its own docs_repo and mkdocs_config.
- docs-lint-common.yaml is the reusable lint workflow for docs PRs.
The same MkDocs Material theme settings are used across every site so a developer can move between them without visual whiplash.