System Page

The System page (System in the sidebar) provides operational tooling for inspecting and managing the runtime state of your coreX Platform deployment. It has seven tabs: Settings, Users, Features, Snapshots, Tables, Valkey, and High Availability.

This page documents the three operational tabs — Tables, Valkey, and High Availability. For Settings and Users, see Users & Settings. For Snapshots, see Audit & Snapshots.

Tables Tab (Stick-Table Viewer)

HAProxy stick-tables are in-memory data structures that track per-client state — IP addresses, request counts, rate-limit counters, connection counts, and more. They power rate limiting, connection tracking, source-IP stickiness, and the Page Protect beacon trust table. The Tables tab lets you inspect every stick-table in the running HAProxy instance, view their entries, and clear entries or entire tables.

What You See

The tab shows a list of all stick-tables, each with:

Click any table row to expand it and view the entries inside.

Entry View

Each expanded table shows a paginated entries table with:

Features

Performance

Stick-tables can hold hundreds of thousands of entries. To keep the UI responsive:

• The backend uses a 15-second timeout for show table commands (the default 5s stats-socket timeout is too short for large tables).
• The full parsed entry list is cached in Valkey for 5 seconds (STICK_TABLE_CACHE_TTL_SECONDS), so repeated pagination clicks don’t re-dump the entire table from HAProxy.
• The maximum page size is capped at 500 entries (STICK_TABLE_MAX_PAGE_SIZE).

Common Stick-Tables

The exact set of tables depends on your configuration — tables are created on demand when the features that use them are enabled.

Valkey Tab (Valkey Inspector)

Valkey (a Redis-compatible in-memory data store) is coreX Platform’s shared state backend. It holds rate-limit counters, the task queue, token revocation lists, CAPTCHA challenge state, stick-table caches, and more. The Valkey tab is a read-only keyspace browser (with admin-only delete) for inspecting and debugging the live Valkey instance.

Server Info Card

The top of the tab shows a summary of the Valkey server:

If Valkey is unavailable, the card shows an error and the rest of the tab degrades gracefully.

Namespace Browser

Keys are grouped by namespace prefix — the substring before the first : in the key name. For example, rate_limit:192.168.1.1 is in the rate_limit namespace; cap:_cv:abc123 is in the cap namespace. Keys without a : are grouped under a sentinel group.

Each namespace row shows:

• The prefix (e.g. rate_limit, cap, stick_table, valkey_inspect)
• The key count in that namespace
• Up to 5 sample key names

Click a namespace to expand it and view the keys inside.

Key View

Each expanded namespace shows a paginated keys table:

Features

Common Namespaces

Performance

• Key scanning uses bounded SCAN operations (up to ~200,000 keys max via VALKEY_INSPECT_MAX_SCAN_BATCHES).
• Scanned key lists are cached in Valkey for 5 seconds (VALKEY_INSPECT_CACHE_TTL_SECONDS).
• The maximum page size is capped at 500 keys (VALKEY_INSPECT_MAX_PAGE_SIZE).

High Availability Tab

The High Availability (HA) tab is a health dashboard and configuration editor for multi-instance HA deployments. It is only visible when HA is enabled (HA_ENABLED=true). When HA is disabled, the tab shows a message indicating HA is not configured.

For the full HA deployment guide, see Docker Swarm or Kubernetes. This section documents the operational tab.

Health Dashboard

The top of the tab shows real-time health for all HA components, auto-refreshing every 5 seconds:

HAProxy Instances

Each configured HAProxy instance is shown with:

The MASTER instance is the one receiving traffic (via the keepalived VIP or Swarm ingress). BACKUP instances are hot standbys that take over if MASTER fails.

Valkey Nodes

Each Valkey node is shown with:

In HA mode, Valkey runs as a primary + replica with Sentinel-managed failover. If the master fails, Sentinel promotes a replica to master automatically.

Coraza SPOA Instances

Each Coraza SPOA (WAF engine) instance is shown with:

Coraza runs with 2 replicas in HA mode. HAProxy load-balances WAF evaluations across healthy instances — if one goes down, traffic shifts to the other.

Configuration Editor

Below the health dashboard is the configuration editor (admin only):

Topology Settings

Valkey Sentinel

When Sentinel is enabled, the Valkey client uses Sentinel.master_for() to discover and connect to the current master. If Sentinel fails, it falls back to direct mode.

HAProxy Instances Editor

Add, edit, or remove HAProxy instance entries. Each instance has:

The provider pushes generated HAProxy config to every instance in this list. In single-instance mode, this list contains one entry (the local instance).

Keepalived Editor

VRRP configuration for IP failover. In Swarm mode, this section shows a hint that keepalived is not used (the Swarm ingress mesh provides VIP and failover instead).

Apply Button

The Apply button pushes the HA configuration to all instances. This:

1. Generates keepalived config (if not Swarm mode) and restarts keepalived on each HAProxy instance
2. Generates the HAProxy peers section for stick-table replication
3. Pushes the HAProxy config to every instance’s Data Plane API
4. Reloads HAProxy on every instance

Swarm Mode Differences

When SWARM_MODE=true:

• Keepalived is not used — the Swarm ingress routing mesh provides VIP load balancing and automatic failover
• The keepalived state badge shows “Swarm VIP” instead of MASTER/BACKUP
• The keepalived editor shows a hint but the values are ignored
• Stick-table peers still use the tasks.corex DNS name for peer discovery (Swarm’s DNS round-robin)
• HAProxy instances use endpoint_mode: dnsrr for direct instance-to-instance stick-table sync

Verification

Stick-Tables

1. Navigate to System > Tables
2. Verify the rate-limit and frontend tables appear with non-zero Used counts after sending traffic
3. Expand a table and verify entries appear with keys (IPs), expire times, and store counters
4. Send a request that triggers a rate limit, then check the rl_rate_table — the counter should increment
5. Clear the entry (admin) and verify the client is no longer rate-limited

Valkey

1. Navigate to System > Valkey
2. Verify the server info card shows the correct version, role (master), and non-zero key count
3. Expand the rate_limit namespace and verify rate-limit keys appear with TTLs
4. Trigger a CAPTCHA challenge and verify a cap:cid:* key appears in the cap namespace
5. Delete a key (admin) and verify it disappears on refresh

High Availability

1. Navigate to System > High Availability
2. Verify all HAProxy instances show as Available with the correct keepalived state (one MASTER, rest BACKUP)
3. Verify Valkey nodes show master + replica roles
4. Verify Coraza instances show UP state
5. Stop the MASTER HAProxy instance and verify a BACKUP takes over (state changes to MASTER)
6. Verify stick-tables stay in sync across instances (same entry counts in the Tables tab)

Next Steps

• Docker Swarm — HA deployment with the Swarm ingress mesh
• Kubernetes — HA deployment with Helm and sidecar pods
• Architecture — HA topologies diagram and explanation
• Rate Limiting — What the stick-tables track