Change Center is a controlled workflow for configuration changes. Instead of sending an edited file directly to a server, you create a change request that can be reviewed, validated, approved, deployed in stages and rolled back from one place.
The workflow is available from the HAProxy, NGINX, Apache and Keepalived configuration editors.
It is designed for both standalone servers and HA clusters. When the selected server is a cluster master, Change Center captures the existing master/slave topology and tracks every target separately. You can see which node was validated, which batch is running, the health-check result and the exact output of every operation.
Creating a change does not modify the live configuration. A server is changed only after the request has passed validation and the deployment is started.
Direct configuration editing is useful for a quick change on one server, but it gives an operator very little protection when several nodes, reviewers or maintenance windows are involved. Change Center adds the missing safety and visibility around the same configuration workflow.
| Direct deployment | Change Center |
| The edited file is applied immediately. | The candidate is stored as a draft and can be reviewed before any server is changed. |
| The operator must coordinate cluster nodes manually. | Cluster targets, order, batches, canaries and exclusions are recorded in the rollout plan. |
| Errors are discovered during or after the update. | The candidate is validated on every included target before deployment. |
| The previous state must be found and restored manually. | A separate pre-change snapshot is captured for every target and used for rollback. |
| It is difficult to reconstruct who changed what and why. | The diff, author, approver, target results and timeline remain attached to the change. |
| Later manual edits may remain unnoticed. | Drift detection compares the live file with the deployed baseline. |
- Create: edit a configuration file and save the candidate as a named change request.
- Validate: Roxy-WI checks the candidate on every included rollout target without replacing the live file.
- Approve, when required: another administrator reviews the highlighted diff and approves the request.
- Deploy or schedule: run the change now or assign a start time and an optional maintenance-window end.
- Observe: follow every node, batch and health check in the change details and timeline.
- Control: pause between batches, promote a manually gated rollout, retry a node or roll back when needed.
- Verify: use drift detection to confirm that deployed nodes still match the approved configuration.
A typical successful lifecycle is Draft → Validated → Approved (if required) → Deploying → Deployed. Validation, deployment and rollback failures have their own states, so a green success message is never used to hide a failed target.
Group deployment policy
In 9.1, a super administrator can choose how each group deploys HAProxy, NGINX, Apache and Keepalived configurations. Open Admin area → Groups, use the group's Actions → Configure deployment policy menu, select a mode for each service and click Save policy.
| Mode | Effect |
|---|---|
| Direct and Change Center | Allow direct configuration deployment and creation of Change Center requests. This is the default for existing and new groups. |
| Change Center required | Block direct configuration deployment for this service and group. Validate in the editor, then create a change and deploy it through Change Center. |
| Direct deployment only | Allow direct deployment and block creation of new Change Center requests for this service and group. |
Configuration checks remain available in every mode. Policies are enforced by the server as well as reflected in the interface. Change Center still requires an active Premium subscription; selecting a policy does not activate it. Confirm availability before requiring Change Center for a group.
Background tasks in 9.1
Change Center requires Premium. From Roxy-WI 9.1, validation, deployment, rollback, resume, promotion, per-node retry/rollback/include and drift checks run as durable Operations tasks through RabbitMQ.
After starting an action, follow its operation ID, queued/running/completed state and failure message in the change details and timeline. You may close the page and reopen it to resume progress updates. A queued task has not yet applied the change. Approval, scheduling, cancellation and pause signals still return their immediate result.
API callers receive HTTP 202 with the change data and tasks_ids for queued actions. Inspect the change's operation field for task ID, status, active flag and error; accepting a task is not proof that deployment succeeded.
A Web restart does not interrupt queued work. If Operations stops, its lease expires after ROXYWI_OPERATIONS_LEASE_SECONDS (300 seconds by default). Work that had started is marked interrupted for inspection before retry/resume/rollback; it is not automatically deployed again. Pending work can run after Operations returns. The maintenance window is checked again when scheduled work leaves the queue.
Scheduler retains completed Change Center task history for 30 days and prunes hourly, preserving active tasks and the latest task for each change. ROXYWI_CHANGE_HISTORY_RETENTION_DAYS changes this period; 0 disables cleanup. Changes, configuration snapshots and their audit timelines are retained.
- Open the configuration editor for the required server and service.
- Select the configuration file when the service supports multiple files, then make your edits.
- Click Create change.
- Enter a clear name and description. Explain the intent and the expected result, not only the lines that changed.
- Select the action: Save, Reload or Restart.
- Select the execution mode and, when needed, configure batches, concurrency, canaries, excluded nodes, health checks, approval and notification recipients.
- Create the request. Roxy-WI opens Change Center, where you can inspect and validate it.
The target list is a snapshot of the topology at creation time. If the master/slave topology changes before deployment, create a new change so that the rollout plan and rollback snapshots match the current cluster.
Click Validate while the change is in Draft or Validation failed. Roxy-WI runs the service-specific configuration check on every included node. An excluded slave is skipped and its reason remains visible in the rollout table.
If any target rejects the candidate, the change becomes Validation failed. Open the details to see the result for that target. Retry validation when the failure was temporary; when the candidate itself is invalid, correct it in the configuration editor and create a new change. No live configuration is replaced during this step.
When Require approval by another administrator is enabled, a successfully validated change becomes Pending approval. An administrator with access to the same group can approve it, but the author cannot approve their own request. This provides a real four-eyes review instead of a self-confirmation checkbox.
| Setting | How it works |
| Rolling | Deploys the configuration in batches. With the automatic batch size, one node is processed at a time. This is the safer default for a live cluster. |
| Parallel | Processes several targets concurrently, up to the configured maximum. Use it when speed is more important and the service can tolerate simultaneous changes. |
| Canary | Deploys selected slave nodes in the first batch. If the canary fails validation, deployment or health checks, the remaining nodes are not changed. |
| Manual promotion | Stops after a successful batch with Awaiting promotion. Inspect the service, then click Promote to continue with the next batch. |
| Exclude | Temporarily removes an unavailable slave from this rollout. The master or a standalone target cannot be excluded. |
For a master/slave cluster, slaves are processed before the master. A target that already reached Deployed is not applied again when an interrupted rollout is resumed.
Health-check modes are Full (configuration and service state), Configuration only, Service only and None. You can also configure retry attempts and the delay between attempts. For a save-only action, no runtime service check is required.
A validated or approved change can be deployed immediately or scheduled. The scheduling dialog uses your browser's local time and can include a maintenance-window end. If the scheduler cannot start the change before that deadline, the request becomes Schedule missed instead of being deployed outside the approved window.
Pause is safe by design: it requests a stop after the currently running batch, rather than interrupting an upload in the middle. The status first becomes Pause requested and then Paused. Use Resume to continue from the remaining targets. When manual promotion is enabled, use Promote after reviewing the completed batch.
If validation, deployment or rollback is interrupted, inspect the operation status and target results after worker recovery. The default Operations lease is five minutes. Recovery does not determine the remote state for you; verify the configuration before retrying, resuming or rolling back.
At creation time, Change Center downloads and stores the current configuration separately for every included target. These snapshots are the rollback source; the application does not assume that all cluster nodes started with identical files.
If deployment or a post-deployment health check fails, the rollout stops and Roxy-WI automatically attempts to restore every target affected by that attempt. The final state distinguishes Auto rolled back from Auto rollback failed, and the per-node output explains what succeeded and what still needs attention.
You can also roll back a completed change, or roll back one target from the details view when the workflow state allows it. After a partial failure, use the per-node actions to retry, roll back, exclude or include a slave without repeating successful targets unnecessarily.
Configuration drift means that the file currently present on a target no longer matches the configuration that Change Center deployed. This can happen after a manual SSH edit, another automation tool, a package script or an incomplete recovery.
Click Check drift on a deployed change. Roxy-WI downloads the current file from every deployed, non-excluded target and compares it byte-for-byte with that change's deployed draft. The result is shown for the whole change and for each target:
- In sync: all checked files match the deployed baseline.
- Drift detected: at least one file differs; open the details to view the highlighted diff.
- Check failed: Roxy-WI could not read or compare at least one target.
- Not checked: no drift comparison has completed yet.
Drift detection is intentionally available only after a successful deployment and only while deployed targets exist. It reports unexpected changes; it does not overwrite them automatically. Review the diff, then create a new change or perform an explicit rollback.
The timeline records creation, validation, approval, scheduling, every rollout batch, target results, pause and promotion, rollback and drift events. The global Audit history can be filtered by text, service, event, status and date, and deployment reports can be exported for incident review or compliance records.
During change creation, select the exact recipients that should be notified. Email recipients come from users in the active group. Telegram, Slack, Mattermost and PagerDuty destinations come from Monitoring → Channels. Change Center sends notifications for scheduled or missed deployments, deployment and rollback results, and drift state changes.
Webhooks are configured from the Change Center overview. Each webhook has its own event selection, enabled state, TLS verification option and optional signing secret. Delivery is queued and retried, so a slow notification endpoint does not block the deployment itself.
| Status | Meaning and next step |
| Draft | Edit the request or run validation. |
| Validation failed | Review the target output. Retry a temporary failure, or correct the configuration and create a new change. |
| Validated | The request is ready to deploy or schedule without approval. |
| Pending approval | Another administrator must review and approve the request. |
| Approved | The approved request is ready to deploy or schedule. |
| Scheduled | The scheduler will claim the request at the selected time. |
| Deploying | One or more rollout targets are being processed. |
| Pause requested | The active batch is allowed to finish; click Resume to cancel the pending pause. |
| Paused | The rollout stopped safely between batches and can be resumed. |
| Awaiting promotion | A batch completed and requires manual promotion before the next batch. |
| Deployment interrupted | Verify remote state, then resume, retry a target or roll back. |
| Deployed | All included targets completed successfully; drift detection is available. |
| Auto rolled back | Deployment failed and all affected targets were restored automatically. |
| Auto rollback failed | Deployment and at least one automatic restore failed; inspect per-node output. |
| Rolling back / Rolled back | An explicit restore is running / completed successfully. |
| Rollback failed | At least one target could not be restored; correct the cause and retry. |
| Schedule missed | The maintenance window expired or the scheduled deployment could not start; inspect the output and reschedule or deploy manually. |
| Cancelled | The request was closed without deployment. |
- Roxy-WI must have working SSH access to every included target and permission to read, validate and replace the selected configuration file.
- The service and its configuration path must be configured correctly on every target.
- Run one dedicated Scheduler (
python3 roxy_wi.py scheduler), Operations (python3 roxy_wi.py operations) and RabbitMQ. Keep Scheduler separate from Web workers. All roles must share the database, encryption key, saved configurations andlib_path;lib_path/change-locksrequires shared advisory file locks. See deployment and health checks. - The scheduler checks scheduled deployments every 15 seconds, notification deliveries every 10 seconds and deployed configurations for drift every five minutes.
- Before a high-risk rollout, use a canary slave, rolling batches, full health checks and manual promotion.
- Do not disable health checks only to make a failing rollout pass. Fix the validation, service-state or SSH problem shown in the target output.
- If a rollout was interrupted, inspect the remote file and per-node status before using Recover, Resume or Retry.
The main advantage of Change Center is not simply another way to upload a configuration. It makes the entire delivery decision visible: what will change, who reviewed it, where it will be deployed, how quickly it will move through the cluster, whether every node stayed healthy and whether the live configuration still matches the approved result later.