Sentinel Secure X

Readable deployment docs on the live domain.

Installation, operator guidance, endpoint service setup, and platform references in one browsable library.

Open Docs Home Agent Downloads Dashboard

Production Profile

The practical hardening checklist for pushing Sentinel Secure X beyond a development install.

Operator Guides View Markdown

Production Profile

Use .env.example as the baseline, then tighten the deployment with the checklist below before exposing Sentinel Secure X to real devices or downstream systems.

Network boundary

  • Terminate browser TLS and device mTLS at a trusted reverse proxy.
  • Leave SENTINEL_TRUST_PROXY_CERT_HEADERS=false unless the Flask app is only reachable behind that trusted proxy.
  • Replace SENTINEL_ALLOWED_ORIGINS=* with the exact dashboard origin or origins you expect.

Secrets and signing material

  • Replace SENTINEL_SECRET_KEY, SENTINEL_JWT_SECRET, workload tokens, HMAC secrets, and monitoring bearer tokens with long random values.
  • Store Ed25519 private keys for workload assertions, trust assertions, incident-policy bundles, backup manifests, and evidence exports outside the repo.
  • Prefer external signing commands or HSM-backed hooks where your environment already has that capability.

Enrollment and identity posture

  • Set SENTINEL_REQUIRE_NEW_DEVICE_APPROVAL=true unless you are intentionally running an open enrollment window.
  • Keep SENTINEL_REQUIRE_CERT_COMMON_NAME_MATCH=true and align issued device certificates with device_id.
  • Enable CRL and/or OCSP validation for production certificates instead of leaving revocation inputs empty.

Workload trust posture

  • Prefer SENTINEL_WORKLOAD_ASSERTION_ONE_TIME_USE=true and SENTINEL_WORKLOAD_ASSERTION_BIND_SOURCE_IP=true for higher-assurance workload clients.
  • Require signed requests and client certificates for sensitive workload clients such as rollout-signal writers.
  • Keep workload assertion signing and verification keys configured together so issuance and validation stay aligned.

Change-management features

  • If you use incident policy template promotion between environments, enable explicit target-environment checking and pin trusted issuers.
  • Consider SENTINEL_INCIDENT_POLICY_TEMPLATE_DIRECT_IMPORT_ENABLED=false in higher-assurance environments so promotion always goes through reviewed import requests.
  • Keep dual-approval settings enabled for sensitive command, certificate, policy exception, recovery, and update-campaign paths.

Background services

  • Run the API, delivery worker, maintenance worker, scheduled-job coordinator, and update-campaign scheduler as separate managed services.
  • Set the SENTINEL_REQUIRE_* health toggles to true for the workers you rely on so readiness fails closed when they disappear.
  • Configure OS-native service recovery rather than custom watchdog loops.
  • After deployment changes, run the Linux smoke test against the selected units and the local readiness endpoint before reopening traffic.

Database posture

  • Keep SENTINEL_DATABASE_REQUIRE_POSTGRESQL=true in production.
  • Apply Alembic migrations as part of deployment and avoid SENTINEL_AUTO_CREATE_SCHEMA_ON_BOOT=true outside development.
  • Back up the PostgreSQL database and any signing material together with your broader recovery plan.
On this page
Network boundarySecrets and signing materialEnrollment and identity postureWorkload trust postureChange-management featuresBackground servicesDatabase postureRecommended operator references