Git platforms
Repositories, merge requests and members come from here. Connect with an access token or an OAuth app; self-hosted GitLab works too.
Architecture review on every pull request, on your own servers.
AppArch reads the structure of your codebase - layers, dependencies, contracts - and comments on the pull request the moment it opens. It runs inside your CI and your network. Nothing leaves.
- Installed on-premises
- 9 languages
- GitLab, GitHub, Bitbucket, Azure DevOps
9languages: languages: .NET, Java, Python, Go, TypeScript, Ruby, PHP, Kotlin, Swift
1000+rules: rules in the catalogue, each with a documentation page
4Git platforms: Git platforms
5modules: modules on one code graph
<2 minper review: per review: under 2 minutes, measured on a 5 GB repository
4security frameworks: security frameworks: OWASP, PCI DSS, STIG, CASA
Five modules, one reading of your code
Each module answers a different question about the same repository. Switch on the ones you need; they share the rule catalogue and the dependency graph.
ArchPilot
Review comments on the pull request
- Inline comments with rule code and a link to its documentation
- One summary comment per merge request: new, still open, resolved
ArchScan
A full report for the whole codebase
- Every finding carries the offending lines, not just a file name
- An interactive dependency map of projects and packages
ArchSecurity
Static security analysis mapped to the frameworks auditors ask about
- One report per framework, ready for an audit
- Vulnerable dependencies checked against an offline advisory set
Compliance
Policy checks with a score and an audit trail
- Rules switched on per project, per workspace, or for the whole installation
- Scheduled scans, so the score stays current without anyone remembering to run one
Git Health
29 checks on how the repository is run
- Branch protection, merge request rules, CI security tooling
- Findings carry a value, not just pass or fail
Where to start?
Most teams start with ArchPilot: the first comment arrives on the next pull request.
How a finding reaches your pull request
Three steps, no agent on the developer's machine, nothing that phones home.
- 01
Register the repository
Connect a Git credential in the panel and pick the repository. AppArch issues a project token for it.
- 02
Add one job to your pipeline
One container image per language runs as a CI job on the checked-out code. It fetches the rules, analyses in place and posts only the results.
- 03
Read the comment, open the report
The engineer sees the finding on the pull request; the team sees the score, the trend and the findings in the panel.
Rules are managed in the panel, not in a file
Every rule in the catalogue has a code, a name, a description and a documentation page. Switch a rule off for the whole installation, one workspace or one project; the narrower setting wins.
- The threshold that fails a pipeline is a setting, not a code change.
- Scan scope - which folders count - is set in the same place.
- Every rule has its own documentation page on docs.apparch.io.
Built to run inside your network
There is no hosted version. AppArch is installed on a host you control, and the code it reads never leaves your CI.
Single-host install
Docker Compose with PostgreSQL and Redis. A setup wizard creates the first administrator; upgrades apply their own migrations.
Sign in with your directory
LDAP and Active Directory sign-in, two-factor authentication, invitation by domain. No social login.
Signed licence, offline if needed
The licence is a signed file the installation verifies locally. Air-gapped sites pull images from a private registry and never call out.
No usage data leaves
The only outbound call is the optional update check, and you can switch it off. Everything else stays on your host.
What it connects to
Git platforms bring the repositories and merge requests; the rest add deploys, incidents, issues and AI around them.
CI pipelines
The analyser runs as one job in your own pipeline: ready-made snippets for four providers, a plain docker run for the rest.
Deployment
Which version runs in which environment is written onto the service catalog.
Observability
With Dynatrace, New Relic or Percona PMM connected, incident records flow in, and DORA's two empty metrics, change failure rate and time to restore, fill from real data. Percona PMM also adds database query times.
Quality and testing
SonarQube measurements and findings sit next to AppArch's own; JMeter test summaries land on the project's performance tests page.
AI
The installation's operator connects one provider; requests go from that account and nothing passes through AppArch.
Issue tracking
Findings open as issues on the board your team already uses. Project mapping is configured per workspace.
Sign-in and notifications
People sign in with their LDAP or Active Directory account; notifications go out by e-mail through your own SMTP server. Slack and Teams channels are on the way.
What does an architecture review tool do?
A codebase is hundreds of small decisions that each look right on their own: which layer calls which, when a service contract broke, in which change a security check fell away. Code review sees these decisions but tires over time; nobody writes the same warning by hand on every pull request.
An architecture review tool turns those decisions into rules and applies them to every change automatically. The developer sees the finding on their own pull request, the team lead follows the trend in the panel, and the security team gets the compliance report from the same scan.
How it differs from a linter or a code-quality platform
A linter looks at one file at a time. AppArch reads the dependency graph of the whole repository, so it can say that a presentation project references infrastructure, or that two modules depend on each other. Findings from external scanners appear in the same panel, labelled with their source.
What to look for when choosing one
- Does the code leave your network? A tool that runs on-premises keeps the code inside your own network.
- Who owns the rules? Managing rules in a panel rather than in a file keeps the whole team consistent.
- Does it write on the pull request? Reports go unread; an inline comment gets read.
For details, see the ArchPilot, On-premise & air-gap and rule catalogue pages.
Questions we get asked
How is this different from a linter or SonarQube?
A linter looks at one file. AppArch reads the dependency graph of the whole repository, so it can say that a presentation project references infrastructure, or that two modules depend on each other. SonarQube findings can be mirrored into ArchSecurity next to AppArch's own, labelled by source.
Which languages are supported?
.NET, Java, Python, Go, TypeScript and JavaScript (including React, React Native and Node.js), Ruby, Kotlin, Swift and PHP. Each has its own analyser image and its own part of the rule catalogue.
Does our code leave our network?
No. The analyser runs as a job in your own CI, on the checked-out code, and sends only findings to the AppArch server - which is also yours. There is no hosted service in the path.
What about false positives?
Switch the rule off for the project, the workspace or the whole installation, or narrow the scan scope so the folder is skipped. Findings can also be acknowledged in the panel, and a rule's severity can be lowered so it no longer fails the pipeline.
How is it licensed?
Per installation, with a signed licence file that sets the users and projects; every module is included. There is no per-scan metering and no hosted tier. Contact us and we will size it with you.
How long does installation take?
A single host with Docker: pull the images, run the compose file, walk through the setup wizard. Registering the first repository and adding the CI job is usually the same afternoon.
See it on your own code
Book a thirty-minute demo. We walk through the panel on a real repository and answer the questions your team has.