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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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?
Which authentication options exist?
In a full air gap, what works and what does not?
Who sees the data?
How does pricing work?
Does it run on Kubernetes?
What should I back up?
What happens to the licence if I change servers?
Try it inside your perimeter
Ask for your installation ID; with the compose file you are up in an afternoon.