Evaluate with Compose

Run the full multi-service inndx topology locally with Docker Compose to see its real distributed shape.

Dev mode runs every stage in one process. In production, inndx runs as separate services that communicate through external infrastructure: a relational database, blob storage, a cache, a service registry, and a message broker. Docker Compose lets you stand up that real shape on one machine so you can evaluate it end to end before committing to a Kubernetes deployment.

Evaluation, not production

The Compose setup wires up convenient local defaults, including throwaway credentials, so you can try the distributed topology quickly. It is not a production deployment and its default credentials must never be reused. For a supported production install, follow the Kubernetes guide in your onboarding materials.

What gets started

The Compose files under deploy/compose/ bring up the inndx services alongside the infrastructure they depend on:

The five services (orchestrator, fetcher, parser, sink, analytics), each as its own container with its own port.
PostgreSQL as the relational database.
RustFS as S3-compatible blob storage for raw assets and results.
Dragonfly as a Redis-compatible cache and service registry.
Kafka as the message broker that carries events between services.

Each service is configured through INNDX__… environment variables. For example INNDX__BROKER__KIND: kafka selects the Kafka broker and INNDX__DATABASE__PRIMARY points at PostgreSQL. The mapping between these variables and the configuration sections is described in Reference, Configuration.

Start the topology

From the repository root, bring up the infrastructure and the services together:

docker compose \
  -f deploy/compose/postgres.yml \
  -f deploy/compose/dragonfly.yml \
  -f deploy/compose/rustfs.yml \
  -f deploy/compose/kafka.yml \
  -f deploy/compose/inndx.yml \
  up

The orchestrator applies database migrations on startup (it is launched with the --migrations flag), then each service registers itself and begins consuming events.

Verify it is running

The orchestrator API is published on port 8022 in this setup. Its live API reference confirms the service is up:

http://localhost:8022/.well-known/docs

The fetcher, parser, sink, and analytics are published on their own ports (8023, 8024, 8025, 8026). See Reference, Images for the difference between the inndx and inndx-browsers image variants.

Create a crawl job

Creating and running jobs works exactly as in Run the server, except you target the orchestrator on port 8022:

curl -X POST http://localhost:8022/crawl_jobs \
  -H 'content-type: application/json' \
  -d @first-crawl.json

Because the services are now decoupled through Kafka and share PostgreSQL and RustFS, you are exercising the same architecture used in production, just packed onto one host.

Tear down

docker compose -f deploy/compose/inndx.yml down

You have now seen inndx run as a single command, as a single-process server, and as a distributed topology. To understand how those pieces fit together and how they scale, read the Concepts section. When you are ready to deploy for real, your onboarding materials cover the supported Kubernetes install.