Install Naradox as a self-hosted Check Point governance workspace.

Before you choose a host

• Supported deployment: one Linux host or VM, using the signed installer and Docker Compose with bundled PostgreSQL 18. An external database is not supported.
• Release architecture: each bundle targets one Linux platform. Confirm the selected release's architecture with support before provisioning your host. The installer checks that its images match your Docker host platform.
• Check Point: the Management server must expose API v2.1. Configure its URL ending in /web_api/ and select the intended domain for Multi-Domain Server deployments.

Validate in your environment: the API requirement is not a claim that every Management release or hotfix has been tested. Use a pilot to confirm your exact version, intended workflows, and CPU, memory, and storage needs before production rollout.

1. Issue the license in the portal

• Sign in to your customer account and open Licenses.
• Issue the license for your deployment and save license.json or the matching Naradox: string for local import.
• The first signed import binds the installed deployment to the issued deployment and customer IDs.

The customer portal account and your first local Naradox administrator are separate accounts. Keep the downloaded license private; signing in to the portal does not activate the installed application. If a required Terms review appears, an owner or billing admin must complete it before license issuance.

2. Check the target host

• Use a Linux host or VM with Docker Engine 28.0.0 or newer and Docker Compose plugin 2.33.1 or newer.
• Have Minisign, sha256sum, Bash, tar, and administrator access for verification and installation.
• Provide a same-host HTTPS reverse proxy and certificate. The installer exposes the UI on loopback by default.
• Allow the Docker daemon to pull the release's pinned PostgreSQL 18 image, and allow outbound access to the Check Point Management servers you plan to connect.
• For UI-driven updates, use rootful Docker with direct host UID/GID mapping, a physical root-owned install path, systemd, /usr/bin/python3 3.11 or newer, age, Minisign, Bash, and tar. SELinux-enforcing hosts currently use signed manual upgrades.

Check the installed Docker versions and host platform before scheduling the install:

docker compose version
docker version --format '{{.Server.Version}}'
docker version --format '{{.Server.Os}}/{{.Server.Arch}}'

Have these decisions ready

• The browser-facing HTTPS hostname, its DNS record, and a certificate and renewal plan for that hostname.
• The first local administrator's details and a way to retain MFA backup codes securely.
• The installation directory and whether host-supported, administrator-approved UI updates will be enabled.
• An encrypted off-host backup destination, a separately held decryption identity, and the recovery window your organization needs.

The signed bundle includes docs/INSTALL_ADMIN.md. Its server requirements and guided HTTPS sections own the full host and proxy procedure. For backup tools and restore preparation, follow the backup and recovery guide before admitting users.

3. Download and verify the release

Need the release verification key? Email support@naradox.com with the release version. Request naradox-release-minisign.pub, its expected SHA-256 fingerprint, and signing key identity. Arrange confirmation through a trusted onboarding contact or channel separate from the release download, then keep the confirmed fingerprint for your verification checks. A key supplied alongside an unverified archive cannot establish that archive's authenticity.

• In portal Downloads, check whether the release is Stable or Preview and read its migration, breaking-change, advisory, and release notes.
• Download the bundle, detached .minisig signature, and .sha256 file for the same release.
• Follow the exact Minisign and SHA-256 commands in that release's details. Every check must succeed before extraction or sudo.

4. Run the verified installer locally

1. Extract the verified archive, enter its top-level directory, and run sudo ./scripts/install.sh.
2. Supply the public HTTPS URL and first local admin details when prompted. Follow the guided HTTPS setup or the manual proxy procedure in the bundled installation guide.
3. Configure the same-host TLS proxy with the installer-generated proxy credential. Keep the UI on its selected loopback bind and the API port unpublished; DNS alone does not configure HTTPS.
4. The installer prepares the bundled runtime, PostgreSQL, production configuration, and first local admin. Wait for its success message and readiness checks.

Expected result: your chosen HTTPS address opens the installed Naradox sign-in page with a valid certificate. The installer's local readiness checks and the browser-facing HTTPS check are separate; complete the public HTTPS check in docs/INSTALL_ADMIN.md from a client workstation.

5. Import the issued license

• Open Platform > Licensing in Naradox after first login.
• Upload the portal-issued license.json or paste the matching Naradox: string.
• Naradox verifies the signed payload locally and enforces its licensed-user, deployment, and expiry limits.

Sign in with the local administrator created by the installer and enroll its authenticator. Enroll local administrators before the host operator enables mandatory administrator MFA under the bundled installation procedure; an unenrolled administrator cannot sign in while that requirement is active. Check the displayed deployment, capacity, and expiry after import. Keep the portal copy available for recovery, and import a replacement when the signed limits or expiry change.

6. Check the installation before inviting operators

• Confirm local sign-in, MFA, license status, and the intended browser-facing HTTPS URL.
• Create an encrypted off-host backup and complete a disposable restore check using the bundled guide.
• Follow the first-workflow guide to add Check Point, check read access, and validate a deliberately limited change in a pilot.
• Retain the matching signed release and assign owners for account recovery, backups, and change approval.

The installed deployment verifies its license locally and does not need the portal for day-to-day governance.

If installation stops

• Signature or checksum failure: stop before extraction. Re-download the matching files and confirm the key; use the download recovery steps.
• Host or platform check fails: correct the reported prerequisite or obtain the matching release. Do not bypass the platform check or rebuild the supplied images.
• HTTPS fails after local readiness: inspect DNS, certificate, same-host proxy routing, and the generated proxy configuration using the bundled guide.
• Interrupted setup: retain the original bundle and installation state. Follow the guide's interrupted-install procedure; do not delete the database or edit the completion marker to make setup appear successful.

Record the release version and exact failed step, then send a sanitized support request if the recovery step is unclear.