rConfig V8 Pro Docker Deployment: Containerized Network Management Setup

This guide covers installing, running and updating rConfig V8 Professional with Docker Compose, using the rconfig8docker repository. See also the full Linux installation guide and the update process.

Before proceeding, review the OS Configuration guide and Security Hardening guidelines.

rConfig V6 Core Docker Deployment

rConfig V6 Core represents the community edition of rConfig. Deployment documentation is maintained in the GitHub repository. Consult the repository for complete installation procedures and configuration guidance.

From V8.4.1: hardened Docker image

• Horizon, the scheduler and the web server’s workers run as www-data, and Redis runs as redis. Nothing in the app runs as root.
• Redis requires a password. The container creates it on first start and saves it as REDIS_PASSWORD in data/.env.
• data/storage and data/.env belong to www-data (uid 1000) with no access for other users.
• Service output goes to docker compose logs app, not to files in storage/logs.
• docker compose ps shows the container’s health.
• The database port is no longer published on the host, and MariaDB is pinned to a major version.
• An optional SNMP trap receiver is available.
• xFTP and Vector Hub are not supported in Docker.
• xdebug is no longer in the image.

Existing installs: follow Updating. The first update to V8.4.1 has extra checks.

Complete the rConfig Professional Docker deployment with the following steps. Run the docker commands as root on the Docker host. For offline environments, see the V8 Pro Offline Installation instructions.

1. Clone the repository
2. Log in to the rConfig registry
3. Configure environment variables
4. Start the containers
5. Complete the installation
6. Check the container is healthy
7. Access rConfig V8 Professional

SSL/TLS Configuration

SSL/TLS encryption is not configured during default rConfig deployment. SSL/TLS implementation is strongly recommended and may utilize organizational PKI infrastructure or certificate authorities such as Let’s Encrypt. SSL/TLS configuration methodology is deferred to organizational security policies and infrastructure requirements. Contact rConfig support for SSL/TLS implementation assistance for your rConfig V8 deployment. Configuration guidance is available in the SSL Configuration Documentation.

Supported Container Paths & Volumes

The rConfig V8 Pro container runs the application at the fixed in-container path /var/www/html/rconfig8. The supplied docker-compose.yml mounts persistent data from the data directory of your rconfig8docker clone: data/.env, data/storage and data/db_data. Our container images, update procedures and support processes are built and tested only against this layout.

Do not change the in-container application path or remap the volume mount targets. Changing these paths, for example by editing the volume lines in docker-compose.yml, symlinking the data directory, or running the image with custom mount points, will cause updates to fail and places your deployment outside the supported configuration.

Deployments that deviate from the default container paths or volume layout are not eligible for support under your subscription agreement. If you have a legitimate requirement to customise the layout, contact prosupport@rconfig.com before deploying.

Docker Deployment Overview

Note

rConfig V8 Professional is a commercial product requiring an active subscription. Purchase subscriptions through: rConfig Pricing. A valid license key is required for Docker image download and execution. For additional information, contact info@rconfig.com.

Prerequisites

1. Docker and Docker Compose are installed on the target server.
2. The contents of the repository’s data directory are in the data directory on your server. Cloning the repository and using its data directory as it is works.
3. An rConfig Professional subscription, with the registry username and token rConfig sent you.
4. root on the Docker host.

The examples use the Docker Compose plugin (docker compose). The standalone docker-compose binary works the same way; use whichever is installed, and don’t mix them in scripts.

Deployment Procedures

Clone the Repository

git clone https://github.com/rconfig/rconfig8docker.git
cd rconfig8docker

Log in to the rConfig Registry

docker login reg.rconfig.com:8443
Username: # the robot account username rConfig sent you
Password: # the token rConfig sent you

Configure Environment Variables

Edit data/.env:

APP_DEBUG=true/false
APP_URL=http://yourFQDNorIP.domain.com
DB_HOST=db  # The database container, or another server if you use an external database
DB_PORT=ENVOY_DB_PORT # 3306 for MariaDB unless customised
DB_DATABASE=ENVOY_DB_DATABASE # Any name for a new database
DB_USERNAME=ENVOY_DB_USERNAME # The database user
DB_PASSWORD=ENVOY_DB_PASSWORD # The database user's password
RCONFIG_API_TOKEN=ENVOY_API_TOKEN # From the rConfig portal

Leave APP_KEY and REDIS_PASSWORD empty. The container generates both on first start and saves them in data/.env.

Start the Containers

From the root of the clone:

docker compose up -d

Watch the app container start. It is ready when the log shows Starting services...:

docker compose logs -f app

Complete the Installation

Run the setup commands. Always run artisan as www-data (-u www-data), never as root, so the files it writes stay owned by the app:

docker compose exec -u www-data app php artisan migrate --force
docker compose exec -u www-data app php artisan rconfig:sync-tasks
docker compose exec -u www-data app php artisan rconfig:update-rbac-data
docker compose exec app supervisorctl restart horizon

From V8.4.1 you don’t need to chown or chmod anything, and you don’t run key:generate. The container sets the owner and permissions of data/storage and data/.env on every start, and creates APP_KEY itself.

Check the Container is Healthy

docker compose ps

The status column should show (healthy) within about two minutes. If it shows (unhealthy), see Container health.

Access rConfig V8 Professional

Open the URL you set as APP_URL and log in with the default credentials:

• Username: admin@domain.com
• Password: admin

After first login, follow the security hardening guidance to align the container with enterprise policies.

Post-Installation Verification

1. Change the default account credentials.
2. Check the version number on the Settings page.
3. Open External Tools > Queue Manager and check that Horizon shows as active on the dashboard.
4. Check the services in the container:

docker compose exec app supervisorctl status

Expected output (PIDs and uptimes differ):

apache2                          RUNNING   pid …, uptime …
cache-rebuild                    EXITED    …
horizon                          RUNNING   pid …, uptime …
redis                            RUNNING   pid …, uptime …
schedule-run                     RUNNING   pid …, uptime …

cache-rebuild rebuilds the config, route and view caches once on start, then exits. schedule-run runs php artisan schedule:work, which takes the place of a cron line. If the SNMP trap receiver is on, rconfig-snmp-trap is also listed as RUNNING.

Administrative Account Security

Establish a new administrative user account through the settings interface as an initial configuration step. Remove the default administrative account after verifying the new account has appropriate privileges and authentication functions correctly.

Next Steps:

• Understand V8 Features and Capabilities
• Review Update Procedures
• Consider Vector Server Upgrade for enhanced capabilities

How the Container Runs

From V8.4.1:

• Horizon, the scheduler and the web server’s workers run as www-data, and Redis runs as redis. Nothing in the app runs as root. The Worker Privilege checks are for bare metal and show “Not applicable in Docker”; the container health check covers the same ground.
• Redis only listens inside the container and requires the password in REDIS_PASSWORD. Keep that line in data/.env: the container reuses it on every start and upgrade.
• data/storage and data/.env belong to www-data (uid 1000) with no access for other users: folders 0750, files 0640, stored device configs 0440. On the host they show as owned by whichever user has uid 1000. Host tools that read them as another non-root user lose access.
• The database is not published on the host. To reach it from the host itself, uncomment the 127.0.0.1:3360:3306 lines in docker-compose.yml. It then listens on 127.0.0.1 only.

Running artisan

Run artisan as www-data:

docker compose exec -u www-data app php artisan <command>

As root, artisan can create root-owned files in storage that the app then cannot write. Restart Horizon with supervisorctl, which runs as root in the container:

docker compose exec app supervisorctl restart horizon

Logs

From V8.4.1, Horizon, scheduler, web server and Redis output goes to the container’s output, not to files in storage/logs. There is no horizon.log in Docker.

docker compose logs app            # all service output
docker compose logs -f app         # follow it
docker compose logs --since 1h app

The app’s own logs (laravel-YYYY-MM-DD.log and the others) stay in data/storage/logs and show in the System Log Viewer. Docker keeps the service output with its logging driver, so set size limits there (for example max-size and max-file for the default json-file driver).

Container Health

From V8.4.1, the image has a Docker health check. It runs every 60 seconds, after a 120 second start period, and marks the container unhealthy after three failures in a row. It fails if:

• Horizon or the scheduler is not running as www-data
• Horizon or the scheduler is running as root
• the SNMP trap receiver is on but not running as www-data
• Redis answers without a password, or does not answer
• the web server returns an error (HTTP 500 or above) for /login

docker compose ps shows the result. To see why the container is unhealthy:

docker inspect --format '{{json .State.Health}}' rconfig8docker-app-1

Use the name docker compose ps shows if yours differs. The Output of each entry in Log lists the problems, for example Horizon is not running as www-data. Check docker compose logs app for the cause.

SNMP Trap Receiver (Optional)

From V8.4.1, the container can run the SNMP trap receiver:

1. Set RCONFIG_SNMP_TRAPS=true in data/.env.
2. Uncomment the - "162:1162/udp" line under ports: in docker-compose.yml.
3. Run docker compose up -d.

The receiver runs as www-data on UDP 1162 inside the container, and the host’s UDP 162 is mapped to it. rConfig identifies devices by the source address of their traps. Docker keeps that address with its default iptables networking. If your Docker host uses the userland proxy instead, every trap appears to come from the Docker bridge; in that case run the app container with network_mode: host.

See SNMP Traps for filters and actions.

Not Supported in Docker

• xFTP (the TFTP, FTP and SFTP services) runs as separate containers controlled through the host’s Docker socket. Giving the rConfig container that socket would give it root on the host, so the xFTP pages say it is unavailable here. Run xFTP on a bare-metal rConfig install instead.
• Vector Hub needs systemd and a root helper on the server, which a container does not have. Use a bare-metal rConfig install for Vector Hub.

Updating

October 2026 PHP security advisory (CVE-2026-109618, CVE-2026-109619)

The rConfig image runs PHP as an Apache module, which the PHP project rates as the highest-risk setup for these vulnerabilities. See how to patch PHP for CVE-2026-109618 and CVE-2026-109619 for the Docker steps and interim workarounds.

Registry Version Discovery

docker login reg.rconfig.com:8443

Available Versions

Contact info@rconfig.com for available container versions and tags if registry browsing commands are not supported by your configuration. The :latest tag references the most recent stable release.

Update Steps

Run these from the root of your rconfig8docker clone.

1. Wait until the queue is empty. Settings > Queue Manager should show no pending jobs. Redis lives inside the app container, so queued jobs, sessions and cache are cleared whenever the container is recreated.

2. Back up the database and the data directory:

   docker compose exec db sh -c 'mariadb-dump -uroot -p"$MARIADB_ROOT_PASSWORD" --all-databases' > rconfig-db-backup.sql
   tar czf rconfig-data-backup.tar.gz data/.env data/storage

3. Check which MariaDB version is running now:

   docker compose exec db mariadb --version

4. Update docker-compose.yml from the repository. Then set its db image to your current MariaDB major version or a later one, for example mariadb:12.3 if step 3 shows 12.3 or anything older. If step 3 shows a newer major (for example 13.0), use that one (mariadb:13.0). Never set a lower major than the one in use: MariaDB cannot move data back to an older major. Copy any local changes, such as other ports, from your old file.

5. If anything on the host connected to the database on port 3360, uncomment the 127.0.0.1:3360:3306 lines. From V8.4.1 the database is no longer published by default, and when enabled it listens on 127.0.0.1 only.

6. Pull the new image and recreate the containers:

   docker compose pull
   docker compose up -d
   docker compose logs -f app   # wait for "Starting services..."

   On the first start of the V8.4.1 image, the container fixes the owner and permissions of everything in data/storage (this can take a few minutes on a large install), and adds REDIS_PASSWORD to data/.env.

7. Run the database migrations and restart Horizon. Migrations are not run automatically:

   docker compose exec -u www-data app php artisan migrate --force
   docker compose exec app supervisorctl restart horizon

8. Check that docker compose ps shows (healthy), Settings > Queue Manager shows Horizon as active, and the version on the Settings page is the new one.

Rollback

To go back to the previous image, set the app image: line in docker-compose.yml to the previous version’s tag and run docker compose up -d. You can leave data/.env and data/storage as they are.

An image older than V8.4.1 runs Redis without a password and runs Horizon and the scheduler as root again, so treat it as a short-term step. If the data itself needs restoring, use the backups from step 2.

Update Considerations

Always review release notes prior to updating to understand breaking changes or special migration requirements. Test updates in non-production environments when operationally feasible.

Common gotchas

• The rConfig container runs at the fixed in-container path /var/www/html/rconfig8. Do not remap volumes or rename directories: update scripts and support processes depend on this exact layout.
• After the first docker compose up -d, run the setup commands in Complete the Installation before rConfig is usable. Skipping them leaves the database uninitialised.
• Running docker compose exec app php artisan … without -u www-data runs it as root and can leave root-owned files in storage.
• Deleting REDIS_PASSWORD from data/.env makes the container create a new one on the next start. Keep the line.
• If the container starts but the UI is unreachable, check the ports: mapping in docker-compose.yml (8080:80 by default) and that your host firewall allows it.

What’s next

• V8 Pro Installation (Linux) - Standard bare-metal installation guide for comparison
• V8 Pro Update Process - Updating a bare-metal install
• Horizon Queue Manager - Monitoring the queue
• OS Configuration - Operating system prerequisites and security hardening