Product
Archito NewLearns from your merge requests and flags what is stuck Integrations 25
Solutions
By role
Why AppArch
Resources
Customers Pricing Contact
Language
Contact us

Everything stays inside the perimeter: code, panel, findings.

For regulated sectors and closed networks: the panel, the analysis and the database run on your own servers. Only two doors open outward - the image registry and the licence file; in an air-gapped install both can be carried inside.

One product, one release line

Every installation runs the same images, versioned by a single tag. No fork, no lagging edition.

Every module included

All modules, from ArchPilot to Archito, run on your servers. Every feature reaches every installation in the same images.

Management console included

The install has its own management area: licence, users and e-mail settings in one place, with a first-boot wizard walking you through setup.

Identity and AI

There is no Google or GitHub sign-in: identity stays inside your perimeter, with e-mail and password or LDAP / Active Directory. AI features are optional and only they need internet access, to the provider your operator chooses.

What runs in the installation?

The reference install is four containers on one server. The analysis runs not on that server but inside your CI jobs.

Component What it does Who reaches it
Panel (app-ui) The web interface your users open. It passes every request on to the API under the user's own identity. Browsers; default port 8080
API (api) Takes in analysis reports, computes the scores and runs scheduled work such as Git sync and reports. It is the only component that talks to the database. The panel and your CI runners; default port 5000
PostgreSQL 16 Findings, reports, users and management settings. The API only
Redis 7 Sessions, cache and the session keys replicas share. The panel and the API
Analysis images (collectors) Scan the code in your CI job and send the report to your own API. One image for each of the nine languages. Your CI jobs; nothing runs on the server permanently

TLS is provided by the reverse proxy (nginx, traefik) or ingress in front. Browsers only need the panel port, CI runners only the API port.

Installation is three steps

Kubernetes is not required; Docker compose is enough. The guide, with screenshots, lives on docs.apparch.io.

  1. 01

    Licence + installation key

    Sales sends your installation ID and installation key; the key is transmitted exactly once. On first boot the installation collects its licence online. Air-gapped: you send the installation code shown by the setup wizard and receive a .lic file bound to it.

  2. 02

    Pull the images

    docker login hub.apparch.io - the installation ID is the username, the key is the password. On an air-gapped network the images are pulled once outside and carried in.

  3. 03

    compose up + wizard

    The compose file brings up the panel, the analysis and the database migrations; on first boot the setup wizard wires the admin account and the licence.

Requirement: Docker Engine 24+ with the compose plugin. That is all.

Installing on an air-gapped network

Neither installing nor running needs a connection out of your network. The only exchange with the outside is two files carried by hand.

  1. 01

    Bring the images in

    The panel and API images are delivered as a single archive file; you carry it to the server and load it with docker load. The analysis images go into your own internal registry, and your CI jobs pull them from there.

  2. 02

    Generate the secrets on the server

    gen-secrets.sh creates the database and Redis passwords, the session signing key and the encryption master key at random on the server itself. None of them reaches us, and none is in the images.

  3. 03

    Send the installation code

    Start the services and send AppArch the installation code shown in the setup wizard's licence step. The .lic file you get back is bound to this installation only; place it at ./license/apparch.lic or paste it into the wizard.

  4. 04

    No request goes out

    Leave the vendor and update addresses empty: the licence is verified locally, no version check is made and no request leaves the network. New releases arrive as files too.

Simple to run, clear to watch

What your team needs to know after the install, in four headings.

Health endpoints

/health/live says the process is up, /health/ready that the database and Redis answer (for the panel: the API). Compose uses them as container healthchecks; on Kubernetes they back the liveness and readiness probes.

Upgrades

Change the image version in .env, then docker compose pull and up. Pending database migrations run at startup, in order, however many releases you skipped. Migrations only move forward, so take a pg_dump backup first.

A boot that explains itself

The API logs its startup step by step: database, migrations, reference data, licence. If a step fails, the error line names the step it stopped at; a connection failure shows host and port, never credentials.

More than one replica

Replicas that share the same PostgreSQL and Redis are one installation: migrations run once under a database lock, scheduled work fires on one replica through a clustered scheduler, and sessions are shared through Redis.

Secure by default

Measures that come with the install and need no extra configuration.

  • Your secrets stay yours. Passwords and keys are generated on your server during the install; the images carry only non-secret defaults.
  • Git credentials are encrypted. The access tokens of the providers you connect are encrypted in the database with AES-GCM under your installation's master key.
  • Shell-less, non-root images. The containers carry only the .NET runtime, contain no shell and run as an unprivileged user.
  • A licence that cannot be edited. The licence is verified against the AppArch signing key inside the images; editing the file by hand breaks the signature.
  • Sign-in stays in your network. E-mail and password (with optional two-factor authentication) or LDAP / Active Directory. There is no Google or GitHub sign-in.

How does the licence behave?

No surprise shutdowns: the limits are explicit, and so is what happens past them.

A signed file, verified offline

The licence is an RS256-signed .lic file; the install verifies it locally, and a licence works on one installation only. It does not phone a licence server to keep running. Several pods sharing one database count as one installation.

Calendar-month counters

Usage limits count per calendar month and reset at the start of each month - no sliding-window surprises.

Soft limit first, hard limit after

Crossing a limit does not stop work: seven days and 10% are tolerated while the panel warns you. The hard stop only comes once that buffer is spent.

Frequently asked

How do I get updates?
New releases land in the same image registry; a single tag versions all components together. Updating = pull the new tag, restart compose; database migrations run themselves on boot. The panel can announce new versions if you let it.
Which authentication options exist?
E-mail and password with optional two-factor authentication, or LDAP / Active Directory sign-in. Users are provisioned from the management area. There is no Google or GitHub sign-in.
In a full air gap, what works and what does not?
Works: all analysis, every module, the panel, the reports and Archito's learning - the whole product is local. Does not: AI suggestions and the Ask tab, which need a connection to the AI provider, and automatic release announcements. Images are carried in physically; the installation code goes out, and the licence file issued for it comes in.
Who sees the data?
Only you. Source code, findings, users and reports sit in your database; no telemetry or code content flows to AppArch. On our side there is only your licence record.
How does pricing work?
The licence is quoted per installation, with project and member limits written into it. It is also available through partners and resellers. Talk to sales for a quote - the form takes two minutes.
Does it run on Kubernetes?
Yes. The reference install is single-server Docker Compose; the same images run on Kubernetes. Point the liveness probe at /health/live and the readiness probe at /health/ready, and give the API a generous startup window, because the first boot runs migrations. Replicas that share one database count as one installation and run on one licence.
What should I back up?
The PostgreSQL data (the pgdata volume or a pg_dump) and the .env file. If the encryption master key in .env is lost, stored Git credentials can no longer be decrypted, so keep that key with the rest of your secrets.
What happens to the licence if I change servers?
If you move the database to the new server, the installation stays the same and the licence keeps working. If you install from scratch on the new server, ask AppArch to release the licence and collect it again from the new installation; a licence works on one installation at a time.

Try it inside your perimeter

Ask for your installation ID; with the compose file you are up in an afternoon.

Join our newsletter

New modules, release notes and writing on architecture. Leave with one click whenever you like.