# Roxy-WI Review: Multi-Server Proxy Management and Change Control

> Roxy-WI is a self-hosted Python web interface for HAProxy, NGINX, Apache, and Keepalived infrastructure. It centralizes server access, configuration review, staged deployment, service diagnostics, and access control, although some deployment features require Premium.

**roxy-wi/roxy-wi** — Web interface for managing Haproxy, Nginx, Apache and Keepalived servers

- Repository: https://github.com/roxy-wi/roxy-wi
- Website: https://roxy-wi.org
- Stars: 1,830 · Forks: 285
- Language: Python
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/roxy-wi-roxy-wi

## The Multi-Proxy Operations Problem Roxy-WI Addresses

Roxy-WI targets operators who already run proxy and high-availability infrastructure across multiple servers. Its purpose is not to replace HAProxy, NGINX, Apache, or Keepalived. Instead, it places management, inspection, and deployment controls around those existing services. The supported service scope makes it relevant to teams that would otherwise open several SSH sessions and edit configuration files independently.

The interface is intended for both individual administrators and teams with divided responsibilities. Server groups, roles, and service permissions can assign access at a more useful boundary than unrestricted shell access. OIDC and LDAP integration provide authentication options, while monitoring, traffic metrics, notifications, certificate management, configuration history, and backup destinations can be added as operational needs grow.

The central distinction is controlled change. The README says Roxy-WI can compare configuration differences, validate candidate configurations, require approval, retain an audit trail, and deploy changes in stages with canaries and batches. That workflow is most relevant to production configurations where a syntactically valid edit can still cause a bad deployment across several nodes. Change Center is a Premium capability, so this is the main commercial boundary to evaluate before deciding whether the project fits a non-commercial or cost-sensitive deployment.

## Roxy-WI Service Topology and Request Flow

The repository layout shows a Flask-based Python application rather than a command-line proxy manager. `app/` contains the web application area, while `roxy_wi.py`, `roxy_wi_gunicorn.py`, and `roxy_wi_health.py` provide top-level entry or health-related modules. `scheduler_runner.py` and `service_event_consumer.py` are separate processes, matching the README statement that a Compose deployment starts background workers. The dependency list includes Gunicorn, APScheduler, Pika, aio-pika, WebSockets, Peewee, PyMySQL, Paramiko, and Ansible Runner.

A visible change workflow begins with a draft rather than the running configuration. The documented sequence is to review the diff, validate targets, approve when required, deploy in stages, inspect results and drift, and roll back a failed change. Each target produces its own result according to the Change Center guide linked by the README. This separates intent, authorization, and execution instead of treating a save as an immediate production replacement.

Managed servers are connected over SSH. Roxy-WI then manages service configurations and actions for HAProxy, NGINX, Apache, and Keepalived. For HAProxy configuration files, it can read ordered sources discovered from systemd, including environment files and overrides, or from Docker. When available, it compares those discovered sources with the running HAProxy process. The architecture therefore combines a browser interface, Python workers, SSH-based server operations, persistent application data, and optional broker and database services.

## Running the First Roxy-WI Interface with Compose

The local evaluation path requires Git, Python 3.10 or later, Docker with Linux containers, and Docker Compose 2.24.4 or later. The following documented commands clone the repository and start the quickstart environment. The first build downloads application dependencies, so it will not finish immediately.

```bash
git clone https://github.com/roxy-wi/roxy-wi.git
cd roxy-wi
python3 docker/quickstart.py start
python3 docker/quickstart.py password
```

The README states that this builds the current checkout, starts the application and background workers, and exposes the interface only at `https://localhost:8443`. Open that address, accept the local evaluation certificate, and sign in as `admin` with the generated password. Secrets and application data persist between starts, which means restarting the quickstart does not reset its state.

This is an evaluation path based on SQLite and local HTTPS. It does not claim to be a production deployment guide. For persistent infrastructure deployments, the README points to its Compose guide for MariaDB, HTTPS, storage, and RabbitMQ. The Helm path is intended for Kubernetes and has a different configuration surface.

## Installing Roxy-WI 9.1 on Kubernetes

The published Helm chart can install Roxy-WI into Kubernetes. Version `9.1.0` of the chart defaults to the published `ghcr.io/roxy-wi/roxy-wi:9.1.0` application image. Before installation, the Helm deployment guide requires a prepared `roxy-wi-values.yaml` containing application secrets, RabbitMQ, persistent storage, database settings, and HTTPS ingress.

```bash
helm upgrade --install roxy-wi oci://ghcr.io/roxy-wi/roxy-wi-charts \
  --version 9.1.0 --namespace roxy-wi --create-namespace \
  --values roxy-wi-values.yaml --wait --wait-for-jobs --timeout 10m
```

The command installs or upgrades the release in the `roxy-wi` namespace, creates that namespace when necessary, and waits for resources and jobs. SQLite is the chart default for one Web replica. RabbitMQ is provisioned separately, and MariaDB or MySQL can be supplied externally. Existing installations must follow the separate Helm update procedure before an upgrade.

Linux package installation is also supported, but the README does not reproduce its commands. It directs administrators to the deployment platforms and installation page and separately links an update guide. That omission matters for evaluation: the Compose command is explicit, while a package-based installation requires another documented source and may involve a different configuration process.

## HAProxy Configuration Discovery and Deployment Scope

HAProxy file handling is one of the more specific parts of the documented design. The `Use multiple configuration files` option is disabled by default and belongs to the settings of an individual HAProxy service on the selected server. Once enabled, Roxy-WI reads ordered configuration sources from systemd or Docker rather than maintaining a separate argument list inside the interface. From systemd, the documented sources can include environment files and overrides. If only the main file is present, the settings panel explains how to add a directory with `-f` through the service or container command.

The configuration workspace supports searchable sections, source view, and editing through a form or text editor depending on how a section was created. A deployment can then move through Change Center rather than immediately replacing the active configuration. Canary selection, batches, pauses, per-target checks, failed-change recovery, and rollback are documented for that path.

This design creates a requirement for operators to understand how their underlying daemon receives configuration files. Roxy-WI can detect and compare sources, but it cannot remove the need for correct systemd units, Docker commands, or `-f` arguments outside its interface. The README does not document a separate rollback mechanism for ordinary direct service edits, so teams should not assume every editing path has Change Center's review and recovery controls.

## Operational Boundaries of Roxy-WI's Management Model

Roxy-WI is the wrong tool when an operator needs only a text editor and direct SSH access for one proxy server. Its server groups, roles, permissions, worker processes, persistent data, database options, RabbitMQ dependency, and deployment controls add more moving parts than a manual configuration workflow. Kubernetes users also face a separate configuration surface because the Helm chart requires values for secrets, storage, messaging, databases, and ingress.

The shared demo has a different security and data model from a local installation. It resets hourly and should contain demonstration data only. Its browser credentials are published as `admin` / `admin`, so it is not suitable for evaluating confidential configuration or realistic access-control behavior.

Documentation also has boundaries. The README points to external guides for package installation, Helm updates, first-server setup, Change Center, and Compose operations. It does not establish which direct configuration edits are audited, nor does it claim that rollback is available for every service action. Monitoring and notifications are described as capabilities that can grow with use, but the README excerpt does not specify their deployment requirements. Buyers should distinguish an advertised management area from a feature included in the open-source release, especially because Change Center is explicitly Premium.

## Roxy-WI Versus Direct SSH-Based Proxy Administration

Direct SSH administration is the clearest alternative. With SSH, an operator edits the files and service definitions that HAProxy, NGINX, Apache, or Keepalived already consume, then invokes the relevant service or validation commands. This approach has a smaller application footprint and keeps deployment behavior close to the host, but it does not provide Roxy-WI's browser-based groups, role assignments, configuration diff workflow, staged canary rollout, per-node results, or interface-level drift review.

Roxy-WI takes the opposite approach. It centralizes control in a self-hosted Python application and delegates execution to connected infrastructure over SSH. That creates a consistent operational surface across several server types and environments, at the cost of persistent application state, worker processes, authentication configuration, and dependency management. For a team repeatedly changing many production nodes, those extra parts support a control plane. For a small site with infrequent edits, they can outweigh the benefit.

A Helm deployment is also a different alternative to direct administration. The chart packages Roxy-WI for Kubernetes and can use SQLite for one Web replica or an external MariaDB or MySQL database, but it does not remove the target proxy and Keepalived servers from the design. Roxy-WI remains an interface to existing infrastructure rather than a Kubernetes-native replacement for those services.

## Roxy-WI Releases, Upgrades, and Apache-2.0 Obligations

The repository is not archived, and its last push was on 2026-10-15. Recent releases include v9.1.0 on 2026-10-01, v9.0.0 on 2026-09-05, and v8.3.0 on 2026-08-15. The current README explicitly applies to Roxy-WI 9.1 and later, which means instructions for older releases should not be assumed to match the latest interface.

Upgrade cost depends on deployment route. Package installations have a separate update guide, while existing Helm installations have a required update procedure. The README does not provide automatic migration commands, compatibility matrices, or rollback commands for application upgrades. Operators must therefore read the route-specific documentation and preserve their existing values and storage configuration. The Helm example pins chart and application versions, but a copied command should not be treated as a complete upgrade procedure for an existing installation.

Roxy-WI is licensed under Apache-2.0. The repository includes a `LICENSE` file, and the README displays the Apache 2.0 badge. The license governs use, modification, and distribution according to its own terms, including its notice and license-copy requirements. Subscription-dependent features are separate from the open-source license boundary: Apache-2.0 coverage of the repository does not itself establish that every feature advertised on the website is included without a subscription.

## Conclusion

Roxy-WI fits operators and teams that want one browser interface for existing HAProxy, NGINX, Apache, and Keepalived servers, especially where configuration review and staged deployment justify its operational scope. It is less suitable for a single manual proxy host or for operators seeking a fully open source version of every advertised control feature. Before adoption, verify the Premium boundary for the required workflow, prepare application secrets and persistent storage for the selected deployment, and confirm that target servers can be reached over SSH.

## FAQ

### How do I install Roxy-WI for a local evaluation?

Use the documented Compose quick start with Git, Python 3.10+, Docker, and Docker Compose 2.24.4+. Run `python3 docker/quickstart.py start` and then `python3 docker/quickstart.py password`, then open `https://localhost:8443` and sign in as `admin` with the generated password.

### Which proxy and high-availability services can Roxy-WI manage?

Roxy-WI manages existing HAProxy, NGINX, Apache, and Keepalived servers through its self-hosted web interface. Servers are connected over SSH.

### Does Change Center require a free Roxy-WI license?

The README states that Change Center requires Premium. Its draft, review, canary, batch, per-target result, recovery, and rollback capabilities should therefore be evaluated against the product's feature availability and pricing documentation.

### How does Roxy-WI discover multiple HAProxy configuration files?

After `Use multiple configuration files` is enabled, it reads ordered sources from systemd, including environment files and overrides, or from Docker. When available, Roxy-WI compares those sources with the running HAProxy process.

### Can Roxy-WI be deployed on Kubernetes with Helm?

The repository publishes a chart at `oci://ghcr.io/roxy-wi/roxy-wi-charts`. Its documented version `9.1.0` uses `ghcr.io/roxy-wi/roxy-wi:9.1.0` by default and expects values for secrets, RabbitMQ, storage, database settings, and HTTPS ingress.

## Sources

- [License: Apache-2.0](https://github.com/roxy-wi/roxy-wi/blob/master/LICENSE)
- [Project website](https://roxy-wi.org)
- [README](https://github.com/roxy-wi/roxy-wi/blob/master/README.md)
- [Releases](https://github.com/roxy-wi/roxy-wi/releases)
- [roxy-wi/roxy-wi on GitHub](https://github.com/roxy-wi/roxy-wi)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/roxy-wi-roxy-wi