Architecture Overview

Infracast is built as a cloud-native, API-first platform for continuous asset discovery, compliance automation, and infrastructure security. This page describes the high-level architecture.

System Diagram

graph TB
    subgraph Clients
        UI[React/TypeScript UI]
        API_Client[API Clients / Integrations]
        Agent[Infracast Agents]
        Relay[On-Prem Relay]
    end

    subgraph AWS["AWS (ECS Fargate)"]
        CF[CloudFront CDN]
        ALB[Application Load Balancer]
        ECS[Go API Server<br/>ECS Fargate]
        PH[Plugin Host<br/>Subprocess]
    end

    subgraph Data
        RDS[(PostgreSQL<br/>RDS)]
        S3_UI[S3 Bucket<br/>React UI]
        S3_Art[S3 Bucket<br/>Evidence Artifacts]
    end

    subgraph Plugins
        DP[Discovery Plugins<br/>AWS, Azure, GCP,<br/>VMware, Cisco, ...]
        OP[Output Plugins<br/>CIS, NIST, CMMC,<br/>FedRAMP, STIG, ...]
    end

    UI -->|HTTPS| CF
    CF --> S3_UI
    API_Client -->|HTTPS| ALB
    Agent -->|HTTPS :443| ALB
    Relay -->|WSS :443| ALB
    ALB --> ECS
    ECS --> RDS
    ECS --> S3_Art
    ECS --> PH
    PH --> DP
    PH --> OP

Core Components

Go API Server

The heart of Infracast is a Go API server built on Go. It handles:

• REST API — all client and agent communication
• WebSocket Hub — persistent connections for on-prem relay connectors
• Plugin Orchestration — spawns and manages discovery plugin subprocesses
• Scheduler — runs discovery jobs on configurable intervals
• Threat Intelligence — correlates asset data with CVE/NVD feeds
• Compliance Engine — maps asset findings to NIST 800-53, CMMC, FedRAMP, PCI-DSS, SOC2, STIG controls

React / TypeScript UI

The frontend is a single-page application (SPA) served from Amazon S3 via CloudFront. It communicates exclusively with the API server — there is no server-side rendering.

Key UI features:

• Interactive asset graph explorer
• Compliance posture dashboards
• Discovery job management
• Agent fleet management
• Evidence and POA&M tracking

PostgreSQL Database

All persistent state is stored in PostgreSQL:

• Asset graph (nodes and edges)
• Tenant and user accounts
• Discovery job history
• Findings, evidence, POA&M
• Compliance questionnaires
• Audit logs

Plugin System

Infracast uses a plugin-per-process model for discovery. Each plugin runs as an isolated subprocess communicating over a well-defined interface. This means:

• Plugin crashes don't affect the API server
• Plugins can be updated independently
• New integrations can be added without redeploying the core

See Plugin System for details.

Deployment Models

Model	Where	Best For
SaaS	app.infracast.io	Most organizations — zero ops overhead
Docker	Any Docker host	Evaluation, air-gapped, small teams
Terraform + ECS	Your AWS account	Enterprise self-hosted, MSSP, FedRAMP

SaaS Architecture

Internet → CloudFront → S3 (UI)
         → ALB → ECS Fargate → RDS PostgreSQL (Multi-AZ)
                            → S3 (Evidence artifacts)

Self-Hosted (Docker)

localhost:3000 (UI)  →  localhost:8080 (API)  →  PostgreSQL

Self-Hosted (ECS / Terraform)

See Deployment Architecture for the full AWS architecture.

API-First Design

Every capability in Infracast is accessible via REST API. The UI uses the same API as external integrations. This means:

• Full automation support (CI/CD pipelines, IaC scanning)
• Easy integration with SIEMs, ticketing systems, and GRC tools
• API tokens scoped to tenant and role

Multi-Tenancy and RBAC

Infracast is built for multi-tenant operation with a three-layer hierarchy: Account → Tenant → Workspace → Data.

• Account — billing relationship; one per signing customer
• Tenant — customer organization; users and policies live here
• Workspace — scoped data environment inside a tenant; credentials, scans, findings, and reports live here
• System Admins manage tenants and platform settings
• Tenant Admins manage users and configuration within their tenant
• All data is scoped by workspace_id (and tenant_id) at the database level — cross-workspace data leakage is structurally prevented

See Accounts, Tenants & Workspaces for the full hierarchy, Multi-Workspace Patterns for when to use multiple workspaces, and Security Architecture for the full RBAC model.

Key Design Principles

Principle	How Infracast Implements It
Outbound-only	Agents and relays initiate connections — no inbound firewall rules needed
Credential safety	Credentials stored encrypted at rest, never written to disk on relay/agent
Evidence integrity	Ed25519 signatures on all evidence artifacts
FIPS compliance	BoringCrypto build available for FedRAMP High / IL4+
Extensibility	Plugin interface allows adding new providers without core changes

Security Relationship Graph (Build 112)

Infracast's topology graph includes a security relationship layer — edges that capture IAM chains, encryption bindings, and data-flow paths between resources.

These edges power attack path chaining across the full IAM identity chain:

• attached_to — IAM policy → role or user (policy blast radius)
• executes_as — Lambda/EC2 → IAM role (compute execution identity)
• depends_on — EC2 instance profile → IAM role; CloudFront → S3 origin
• logs_to — CloudTrail/Config → S3 (audit log path integrity)
• encrypted_by — Storage/compute resources → KMS key (encryption coverage)

See Data Model and Attack Path Analysis for details.

Technology Stack

Layer	Technology
API Server	Go 1.22+
Frontend	React 18, TypeScript, Vite
Database	PostgreSQL 15
Container	Docker, AWS ECS Fargate
IaC	Terraform 1.5+
CDN	Amazon CloudFront
Auth	JWT, Ed25519 API keys