Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.ntropii.com/llms.txt

Use this file to discover all available pages before exploring further.

Once your runbook passes local tests, shipping it is two moves:
  1. Push — upload a runbook artifact to Ntropii Workspace. This stores the version but does not run anything.
  2. Deploy — copy the version to Ntropii Tenant, where it can actually execute against the data plane.
Both steps are available via the CLI (for humans) and via MCP (for coding agents). Pick whichever fits the situation.

​
Prerequisites

​
Push a version

A “version” is a packaged runbook — the source tree plus a requirements.txt describing exactly which dependencies the worker should install alongside it. 
# Build a zip of the runbook directory
cd runbooks/nav-monthly
zip -r ../../nav-monthly-v0.2.0.zip .
cd -

# Push to Workspace
ntro workflow push <workflow-id> ./nav-monthly-v0.2.0.zip
# → Created version v_abc123
The CLI uploads the zip, and Workspace records a new version record. Nothing has run anywhere yet — the version just exists in the registry.

​
The requirements.txt contract

When Workspace receives the artifact, the receiving Ntropii Tenant later creates a fresh virtual environment from the artifact’s requirements.txt and installs exactly those pinned versions. Two runbooks pinned to different SDK versions can run side-by-side without conflict. This means:
  • Pin everything that matters. ntro==1.4.2, not ntro or ntro>=1.4. Pinning is what makes the runbook reproducible six months from now.
  • Pin the SDK extras. If the runbook uses ntro.workflow, pin ntro[workflow]==1.4.2.
  • Don’t pin development-only deps. pytest and friends belong in a separate dev requirements file the worker doesn’t see.
The runbook templates ship a working requirements.txt you can lift as a starting point.

​
Deploy a version to a tenant

Pushing a version doesn’t activate it. To make a version executable for a tenant, deploy it: 
ntro workflow deploy \
  --workflow <workflow-id> \
  --version <version-id> \
  --tenant acme-fund-admin
The CLI returns a deployment ID. The deploy is asynchronous — Ntropii Tenant copies the artifact, builds the venv, registers the workflow with Temporal, and reports back.Poll for status:
ntro workflow deploy-status <deployment-id>
# → status: deploying  (creating venv)
# → status: deploying  (registering with Temporal)
# → status: ready

​
Versioning and rollback

Multiple versions of the same workflow can coexist in Workspace. Only one version is “active” per tenant at a time — the most recent successful deploy. Rollback is just a deploy of the previous version: 
ntro workflow deploy \
  --workflow <workflow-id> \
  --version <previous-version-id> \
  --tenant acme-fund-admin
Ntropii Tenant tears down the new venv (after any in-flight runs complete) and brings up the old one. Active runs aren’t killed mid-flight.

​
Triggering a run after deploy

Deploy makes a version available. To actually execute it, trigger a run: 
ntro workflow run nav-monthly \
  --tenant acme-fund-admin \
  --entity acme-spv1 \
  --period 2026-03
workflow run returns a task ID. Use ntro run status to follow it, or watch in the Tenant UI. A coding agent can do the same via the ntro_workflow_run MCP tool.

​
A typical first deploy

1

Test locally

ntro workflow test ./runbooks/nav-monthly --child ... --child ... — confirm HAPPY and REJECT_ALL both pass.
2

Register the workflow if it's new

ntro workflow create --name nav-monthly --description "..." --schedule "0 8 5 * *" --timezone Europe/London
3

Push the artifact

zip -r nav-monthly.zip . then ntro workflow push <workflow-id> ./nav-monthly.zip. Note the version ID.
4

Deploy to one tenant

ntro workflow deploy --workflow <id> --version <version-id> --tenant <staging-tenant>. Poll deploy-status until ready.
5

Trigger a smoke run

ntro workflow run nav-monthly --tenant <staging-tenant> --entity <test-entity> --period 2026-03 --wait. The --wait flag polls until the run completes.
6

Promote to production tenants

Once the staging deploy proved healthy, deploy the same version to your production tenants. Same ntro workflow deploy command, different --tenant.

​
What’s deferred

Two pieces of the Notion plan’s “Deploy & Run” section are not in this version of the docs:
  • Observer & diagnostics — the in-flight monitoring and exception handling that watches running workflows for anomalies. The system exists; the docs are still being written.
  • Private infrastructure — guidance on deploying Ntropii Tenant on your own AKS / Vercel / etc. for data sovereignty.
Both join the docs when their underlying systems harden enough to be customer-documented.

Testing locally

Catch regressions before they ship.

Run inspection

ntro run status and friends — track what’s running and what’s pending.