Architecture and components

Goal

Understand each ShieldGate component, what it is responsible for, and how a configuration change travels from the console to the data plane.

The components

• Admin console (Web) — the browser UI where administrators sign in and manage everything: topology, policies, network, certificates, and operations.
• API — the single source of truth. It validates changes, stores them in PostgreSQL, and publishes configuration snapshots.
• Proxy — the HTTP(S) data plane. It terminates TLS, evaluates WAF policies, applies traffic control, and forwards clean requests to upstreams.
• Appliance — the network data plane. It applies zones, interfaces, routes, firewall rules, NAT, and VPN configuration on the host.
• Worker — background jobs: certificate renewals, scheduled tasks, feed updates.

How configuration flows

1. An administrator edits configuration in the console.
2. The console calls the API, which validates and stores the change in PostgreSQL.
3. When the administrator publishes, the API produces a versioned snapshot.
4. Data-plane services are notified over Redis and pull the new snapshot.
5. Each node reports apply status back so you can confirm the rollout.

Publishing is atomic and versioned. If something goes wrong, you roll back to a previous version rather than editing live state.

Storage and messaging

• PostgreSQL stores all configuration, identity, and audit data.
• Redis carries publish notifications and shared cache state between nodes.

Verify your understanding

• Which component is the source of truth for configuration?
• What happens if the proxy misses a publish notification? (It pulls the latest snapshot when it reconnects — snapshots are versioned.)

Tips

• The console never talks to the database directly; it always goes through the API. Remember this when debugging permissions or connectivity.