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.

Two setup steps before you write your first runbook:
  1. Pick a data-platform strategy when you create the tenant — Ntropii-managed Postgres or your own warehouse.
  2. Set up a runbook git repo — this is where you and your coding agent will author the Python code.
You only need to do each step once per tenant.

​
1. Pick a data-platform strategy

Every tenant has to declare what data platform it uses at creation time. Three values today:
If you…Pick
Are starting fresh, don’t run a warehouse, or want the simplest pathmanaged-postgres
Already run Snowflake for fund-ops datasnowflake (BYO)
Run Microsoft Fabric and want Ntropii to read from itmicrosoft-fabric (BYO)
The chosen value is stored on the tenant and is the audit answer to “what data platform does this tenant run on?”. It’s required — there’s no implicit default.
One command. Ntropii provisions a per-tenant Postgres database for you; no credentials to register.
ntro tenant create --slug acme-fund --data-platform managed-postgres
The tenant lands in PROVISIONING while the database is being prepared, then flips to ACTIVE. From that point on, runbooks running on this tenant read from and write to its managed database without any further config.
Managed Postgres is per-tenant isolated — each tenant gets its own database, not a shared schema. The data sovereignty model is identical to BYO: financial data stays inside Ntropii Tenant, never enters Ntropii Workspace.

​
Inspect what’s available

Once a binding is in place (managed or BYO), you can ask Ntropii to list the schemas it can see: 
ntro integration discover <integration-id>
This is what your coding agent uses (via MCP) to understand your warehouse layout when generating a runbook.

​
2. Set up a runbook git repo

Runbooks are plain Python files using the ntro SDK. They live in a git repo that you own. Ntropii does not host your runbook source. The reference structure is ntro-runbook-templates: 
your-runbooks/
├── pyproject.toml             # pulls in ntro[workflow]
├── requirements.txt           # locked deps (this is what the worker installs)
├── runbooks/
│   ├── document-ingest/
│   │   ├── templates/
│   │   │   ├── workflow.py    # NtroWorkflow subclass
│   │   │   ├── activities.py  # SDK calls (ai.extract, files.parse, etc.)
│   │   │   ├── models.py      # Pydantic types for inputs/outputs
│   │   │   └── __init__.py
│   │   └── tests/
│   │       └── test_scenarios.py
│   └── nav-monthly/
│       └── templates/...
The requirements.txt contract. When you run ntro workflow push, the CLI uploads your runbook code and its requirements.txt. Ntropii Tenant creates a fresh virtual environment from those exact pinned versions, then registers the workflow with Temporal. Two runbooks pinned to different SDK versions can run side-by-side without conflict.

​
Quick start

# Clone the templates as a starting point
git clone git@github.com:ntropii-com/ntro-runbook-templates.git my-runbooks
cd my-runbooks

# Take stock of what's there
ls runbooks/
# → document-ingest  nav-monthly  nav-monthly-journals

# Test one locally (no deploy required)
ntro workflow test ./runbooks/nav-monthly --scenario happy
If the scenario passes, your environment is set up correctly — the SDK is installed, the test harness works, and you can iterate on the runbook before pushing.

​
CLI configuration

The CLI reads ~/.ntro/config.toml. Run ntro auth login to generate it interactively: 
ntro auth login
# Connection name [local]:
# Host [https://api.ntropii.com/v1]:
# API key: <paste>
# Default tenant: acme-fund
That writes: 
default_connection_name = "local"

[connections.local]
host = "https://api.ntropii.com/v1"
api_key = "ntro_..."
default_tenant = "acme-fund"
Multiple environments (local / staging / production) can coexist as separate [connections.X] blocks. Switch between them with -c: 
ntro -c production tenant list
Override at runtime via env vars: NTRO_HOST, NTRO_API_KEY, NTRO_TENANT, NTRO_DEFAULT_CONNECTION_NAME.

​
What’s next

API keys

How to mint, scope, and rotate the key you just used.

Wire it into a coding agent

Once the env is configured, give your coding agent MCP + CLI access.