Deterministic Port Registry

Audience: developers and operators wiring up local environments, hosts files, and service-discovery configuration for Stella Ops.

All Stella Ops web services are assigned deterministic HTTPS/HTTP port pairs to avoid collisions during local development and to simplify service-discovery configuration. This page focuses on deterministic slot/port allocation and may include legacy or unassigned notes; the canonical service inventory is the WebService Catalog. For the layered platform view, see Platform topology.

Port Assignment Scheme

• Formula: Service at slot N → HTTPS = 10000 + N×10, HTTP = 10000 + N×10 + 1
• Range: 10000–10911
• Local alias: Each service additionally binds https://{name}.stella-ops.local (port 443) and http://{name}.stella-ops.local (port 80) — no port in URL

Port Table

Zastava (formerly slot 43, STELLAOPS_ZASTAVA_URL) has been removed: no project exists under src/Zastava/, no STELLAOPS_ZASTAVA_URL env var is defined anywhere, and there is no zastava.stella-ops.local hosts entry. Slot 43 is now occupied by Signals (127.1.0.43), with AdvisoryAI on slot 44 (127.1.0.44) and Unknowns on slot 45 (127.1.0.45), matching the loopback assignments in devops/compose/hosts.stellaops.local and the actual port bindings in devops/compose/docker-compose.stella-services.yml.

Slots 46/47 dev-port note: the deterministic HTTPS/HTTP columns for Workflow Engine and Release Orchestrator follow the slot formula, but in devops/compose these two services publish only port :80 on their dedicated loopback IPs (127.1.0.46, 127.1.0.47) rather than the 104xx dev ports. Release Orchestrator also exposes mTLS on :8443 for the agent-task transport.

Remediation runtime note: src/Remediation/StellaOps.Remediation.WebService is active and binds remediation.stella-ops.local, but no deterministic slot is currently published in this table because compose/router inventory does not yet expose a stable route mapping. Track status in docs/modules/router/webservices-valkey-rollout-matrix.md.

Worker Services

Worker services associated with a web service use ports offset by +2/+3 from the web service slot:

Environment Variable Convention

Each web service has a corresponding STELLAOPS_{SERVICE}_URL environment variable. The Platform service reads these at startup (Layer 1 of the 3-layer configuration) and maps them into ApiBaseUrls for the Angular frontend.

Example: STELLAOPS_SCANNER_URL=https://scanner.stella-ops.local maps to ApiBaseUrls["scanner"].

See also: 3-Layer Service URL Configuration

Friendly Hostnames (.stella-ops.local)

Each service can be reached via https://{name}.stella-ops.local (port 443) and http://{name}.stella-ops.local (port 80) — no port in the URL. The HTTPS/HTTP dev ports (10000+) are bound to localhost only; the .stella-ops.local hostnames use standard ports.

Each hostname resolves to a unique loopback IP (127.1.0.x) so every service can bind ports 443/80 simultaneously without collisions. The entire 127.0.0.0/8 range is loopback on all platforms, so 127.1.0.x addresses work the same as 127.0.0.1.

The Angular UI (ng serve) binds to https://stella-ops.local (port 443 on 127.1.0.1).

At startup each service resolves its hostname to its dedicated loopback IP and binds ports 443/80 on that IP. It logs the result:

• Resolves, ports free: INFO Also accessible at https://{name}.stella-ops.local and http://{name}.stella-ops.local
• Resolves, ports taken: INFO Hostname {name}.stella-ops.local resolves but ports 443/80 are unavailable; use the dev port instead.
• Does not resolve: WARN Hostname {name}.stella-ops.local does not resolve. To enable friendly .stella-ops.local URLs, add hosts-file entries as described in docs/technical/architecture/port-registry.md.

Hosts file setup

Each service gets a unique loopback IP in the 127.1.0.x range so ports 443/80 never collide.

Add the following to your hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on Linux/macOS):

# Stella Ops local development hostnames
# Each service gets a unique loopback IP so all can bind :443/:80 simultaneously.
127.1.0.1  stella-ops.local
127.1.0.2  router.stella-ops.local
127.1.0.3  platform.stella-ops.local
127.1.0.4  authority.stella-ops.local
127.1.0.6  attestor.stella-ops.local
127.1.0.7  evidencelocker.stella-ops.local
127.1.0.8  scanner.stella-ops.local
127.1.0.9  concelier.stella-ops.local
127.1.0.10 excititor.stella-ops.local
127.1.0.11 vexhub.stella-ops.local
127.1.0.12 vexlens.stella-ops.local
# 127.1.0.13 vulnexplorer.stella-ops.local  # MERGED: alias on findings-ledger-web
127.1.0.14 policy-engine.stella-ops.local
127.1.0.14 policy-gateway.stella-ops.local  # alias -> policy-engine (merged)
127.1.0.16 riskengine.stella-ops.local
127.1.0.17 orchestrator.stella-ops.local  # legacy alias (JobEngine WebService retired; see Slot 17)
# 127.1.0.18 taskrunner.stella-ops.local  # REMOVED
127.1.0.19 scheduler.stella-ops.local
127.1.0.20 graph.stella-ops.local
# 127.1.0.21 cartographer.stella-ops.local  # RETIRED: merged into graph-api (alias on 127.1.0.20)
127.1.0.20 cartographer.stella-ops.local
127.1.0.22 reachgraph.stella-ops.local
127.1.0.23 timelineindexer.stella-ops.local
127.1.0.24 timeline.stella-ops.local
127.1.0.25 findings.stella-ops.local
127.1.0.26 doctor.stella-ops.local
127.1.0.27 opsmemory.stella-ops.local
127.1.0.28 notifier.stella-ops.local
127.1.0.29 notify.stella-ops.local
127.1.0.30 signer.stella-ops.local
127.1.0.31 smremote.stella-ops.local
127.1.0.32 airgap-controller.stella-ops.local
127.1.0.33 airgap-time.stella-ops.local
127.1.0.34 packsregistry.stella-ops.local
127.1.0.35 registry-token.stella-ops.local
127.1.0.36 binaryindex.stella-ops.local
127.1.0.37 issuerdirectory.stella-ops.local
127.1.0.38 symbols.stella-ops.local
127.1.0.39 sbomservice.stella-ops.local
127.1.0.40 exportcenter.stella-ops.local
127.1.0.41 replay.stella-ops.local
127.1.0.42 integrations.stella-ops.local
127.1.0.43 signals.stella-ops.local
127.1.0.44 advisoryai.stella-ops.local
127.1.0.45 unknowns.stella-ops.local
127.1.0.46 workflow.stella-ops.local
127.1.0.47 release-orchestrator.stella-ops.local

# Stella Ops infrastructure (local dev containers)
127.1.1.1  db.stella-ops.local
127.1.1.2  cache.stella-ops.local
127.1.1.3  s3.stella-ops.local
127.1.1.4  rekor.stella-ops.local
127.1.1.5  registry.stella-ops.local
127.1.1.6  harbor-fixture.stella-ops.local
127.1.1.7  github-app-fixture.stella-ops.local
127.1.1.8  advisory-fixture.stella-ops.local

# Stella Ops third-party integration services (overlay compose files)
127.1.2.1  gitea.stella-ops.local
127.1.2.2  jenkins.stella-ops.local
127.1.2.3  nexus.stella-ops.local
127.1.2.4  vault.stella-ops.local
127.1.2.5  oci-registry.stella-ops.local
127.1.2.6  minio.stella-ops.local
127.1.2.7  gitlab.stella-ops.local

Infrastructure services

Infrastructure containers (databases, caches, object storage, transparency logs) use a separate loopback range (127.1.1.x) to avoid collisions with application services.

Image versions are digest-pinned via env vars in devops/compose/.env (POSTGRES_IMAGE=postgres:18.1, VALKEY_IMAGE=valkey/valkey:9.0.1, RUSTFS_IMAGE=chrislusf/seaweedfs:latest, REKOR_TILES_IMAGE=ghcr.io/sigstore/rekor-tiles:latest); override for production with audited digests. The fixture containers (127.1.1.6–127.1.1.8) are defined in devops/compose/docker-compose.integration-fixtures.yml and only run during integration-test overlays.

Third-party integration services (127.1.2.x)

Optional third-party services used by integration/e2e overlay compose files (docker-compose.integrations.yml, docker-compose.e2e-analyzer-coverage.yml) use the 127.1.2.x loopback range: