Navo

Continuous deployment

Locked-down continuous deployment of Navo

Keep architecture maps current and serve them from a private Kubernetes perimeter. After a PR merges, a release pipeline runs the Navo CLI, commits YAML back to Git, and Argo CD or Flux rolls a locked-down Navo browser — so IaC, applications, and systems deployments stay honest without public exposure.

Open interactive mapPipeline setup docs

End-to-end flow

PR merged → pipeline → CLI → Git → GitOps → Navo

Step 1

PR merged

Human change lands on main

Application, IaC, or systems-deployment code merges through normal review. That commit is the trigger — not a manual diagram refresh.

  • Pull request #482
  • main @ a1b2c3d

Step 2

Release pipeline executes

CI agent checks out the repo

Azure Pipelines, GitHub Actions, or Jenkins starts the post-merge job: install toolchain, build or fetch the navo binary, prepare workspaces for each map type.

  • Job: navo-map-refresh
  • Agent: linux-x64

Step 3

Navo CLI scans & writes YAML

App · IaC · systems trees → ArchitectureMap

navo scan walks application services, infrastructure as code, and deployment trees (or navo convert for diagrams). Output lands under config/systems/*.yaml. validate:config fails the job on bad topology.

  • navo scan ./apps → app-stack.yaml
  • navo scan ./infra → iac-platform.yaml
  • pnpm run validate:config ✓

Step 4

Commit YAML back to the repo

Git stays the system of record

If maps changed, the bot commits architecture YAML to the mainline branch (or opens a bot PR). No parallel CMDB — the map is just another reviewed Git artifact.

  • commit: "chore(navo): refresh architecture maps"
  • paths: config/systems/*.yaml

Step 5

Argo CD or Flux reads main

GitOps reconciles desired state

Argo CD Application or Flux Kustomization watches the mainline branch. A new commit (YAML and/or SPA image tag) triggers reconcile — no kubectl apply by hand.

  • Application: navo-browser
  • source: main
  • sync: automated

Step 6

Locked-down Navo in Kubernetes

Private SPA serves the updated maps

The in-cluster Navo image rebuilds or mounts compiled config. NetworkPolicy, private Service, non-root, read-only root FS — confidential architecture maps stay inside the perimeter.

  • Deployment/navo
  • Service: ClusterIP only
  • NetworkPolicy: deny-ingress-public
Explore this flow as a 2D/3D map

What continuous deployment keeps current

One post-merge job can refresh multiple ArchitectureMap files — then GitOps deploys Navo with only those Git-backed maps.

Locked-down Navo on Kubernetes

Architecture maps are often confidential. The pipeline updates Git; GitOps deploys a private SPA — not a public SaaS rewrite of your CMDB.

  • ClusterIP (or internal ingress) only — no public map by default
  • NetworkPolicy deny-by-default; allow VPN / private mesh clients
  • Non-root container, read-only root filesystem, drop capabilities
  • Image built in CI with compile:config from the same Git commit
  • Argo CD / Flux automated sync with prune; manual sync for regulated envs

Trust model

Git (main)

apps/   infra/   config/systems/

▲ bot commit (YAML)

watch

Argo CD / Flux

reconcile

Deployment/navo

Service: ClusterIP

NetworkPolicy: lock

SPA + compiled maps

Humans merge product PRs. Bots refresh maps. GitOps deploys. Navo only serves what Git already accepted — inside the cluster perimeter.

Pipeline sketch

Minimal post-merge job

Full Azure Pipelines example, multi-map scan patterns, and GitOps notes live in the docs guide. Explore the same topology as an interactive graph demo.

# After merge to main
make -C navo-cli/navo-cli build
NAVO=./navo-cli/navo-cli/bin/navo

$NAVO scan ./apps  -o navo/config/systems/app-stack.yaml \
  --id app-stack --title "Application stack"
$NAVO scan ./infra -o navo/config/systems/iac-platform.yaml \
  --id iac-platform --title "IaC platform"

cd navo && pnpm install --frozen-lockfile \
  && pnpm run validate:config

git add navo/config/systems
git diff --cached --quiet || \
  git commit -m "chore(navo): pipeline map refresh" && git push
# → Argo CD / Flux sees main → updates locked-down Navo in cluster
Interactive pipeline mapFull pipeline how-toOperator CLI reference

FAQ

Continuous deployment questions

Straight answers about CI/CD pipeline integration, GitOps delivery, and locked-down Kubernetes deployments.

What triggers a Navo map refresh in CI/CD?

A merged pull request. The post-merge job checks out the repo, runs navo scan on application and infrastructure trees, validates the output with pnpm run validate:config, and commits updated YAML back to the default branch. No manual diagram editing is required.

Does Navo require Argo CD or Flux?

No. Argo CD and Flux are the recommended GitOps controllers, but any tool that watches a Git branch and reconciles Kubernetes state will work. You can also deploy Navo manually with kubectl apply or Helm — the CLI and YAML workflow is independent of the delivery method.

Can Navo run inside a private Kubernetes cluster without public exposure?

Yes. The recommended deployment uses ClusterIP (or internal ingress) only, NetworkPolicy deny-by-default with VPN or private mesh access, a non-root container with read-only root filesystem and dropped capabilities, and an image built in CI from the same Git commit. Architecture maps stay inside the cluster perimeter.

What is the difference between navo scan and navo convert?

navo scan walks a codebase using Tree-sitter AST parsing (Go, TypeScript, C#, Python) and emits an ArchitectureMap YAML from the code structure. navo convert imports an existing diagram file — Lucidchart JSON, draw.io XML, or Mermaid markdown — and translates it into the same YAML schema. Use scan for code-first maps and convert for diagram-first maps.

How does the bot commit pattern work?

After the CLI scans and validates, the pipeline checks git diff --cached --quiet. If YAML changed, it commits with a message like chore(navo): pipeline map refresh and pushes to the default branch. If nothing changed, the job exits cleanly. The bot commit triggers GitOps reconciliation, so the deployed Navo SPA always reflects the latest architecture.

Can I use Navo with GitHub Actions, Azure Pipelines, or Jenkins?

Yes. The Navo CLI is a single Go binary that runs on any Linux, macOS, or Windows CI agent. Install it with make build or download a release binary, then call navo scan and navo convert in your pipeline script. The docs include a ready-to-use Azure Pipelines example and the same pattern applies to GitHub Actions, Jenkins, GitLab CI, or any other runner.

Keep architecture living next to code

Reduce architecture drift and meetings. Unlimited viewers free. Community includes MCP, AI YAML, and Git as source of truth.

Try live demoGet product updates