Skip to main content
Systemplane lets you view and modify supported Matcher configuration without restarting the service. Application behavior varies by key: request-time settings may apply on the next request, while a configuration reload stops and restarts a running worker when its configuration changes.

Why use Systemplane


In a traditional deployment, changing a configuration value means updating environment variables and restarting the service. Systemplane eliminates that downtime for many settings:
  • Adjust rate limits during traffic spikes without a redeploy — avoiding service disruption during peak transaction volumes
  • Tune worker intervals based on observed workload; a configuration reload reconciles the affected worker and restarts it when its running configuration changes
  • Update the maximum number of tenant pools as traffic patterns change; PostgreSQL connections-per-pool settings require an environment change and restart
  • Inspect current runtime values to diagnose production issues without log diving

How it works


Systemplane provides a flat key-value management API. All configuration keys are in a single namespace under /system/matcher.

Endpoints

These endpoints are served directly by the running Matcher instance. They are not versioned under /v1 — use the paths above exactly as shown.

Permissions


Systemplane configuration and catalog routes are protected by the same authentication used by Matcher API routes. When authentication is enabled, these routes require the system-runtime-config:admin RBAC permission (resource system-runtime-config, action admin). GET /system/matcher/streaming/manifest is a separate route and requires streaming-manifest:read. When authentication is disabled, all endpoints are accessible without restriction.

Apply behaviors


Not every configuration value can be changed at runtime. Each key has an apply behavior that tells you when changes take effect: Most bootstrap-only keys are NOT registered in the systemplane API — they are managed exclusively through environment variables. This prevents a footgun where an admin PUT would appear to succeed but the running process would silently continue using the boot-time value. The registered Swagger keys are an exception: they are visible in Systemplane but remain bootstrap-only (see the note below).

Common configuration keys


Below are the most commonly adjusted keys, organized by category. For a complete list, call GET /system/matcher.

Runtime-adjustable keys

These keys can be changed without restarting Matcher:
swagger.enabled, swagger.host, and swagger.schemes are registered and visible in Systemplane, but they are not live controls. Swagger mounting and handler values are captured at bootstrap, so a runtime PUT does not change the live UI or specification behavior. Change their startup configuration and restart Matcher instead.

Multi-tenant keys (runtime adjustable)

These keys control multi-tenant behavior and can be adjusted without restart. See Multi-Tenant Mode for details.
Enabling multi-tenant mode itself (tenancy.multi_tenant_enabled / MULTI_TENANT_ENABLED) is bootstrap-only — it is read once at startup and requires a restart. It is not registered in the Systemplane API and cannot be toggled at runtime. See the bootstrap-only table below.

Bootstrap-only keys (require restart)

These keys are not registered in the systemplane API. Change them via environment variables and restart:

Best practices


Call GET /system/matcher to see all current runtime values before making any changes. This confirms what the process is actually using, which may differ from environment variables if previous PUT calls were made.
Runtime application behavior varies by key, and worker changes can restart the affected worker. Test in a staging environment before applying to production.
If a key is not visible in GET /system/matcher, it is bootstrap-only. Update the environment variable and restart the service — there is no runtime path for those values. A visible key can still be bootstrap-only when its documentation says so: the registered Swagger keys accept a runtime PUT but only take effect after a restart.

Next steps


Multi-tenant mode

Enable and configure tenant isolation.

Exception routing

Configure how exceptions are dispatched to external systems.

Match rules

Configure transaction matching rules.

Security

Authentication, authorization, and data protection.