Search docs

Docs search

Supported Stacks

ArchPilot Smart Init and architecture validation work across common backend, frontend, library, and repository patterns using deterministic local detection.

Why it matters

Use this page to understand what ArchPilot can detect today and where Smart Init can help teams model architecture faster.

Backend stack coverage

  • Node.js / TypeScript
  • Express.js
  • NestJS
  • Java
  • Spring / Spring Boot
  • Kotlin
  • FastAPI
  • Django
  • Flask
  • Python
  • PHP
  • Laravel
  • Go
  • .NET
  • Ruby on Rails

Frontend stack coverage

  • React
  • Next.js
  • Angular
  • Vue

Library stack coverage

  • Node.js / TypeScript
  • Python
  • Go
  • Kotlin

Infrastructure stack coverage

  • Terraform
  • Ansible

Framework-aware defaults

  • Node.js / TypeScript, Express.js, NestJS, React, Next.js, Angular, and Vue support includes deterministic manifest/dependency detection, practical import extraction, module-root defaults, and framework-aware source layout defaults.
  • Java, Spring / Spring Boot, Kotlin, .NET, Go, PHP, Laravel, Python, FastAPI, Django, Flask, and Ruby on Rails support includes deterministic framework or language evidence, repository and module discovery defaults, and architecture validation coverage where local evidence is high confidence.
  • Terraform and Ansible repositories are detected as infrastructure context so Smart Init can model infrastructure units and use infrastructure-aware source and module defaults.

Python framework detection

These detections stay local, deterministic, and evidence-based. ArchPilot does not rely on deep semantic framework parsing to propose the initial architecture context.

  • FastAPI detection uses dependency markers, imports, route patterns, and practical repository evidence.
  • Django detection uses django dependency markers, manage.py, settings.py, common Django project layout, and practical repository evidence.
  • Flask detection uses flask dependency markers, from flask import Flask, app = Flask(__name__), route decorators, and practical repository evidence.

Repository and project patterns

  • Repositories with one component
  • Monorepos with apps, packages, libraries, or services
  • Mixed frontend, backend, shared-library, worker, and infrastructure repositories
  • Backend and frontend multi-project repositories
  • Repository layouts with feature or module-style folders

How to interpret support

Support here means ArchPilot detects and maps common project structures, extracts practical source import evidence where available, proposes architecture-aware defaults, and runs deterministic validation against explicit repository and dependency evidence.

Validation focuses on high-confidence repository and dependency evidence. Different stacks expose different signals, so rule depth can vary by architecture category, but the local workflow remains deterministic and reviewable.

Stack and framework detection, architecture-unit discovery, and dependency analysis are separate concepts. A repository can use a recognized stack while dependency analysis is still Partial or Not established because the available architecture and dependency evidence differs between repositories.

Dependency analysis depth

Established dependency analysis means ArchPilot found enough reliable source/import/module evidence to map meaningful dependency relationships.

Partial dependency analysis means the graph and findings can still be useful, but dependency coverage is incomplete. It does not mean partial compliance.

Not established means ArchPilot could not establish dependable dependency conclusions from available evidence. It does not mean there are no dependencies.

Supported Stacks | ArchPilot Docs