CLI
Every inndx command-line subcommand and what it does.
The inndx binary is the entry point for every deployment mode and operational task. This page documents each subcommand. It describes what the binary can do; for deployment procedures that use these commands, see your onboarding materials.
This is a different program from crawlctl: inndx starts and operates the services themselves (or, with run, executes a single crawl manifest in one process with no services at all), while crawlctl is a client that talks to a deployment's services over the network to manage jobs, runs, and the other resources it exposes.
Every subcommand reads the same configuration (see Configuration). The global --config-file flag, available on all subcommands, points at a configuration file:
| Flag | Environment | Description |
|---|---|---|
--config-file, -c | INNDX_CONFIG_FILE | Path to a configuration file. |
Running services
Each service runs with its own subcommand: orchestrator, fetcher, parser, sink, and analytics. The dev subcommand runs all of them together in a single process for evaluation and local testing.
inndx orchestrator
inndx fetcher
inndx parser
inndx sink
inndx analyticsThese subcommands, and dev, share the same flags:
| Flag | Environment | Default | Description |
|---|---|---|---|
--host | INNDX_HOST | 0.0.0.0 | The host the service's HTTP server binds to. Same as server.host. |
--port | INNDX_PORT | 8022 | The port the service's HTTP server binds to. Same as server.port. |
--no-migrations | INNDX_NO_MIGRATIONS | false | Start without applying pending database migrations. |
inndx dev --port 8022Running a single job
The run subcommand executes one crawl job from a manifest file in a single process, without standing up a long-running server. It is the quickest way to try a manifest.
inndx run my-crawl.yml| Argument or flag | Environment | Description |
|---|---|---|
<file path> | none | Path to the crawl manifest file (YAML or JSON). Required. |
--tenant-id, -t | none | The tenant to run the job under. Defaults to the configured default tenant. |
--no-migrations | INNDX_NO_MIGRATIONS | Run without applying pending database migrations. |
Database migrations
The migrate subcommand applies any pending database migrations and exits. Run it before starting services against a new or upgraded database.
inndx migrateIt takes no subcommand-specific flags beyond the global --config-file.
Inspecting configuration
The config subcommand prints the fully resolved configuration (defaults merged with the config file and environment variables) and exits. Use it to confirm what a service will actually use.
inndx config| Flag | Description |
|---|---|
--format, -f | The output format: debug (the default), json, or yaml. |
Global flags and environment
Beyond --config-file, every setting can be overridden with an environment variable using the INNDX__SECTION__FIELD convention (double underscores separate nesting levels). For example, INNDX__SERVER__PORT=8022 sets the server port. Settings resolve as built-in defaults, then the configuration file, then environment variables, with later layers overriding earlier ones. The full set of settings, their environment-variable names, and how this precedence works is documented in Configuration.