Quick start

This page gets you from “CLI installed” to a running two-Component System on your machine. It is the first stop on the tutorial path: run the generated shape once, then build a Component pipeline in the transactional integration tutorial.

What you’ll build

Two Components and the System that joins them: an extractor that sweeps a source folder and publishes each order to a Topic, and a loader that subscribes to the Topic and writes each order to a destination folder. The system host runs the whole thing locally: real Components, a real broker, mocked platform services.

FIG Q1One extractor, one Topic, one loader: a Distribution shape with a single destination, run locally by the system host.

Your code External touchpoint Infrastructure, not your code

What you learn

• intropy int create scaffolds Components from templates.
• intropy sys create assembles those Components into a system host.
• A local run uses real Components and broker plumbing, with folders standing in for external systems.

Before you begin

• The CLI is installed, along with .NET 10 SDK, Docker (running), and Dapr CLI 1.16 (dapr init done)
• A scratch directory you don’t mind throwing away; every command below runs from its root

Steps

1. Scaffold the components

intropy int create extractor -n OrderExtractor -o order-extractor \
  -s organization=Fluxia -s topic=orders -s contract=Order -s empty=false

intropy int create loader -n OrderLoader -o order-loader \
  -s organization=Fluxia -s topic=orders -s contract=Order -s empty=false

fetching integrio-intropy/intropy-templates@v0.4.1
created order-extractor from integrio-intropy/intropy-templates@v0.4.1 (template extractor)
created dependency Contracts from template shared-contracts

intropy int create renders a template into a project. -n names the .NET project and -o the directory it lands in. The two Components share a message model and a Topic, so the -s pairs topic=orders and contract=Order must be spelled the same in both commands: the extractor publishes Order messages on orders, the loader consumes them. empty=false keeps working sample logic in the pipeline steps so there’s something to watch run.

The first scaffold also created Contracts/, a shared class library holding the Order record both Components reference; the second found it already there and left it alone. Each project carries a .intropy/scaffold.json record of how it was made. Commit those; the next command reads them.

2. Create the system

intropy sys create -n OrderFlow

created order-flow from integrio-intropy/intropy-templates@v0.4.1 (template system-host)
assembled system "order-flow": 2 component(s), 1 topic(s), 2 port(s), contracts from Contracts

intropy sys create reads before it writes: it scanned the workspace’s scaffold records, assembled them into a system model, and rendered order-flow/, the system host. Open order-flow/OrderFlowSystem.cs. The whole System is one typed declaration:

order-flow/OrderFlowSystem.cs (excerpt)

builder.AddExtractor("order-extractor")
    .From(Ports.OrderExtractorSource)
    .Publishes(Topics.Orders)
    .Uses(Services.Idempotency)
    .Uses(Services.BusinessIncidents);
builder.AddLoader("order-loader")
    .Subscribes(Topics.Orders)
    .To(Ports.OrderLoaderDestination)
    .Uses(Services.Idempotency)
    .Uses(Services.BusinessIncidents);

Systems and topology explains what this declaration is; The system host lists everything it can do. For now, one consequence matters: the host can run the System.

3. Drop an order in

The host’s development definition resolves each port to a local folder under order-flow/test/. The Extractor is a run-to-completion job (it sweeps its source folder once at host start), so seed the folder before running:

cd order-flow
mkdir -p test/order-extractor-source
cp sample-data/sample-order.json test/order-extractor-source/

The scaffold ships the sample order (task seed wraps these two commands if you have Task installed):

order-flow/sample-data/sample-order.json

{
  "orderId": "ORD-1001",
  "customerId": "CUST-42",
  "orderDate": "2026-05-13T09:30:00Z",
  "lines": [
    { "sku": "SKU-AAA", "quantity": 2, "unitPrice": 19.95 },
    { "sku": "SKU-BBB", "quantity": 1, "unitPrice": 49.00 }
  ]
}

4. Run it

Still in order-flow/:

dotnet run

The host translates the topology into Aspire resources: both Components as processes, a Dapr sidecar each, a Redis-backed broker, and the two platform services as OpenAPI mocks. Wait for the dashboard line and open the login URL it prints:

Login to the dashboard at http://localhost:15170/login?t=<token>

The Aspire dashboard shows every resource, its console logs, and the distributed traces of your run. One host at a time: the dashboard ports are fixed, so stop a previous dotnet run (Ctrl+C) before starting another.

5. Inspect the result

Within a few seconds of the components starting, the Extractor sweeps the seeded file, publishes it to orders, and the Loader writes the transformed order to its destination folder:

cat test/order-loader-destination/ORD-1001.json

{"OrderId":"ORD-1001","CustomerId":"CUST-42","LoadedAt":"2026-08-13T04:14:06.650734+00:00","Status":"Loaded"}

The source file is gone — swept — and the destination holds the Loader’s output: the inbound order was deserialized, validated, transformed into the destination’s shape, and written through the port. To send it through again, stop the host, reseed (step 3), and dotnet run. Or explore the trace of the run you just made in the dashboard first.

That is the build step of Build, connect, deploy: declare the System, run it locally, watch real messages move. Continue with the transactional integration tutorial to build the pipeline inside a Component step by step. Use First deploy when the same System is ready to leave the local run.