Architecture

S4E On-Prem is a multi-service application where all components run as containers. Services communicate over an isolated container network. External access is provided through a reverse proxy using HTTPS and subdomain-based routing.

High-Level Diagram

Browser / API Client
        │  HTTPS
        ▼
┌─────────────────────┐
│    Reverse Proxy    │  TLS termination · subdomain routing
└──────────┬──────────┘
           │
           ▼
┌──────────────────────────────────────────────┐
│                 Container Network            │
│                                              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ Frontend │  │ Core API │  │Public API│  │
│  └──────────┘  └──────────┘  └──────────┘  │
│                                              │
│  ┌──────────────────────────────────────┐   │
│  │         Orchestration Layer          │   │
│  │  Trigger · Scheduler · Dispatcher   │   │
│  └──────────────────┬─────────────────-┘   │
│                     │  Message Queue        │
│  ┌──────────────────┴───────────────────┐   │
│  │            Worker Layer              │   │
│  │   Scanner · Crawler · Action runner  │   │
│  └──────────────────────────────────────┘   │
│                                              │
│  ┌──────────────────────────────────────┐   │
│  │             Data Stores              │   │
│  │  Relational · Cache · Document ·    │   │
│  │  Object Storage · Message Broker    │   │
│  └──────────────────────────────────────┘   │
└──────────────────────────────────────────────┘

Service Layers

Web Layer

Component	Role
Frontend	Web application served to the browser

API Layer

Component	Role
Core API	Main REST API — authentication, assets, findings, reports
Public API	External-facing API for integrations and on-prem sync
Admin API	Internal administration endpoints
Integration API	Third-party integrations (Slack, Jira, webhooks)

Real-time & AI Layer

Component	Role
Event stream	Server-Sent Events — live notifications pushed to the browser
AI assistant	AI-powered action and remediation recommendations

Orchestration Layer

Component	Role
Scan trigger	Receives scan initiation events and publishes them to the queue
Scheduler	Time-based task runner (DB sync, telemetry, mail queue)
Dispatcher	Routes queued scan jobs to the correct worker queues
Scan pre-processor	Enriches and splits scan tasks before dispatch (3 instances)

Worker Layer

Component	Role
Vulnerability scanner	Executes scan modules against target assets
Web crawler	Discovers endpoints, parameters, and technologies on web apps
Action runner	Executes remediation and automation actions
Output manager	Manages and routes scan output to downstream consumers

Sync Services

Component	Role
Template puller	Periodically pulls updated scan templates from S4E Cloud

Supporting Tools

Component	Role
Headless browser	Renders JavaScript-heavy pages during scanning
PDF converter	Converts HTML reports to PDF for export

Data Stores

Store	Role
Relational database	Primary data store — assets, findings, users, scan results
Cache	Session state, rate limiting, real-time ephemeral data
Message broker	Async messaging between orchestration and worker layers
Document store	Crawler output, scan metadata, raw unstructured results
Object storage	Reports, exported files, attachments

Communication Patterns

Synchronous

The browser communicates with the Core API and Public API over HTTPS via the reverse proxy.
API services call internal backend services directly over HTTP for real-time operations.
Scan initiation flows from the Core API to the Scan Trigger synchronously.

Asynchronous

Scan and crawl pipelines are event-driven:

The Scan Trigger or Scheduler publishes a scan request to the message queue.
The Dispatcher routes the request to the appropriate worker queue.
The Scan Pre-processor enriches the job.
The Vulnerability Scanner or Web Crawler executes the job and publishes results.

Queue isolation

Each scan type has its own dedicated queue, preventing slow scanners from blocking fast ones.

Nginx & Subdomain Routing

Nginx runs on the host (not in Docker) and terminates TLS for all subdomains. Each subdomain proxies to a specific Docker service port:

Subdomain	Component	Notes
`app.<domain>`	Frontend	Main user interface
`core.<domain>`	Core API	REST API
`api.<domain>`	Public API	External integrations
`sse.<domain>`	Real-time events	WebSocket / SSE stream
`admin.<domain>`	Admin panel	HTTP Basic Auth required
`git.<domain>`	Template registry	HTTP Basic Auth required
`adminer.<domain>`	Database UI	HTTP Basic Auth required
`portainer.<domain>`	Container management	Portainer login
`rmq.<domain>`	Message broker UI	HTTP Basic Auth required

TLS certificates are self-signed and generated during installation. Replace with your own certificates for production use.

Cloud Connectivity

S4E On-Prem maintains a one-way outbound connection to S4E Cloud:

Direction	Purpose
On-Prem → `api.s4e.io`	Pull scan templates every 6 hours
On-Prem → `api.s4e.io`	Sync action catalog (daily)
On-Prem → `api.s4e.io`	Send anonymized telemetry (daily)

No inbound connections from S4E Cloud are required. All data initiated from S4E Cloud goes only to the sync API endpoints using your API key for authentication.

Next Steps

Differences from Cloud — feature comparison.
Requirements — server sizing guide.
Installation — step-by-step setup.