Configure FDIE on-premises and offline

Use the release-specific customer bundle and handover instructions supplied by Magdox. On-premises FDIE is the complete analysis platform in your network; it is not the Code Security CLI. Hosted self-service does not provision an on-premises server. A disconnected deployment also needs an offline licence, intelligence/update transfers and reachable local identity services.

1. Agree the delivery and operating scope

• Record the customer organisation, authorised operators, licence term, seat/storage allowances, host architecture and support process.
• Agree a stable deployment identity and recovery/rehosting procedure; a licence from another installation cannot be assumed to work.
• Obtain the release manifest, trusted checksums/signature verification instructions, licence or agreed evaluation, all required container images, initial vulnerability data and customer deployment guide.
• Keep licence-signing keys with Magdox. Customers receive a signed licence and verification material, never the signing secret.

2. Prepare an isolated host

• Provision the workload-sized Linux host and durable storage from the agreed profile. Install the supported Docker/Compose versions before disconnection.
• Provide internal DNS, TLS and time synchronisation. Configure firewall rules for application users, administrators and any approved internal identity or mail services.
• Default-deny public outbound access at the network boundary. An on-premises environment variable alone does not prove the application makes no external calls.
• Keep endpoint protection in place. If an exception is necessary for malware analysis, review and restrict it to the isolated analysis paths; do not broadly exempt the host or all Docker storage.

3. Verify and import the delivery

Verify the supplied archive against a checksum or signature obtained through the agreed trusted channel before importing it. The names below are examples; use the archive named in your release manifest. Import every supporting image listed there so Compose does not need an internet registry.

docker --version
docker compose version
# After verifying the delivered archive:
docker load -i fdie-onprem-release.tar.gz
cp .env.onprem.example .env
chmod 600 .env

4. Configure locally generated secrets

Edit the supplied environment file on the target host. Do not paste it into tickets, browser chat or public repositories. Generate a different random value for each secret and store it in your approved secret manager. The table lists configuration names only, not values.

5. Configure local identity

The Compose stack does not bundle Keycloak. Use your approved reachable OIDC provider and configure OIDC_ISSUER_URL, OIDC_CLIENT_ID and OIDC_CLIENT_SECRET privately. Register the exact callback required by the supplied release, configure claim mapping and trust its TLS certificate. Test login, MFA, logout and role assignment. A public identity provider is not reachable in a fully disconnected network; do not rely on an internet-only recovery path.

If the organisation uses Keycloak, also create a confidential service-account client in that realm with only the realm-management roles view-users, query-users and manage-users, and set KEYCLOAK_ADMIN_CLIENT_ID and KEYCLOAK_ADMIN_CLIENT_SECRET. FDIE uses it to create accounts and set passwords for email sign-in; every sign-in screen, including authenticator setup, is FDIE's own. Single sign-on returns to /api/auth/sso/callback on your FDIE origin.

Optional: keep secrets in OpenBao

By default every secret is read from the bundle's .env file. If you already run OpenBao or HashiCorp Vault, FDIE can sign in with an AppRole, take short-lived PostgreSQL credentials from a database secrets engine role (renewed while each process runs) and read application secrets from a KV v2 path. Anything OpenBao cannot supply falls back to .env. The bundle's SECRETS-OPENBAO.md walks through the engine, policy, AppRole and database role step by step.

6. Install the licence and validate configuration

Place the issued licence in the bundle's license directory and preserve the deployment-identity volume. If using an evaluation to obtain that identity, agree the process and expiry with Magdox first. Do not alter the host identity or wipe licence state to extend an evaluation. The hosted 14-day checkout trial is a different arrangement.

mkdir -p license
# Place the privately supplied license.lic in license/ using an approved channel.
# Validate without printing resolved secrets:
docker compose -f docker-compose.onprem.yml config --quiet
# Run the customer deploy script from the verified bundle:
./deploy.sh
docker compose -f docker-compose.onprem.yml ps

How the licence is checked: licence.lic is a signed document naming your organisation, this installation's deployment identity, expiry, plan, seats, features and limits. Magdox signs it with an ECDSA P-384 key held in a hardware-backed key service; your installation holds only the public key, compiled into the release, and verifies the licence at every start without contacting Magdox. An altered licence, one issued for another installation, an expired licence or a tampered release stops the API from starting with the reason in its log; with no licence installed, a 21-day evaluation runs. The deployment identity lives in the licence data volume, so back that volume up with the rest.

7. Verify the offline boundary

• Confirm the frontend, API, database, queue and required workers are healthy. Check missing-variable errors privately; diagnostic logs can contain sensitive data.
• Block public egress and test sign-in, one authorised firmware analysis, a report export and a release comparison. Review failed stages as well as successful jobs.
• Disable or replace external intelligence sync, geolocation, monitoring, reputation lookups, email, cloud storage, webhooks and public identity integrations. Inspect scheduled tasks, not just request handlers.
• Transfer approved vulnerability/rule data through your controlled process and retain its version and age. Offline results cannot incorporate intelligence that has not been imported.
• CVE data: each release carries about 400,000 CVEs with CVSS, CWE, EPSS and CISA KEV data, restored into an empty database on first start so matching works offline at once. To keep it current, request a free NVD API key, set NVD_API_KEY and allow nvd, kev and epss in ONPREM_OUTBOUND_INTEGRATIONS; the daily sync then fetches only CVEs changed since the newest one held. These syncs run on their own worker and never take capacity from firmware analyses.
• Confirm configured upload/temp-storage and sandbox resource limits with a representative image before accepting production use.

8. Back up, update and recover

• Back up the database, retained firmware/exports, configuration and deployment-identity/licence state with restricted access and encryption.
• Test restoration into an isolated environment and reapply deletion instructions before returning it to service.
• Import verified update bundles through the same controlled process. Take a backup and review migration/rollback instructions before updating containers.
• Agree renewals before licence expiry. Keep a documented offline incident and support process with redacted diagnostic packages.

Never run destructive volume-removal or reset commands as a routine upgrade or troubleshooting step. Production acceptance requires the network, identity, storage and recovery checks for the specific delivered release.

Arrange an on-premises deployment

Handover record

Keep the verified release manifest, image and intelligence versions, licence expiry, local identity configuration owner, backup location and last restore-test outcome in the customer's protected operating record. Store secret values separately. The on-call operator should be able to find the approved recovery procedure without needing public internet access.