Skip to main content
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 — on your own GitHub organisation, with your own commit history. Ntropii does not host your runbook source. Two repos to be aware of, with different roles:
RepoWhat it’s for
ntro-runbook-starterThe empty scaffold. Use it once, as the template for your own repo. After bootstrap, your repo lives at your org and is yours to evolve.
runbook-templatesRead-only reference library — nav-monthly, document-ingest, nav-monthly-journals. Look at it; copy patterns from it; don’t commit to it.

​
Bootstrap your repo

1

Create your repo from the starter

On GitHub, open ntropii-com/ntro-runbook-starter and click Use this template → Create a new repository. Pick a name (e.g. acme-runbooks) on your own organisation.
2

Clone your repo locally

git clone git@github.com:your-org/acme-runbooks.git
cd acme-runbooks
You’ll see an empty runbooks/ directory and a README — that’s it. You fill it in.
3

Author a runbook

The fastest path: ask a coding agent (with the Ntro MCP server connected) to scaffold one for you. It reads your tenant + data platform schema, picks a pattern from runbook-templates, and writes the runbook into runbooks/<your-slug>/.Or copy by hand:
# Read-only clone of the reference repo (sibling, not a remote)
git clone git@github.com:ntropii-com/runbook-templates.git ../runbook-templates

cp -r ../runbook-templates/runbooks/nav-monthly runbooks/your-nav-monthly
# then edit templates/{workflow.py,activities.py,models.py} for your tenant
4

Test it

ntro workflow test ./runbooks/your-nav-monthly --scenario happy
Sub-second startup; no deploy, no Docker, no Temporal cluster. If the scenarios pass, your environment is correctly set up.

​
What a runbook looks like

runbooks/
└── your-runbook-slug/
    ├── runbook.md                 # skill definition (see Skill definitions)
    └── templates/
        ├── __init__.py
        ├── workflow.py            # NtroWorkflow subclass
        ├── activities.py          # SDK calls (ai.extract, files.parse, accounting.*, etc.)
        ├── models.py              # Pydantic types for inputs/outputs
        └── requirements.txt       # pinned deps for the worker's per-runbook venv
The requirements.txt contract. When you run ntro workflow create --path, the CLI uploads your runbook directory 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.

​
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.