Problem Statement
Worker concurrency is currently configured through environment variables, which requires deployment-level access and a service restart to adjust runtime behavior. This makes operational tuning difficult for system administrators who need to react to workload changes, resource constraints, or production incidents from the application interface.
Proposed Solution
Move worker concurrency settings into PostgreSQL and expose them through an administrative frontend UI.
The implementation should:
- Persist worker concurrency configuration in the database.
- Provide backend API endpoints for authorized administrators to read and update concurrency settings.
- Add a frontend administration interface for managing worker concurrency values.
- Ensure the worker reads concurrency configuration from the database instead of relying exclusively on environment variables.
- Define safe validation rules, including minimum and maximum accepted values.
- Preserve a sensible bootstrap/default value for fresh installations.
- Document the new configuration flow and any remaining environment variables.
Alternatives Considered
Keeping concurrency configuration in environment variables is simpler but requires infrastructure access and redeployment or restart for changes. This does not meet the operational requirement that system administrators should be able to adjust worker behavior from the frontend.
Additional Context
The existing WORKER_CONCURRENCY environment variable is documented as the maximum number of workflow runs processed in parallel by the worker. This feature should replace or demote that variable to an initial/default bootstrap mechanism while making the database-backed configuration the runtime source of truth.
Problem Statement
Worker concurrency is currently configured through environment variables, which requires deployment-level access and a service restart to adjust runtime behavior. This makes operational tuning difficult for system administrators who need to react to workload changes, resource constraints, or production incidents from the application interface.
Proposed Solution
Move worker concurrency settings into PostgreSQL and expose them through an administrative frontend UI.
The implementation should:
Alternatives Considered
Keeping concurrency configuration in environment variables is simpler but requires infrastructure access and redeployment or restart for changes. This does not meet the operational requirement that system administrators should be able to adjust worker behavior from the frontend.
Additional Context
The existing
WORKER_CONCURRENCYenvironment variable is documented as the maximum number of workflow runs processed in parallel by the worker. This feature should replace or demote that variable to an initial/default bootstrap mechanism while making the database-backed configuration the runtime source of truth.