DrToller

Positioning

What problem does Platform solve?

DrToller.Platform is the OSS deploy layer forDrToller.Framework. It wires the hosts a DRTML runtime needs — Postgres, MinIO, Redis, Qdrant, Ray, Airflow, Grafana, Prometheus, Streamlit — and gives operators one CLI to bring that surface up, verify it, and update it.

The deploy stack that hosts a DRTML runtime.

Developer preview · August 2026. This page explains abstraction layers, not product rankings. These pieces often coexist in one installation.

The problem

A DRTML runtime still needs physical hosts: an object store, a database, a scheduler, a metrics stack, and a compute transport. Assembling those by hand leaves migrate order, dashboard provisioning, secrets, and health checks in a private runbook — and usually leaks host details into step packages.

Platform separates deploy wiring from the execution contract(Framework) and from domain steps (Edge / Ops).

The abstraction

Traditional stacking

Step code
      ↓
Airflow DAG + Ray calls
      ↓
Compose YAML + shell
      ↓
Grafana JSON in git
      ↓
Postgres / MinIO

DrToller

Domain steps (Edge / Ops)
      ↓
DRTML execution contract
      ↓
DrToller.Framework
      ↓
DrToller.Platform
  ├── compose hosts
  ├── operator CLI
  ├── Postgres bootstrap
  └── Grafana / DDL codegen

Purpose: keep domain logic and the execution contract independent of how the hosts are installed.

How the abstraction differs

Not “Platform versus Airflow.” Different questions — often answered together.

DIY Docker Compose

How do I start Airflow, Ray, Grafana, MinIO, and Postgres on one host?

Ad-hoc service wiring

Kubernetes ML platforms

How do I run notebooks, jobs, and serving on a cluster?

Cluster product / control plane

Airflow · Prefect · Dagster

When should this workload run, and what depends on what?

Scheduling host — Platform wires Airflow; it is not the product

DrToller.Framework

What is this data/ML workload as a typed contract, and how should that contract execute?

Runtime: DRTML, storage, processing, telemetry

DrToller.Platform

Where does that runtime actually run, and how does an operator bring the hosts up?

Deploy stack, operator CLI, host wiring, deploy-time codegen

Layer detail

Ad-hoc wiring

DIY Docker Compose

DIY Compose answers: which containers should start on this VM?
Platform answers: which host surface does a DRTML runtime need, in what order, with which env contract, migrate, and health checks?

You can start the same images yourself. Platform is the opinionated bring-up:drtoller up pulls, migrates Postgres, inits MinIO buckets, syncs Grafana, and drtoller verify checks the result.

Cluster products

Kubernetes ML platforms

Cluster products own notebooks, job CRDs, and serving on Kubernetes. Platform’s default is Compose on a VM. Multi-host compute is an attach: KubeRay on an existing DOKS cluster via drtoller cloud bootstrap — not a replacement control plane.

AWS/EKS and GCP/GKE installers are backlog. We do not claim a general-purpose ML platform.

Scheduling host

Airflow

In Platform, Airflow is a supported host — complement, not a competitor. Thin DAG wrappers pass step_id and params into Framework. Streamlit is the same idea for interactive launch.

Airflow still answers when to run. DRTML still answers what the workload is.

Runtime

DrToller.Framework

Framework is the execution contract: parse, validate, compile, storage, parallelism, metrics emit. Platform does not reimplement that layer.

DRTML
   ↓
Framework
   ↓
Platform hosts (today)

Operator docs for the stack live with Framework deploy pages so the runtime contract and the host wiring stay one reference — this site has no separate docs tree.

What to evaluate

Host surface, not a runtime

Platform does not compile DRTML or emit Prometheus series. It starts the services Framework talks to, and the CLI that keeps them consistent.

Steps stay outside

Edge and Ops are mounted via DRTOLLER_HOME / STEPS_ROOTS. The stack does not bundle domain processors or spaCy pipelines.

One operator contract

up / down / verify / update / env replace a private runbook of compose flags, migrate order, and dashboard copy-paste.

Codegen at deploy time

Grafana JSON and Postgres DDL are generated from DRTML on up/update. Hand-maintained dashboard files are not the source of truth.

What Platform does not own

Step processors, registry plugins, spaCy parsing — step packages only. Runtime metric emit, partition loop, storage session — Framework only. Hand-maintained Grafana JSON in git — dashboards are generated from DRTML.

Domain logic          Edge / Ops
DRTML / execution     Framework
Hosts / CLI / env     Platform

Next

Product overviewGitHubDeploy overview