Docker deployment limitations in rConfig V8 Core

After reading this page you can decide whether Docker is the right way to run rConfig V8 Core for your environment. It explains the known limitations of containerized deployments, which scenarios Docker suits well, and how to troubleshoot the issues that come up most often.

This page covers deployment considerations and known issues. If you have already decided to run rConfig in a container and want the setup steps, see the V8 Core Docker setup guide.

Why Docker adds complexity

Docker places several abstraction layers between rConfig and the underlying infrastructure. Each layer adds isolation but also adds overhead, new failure modes, and harder troubleshooting.

Layer	What it adds	Where it bites
Container runtime	Lifecycle, resource allocation, process isolation	Overhead and failure modes absent from bare installs
Network abstraction	Bridge, overlay, and macvlan virtual interfaces	Interferes with device connectivity and source addressing
Storage abstraction	Volume mounts and storage drivers (overlay2, aufs, devicemapper)	Poor performance with large config repositories
Process management	PID namespace isolation	Edge cases with Supervisord workers and PHP-FPM pools

These overheads compound when something goes wrong, which is why a problem that takes minutes to resolve on a server install can take days inside a container.

Known production issues

rConfig support has documented recurring, often unresolvable issues in production Docker deployments.

Persistent storage problems

Volume mounts for configuration repositories show permission issues, filesystem locking, and performance degradation that are hard to reproduce.

Configuration downloads succeed but files cannot be read back.
Intermittent “permission denied” errors despite correct container user configuration.
File corruption in the config repository under high concurrent write load.
Filesystem lock timeouts during compliance checks.

Production repositories hold tens of thousands of files in deep directory hierarchies. Storage drivers tuned for image layers handle this access pattern poorly, and UID mapping between container and host creates race conditions under concurrent access.

Network connectivity problems

Docker’s networking can interfere with device connections, especially across complex topologies or with protocols that expect specific source addressing.

SSH connections to devices time out in Docker but succeed from the host.
SNMPv3 authentication failures specific to the containerized deployment.
The source IP presented to devices differs from the configured address.
Intermittent failures to devices behind NAT or across VPN tunnels.

Docker modifies routing, source address translation, and connection tracking, and its iptables rules can interact unpredictably with host firewall configuration.

Queue worker instability

Laravel Horizon queue workers can become unresponsive in some Docker deployments.

Queue depth grows even though workers show as running.
Worker processes consume 100% CPU but process no jobs.
Jobs stick in “processing” indefinitely.
Supervisor reports workers healthy while no processing occurs.

The interaction between Supervisord, Docker’s process management, PHP-FPM pools, and signal handling produces states that workers cannot recover from. When this happens, background work such as downloads, compliance checks, and scheduled tasks stops.

Performance degradation under load

Layered filesystem and network abstractions add overhead that becomes pronounced when downloading thousands of configurations at once or running intensive compliance checks.

Configuration download throughput 30 to 50 percent lower than on server installs.
Compliance checks take noticeably longer.
Database query performance lags a non-containerized database.
Intermittent timeouts during high-concurrency operations.

The practical effect is lower scale on identical hardware: an estate that runs reliably at 500 devices may start failing at 1,000 devices in a container.

Resource limit unpredictability

Docker memory and CPU limits interact with PHP-FPM pools, database connections, and worker allocation to create performance cliffs.

The application performs well, then fails completely at a specific load threshold.
Memory limits trigger container restarts during operations that succeed on server installs.
CPU throttling causes cascading timeouts.
No reliable way to size limits through testing.

Docker enforces hard limits that terminate processes immediately, whereas a server install lets processes compete for resources and degrade gracefully.

Backup and restore complications

Backing up volumes, container state, and orchestration configuration together is harder than backing up a server install, and restores are more error-prone.

Backups complete but cannot be restored.
Restored containers behave differently from the originals.
Volume backups miss files that existed in the running container.
Database restore succeeds but the application cannot read the data.

Docker spreads state across filesystem layers, volumes, network definitions, and container configuration, all of which must be captured and restored consistently.

Logging and monitoring complexity

Pulling logs from containers and correlating events across multiple containers slows troubleshooting.

Relevant logs are hard to locate.
Container logs rotate away before an issue is detected.
Monitoring shows a container as healthy while the application inside has failed.
Events cannot be correlated across web, database, and worker containers.

Health checks that confirm a process exists do not confirm the application works, so failures hide behind a healthy status.

When Docker is a good fit

Docker is well suited to non-production scenarios where rapid iteration matters more than production reliability.

Use case	Good for	Accepted trade-offs
Development	Building integrations, testing customizations, evaluating features	Performance overhead and occasional instability
Lab and testing	Testing device configs, evaluating policies, training, demos	Instability does not affect production
Proof of concept	Evaluating rConfig with 10 to 50 devices before committing	Limited scale; plan a migration before production
Non-critical environments	Aligning with container standards where minor instability is acceptable	Some issues may need a migration to resolve

Recommended production deployments

For production environments managing 100 or more devices, deploy rConfig V8 Core on a traditional Linux host.

Physical dedicated servers give the highest performance and simplest support, and suit the largest estates (1,000+ devices).
Virtual machines (VMware, Hyper-V, KVM, Xen) balance flexibility and performance with snapshots and live migration, and suit most production estates (100 to 1,000+ devices).
Cloud VMs (AWS EC2, Azure VMs, GCP Compute Engine) deliver cloud benefits without container complexity, and can pair with managed databases such as RDS or Azure Database.

For install steps on a server, see the V8 Core installation guide.

Migrating from Docker to a server install

If you currently run production rConfig in Docker, plan a migration to a server install.

Document device count, user count, and operational patterns, and note any stability or performance issues.
Provision a VM or physical server that meets the system requirements and install a supported Linux distribution.
Schedule a maintenance window with enough time for migration and validation, and prepare a rollback plan.
Back up the Docker deployment, export the database, copy the configuration repository from the Docker volumes, install rConfig on the server, then import the database and config files and validate functionality before restoring service.
Monitor performance and confirm stability over several weeks.

Contact rConfig support for migration help at support@rconfig.com.

Best practices if you run Docker anyway

If you deploy rConfig in Docker despite the guidance above, apply these practices to reduce risk.

Resource allocation

Set memory limits to two to three times expected peak usage and allow CPU burst capacity.
Run rConfig in dedicated containers without competing workloads.
Track resource consumption over time and raise limits before hitting them.

Storage

Mount dedicated volumes for the configuration repository, database data, and logs. Avoid shared volumes and complex bind mounts.
Test storage drivers (overlay2, zfs, btrfs) against your workload, since performance varies with file access patterns.
Monitor volume I/O and latency, as degradation points to a driver limitation.

Networking

Use host networking for single-container deployments to remove abstraction layers that interfere with device connectivity.
Assign static IPs to containers that talk to devices expecting a specific source address.
Include diagnostic tools (tcpdump, netcat, traceroute) in the image.

Queue workers

Run queue workers in a dedicated container with their own resources and monitoring.
Tune Supervisor to restart failed workers aggressively, with short worker lifetimes (one to two hours) to prevent memory accumulation.
Add application-level health checks that confirm workers process jobs, not just that processes exist.

Monitoring and backup

Monitor container status, resource use, restart counts, and health checks, and check application responsiveness, database connectivity, and queue processing separately.
Aggregate logs centrally so rotation does not evict diagnostic data.
Test restore procedures monthly and store backups outside the Docker infrastructure.

Troubleshooting common Docker issues

Configuration files disappear after download

Check volume mount permissions and storage driver health.

Verify the volume mount configuration:

docker inspect <container_name> | grep -A 10 Mounts

Check volume permissions match the container user:

docker exec <container_name> ls -la /var/www/html/rconfig/storage

Test volume persistence across restarts:

docker exec <container_name> touch /var/www/html/rconfig/storage/test
docker restart <container_name>
docker exec <container_name> ls /var/www/html/rconfig/storage/test

Review the storage driver for errors:

docker info | grep "Storage Driver"
journalctl -u docker | grep storage

If unresolved, contact rConfig support with the full diagnostic output.

Device connections fail from the container but work from the host

The network abstraction is interfering with device connectivity.

Test connectivity from the host:
Terminal window
```
ssh admin@device-ip
```
Compare with connectivity from the container:
Terminal window
```
docker exec <container_name> ssh admin@device-ip
```
Switch to host networking mode:
```
network_mode: host
```

Capture packets on host and container to compare:

tcpdump -i any -w host.pcap host device-ip
docker exec <container_name> tcpdump -i any -w container.pcap host device-ip

Review the captures for addressing or protocol differences, and contact support with the capture files if unresolved.

Queue workers stuck processing no jobs

Worker process management has failed in the container.

Check Supervisor status:

docker exec <container_name> supervisorctl status

Review Horizon status:

docker exec <container_name> php artisan horizon:status

Restart the workers:

docker exec <container_name> supervisorctl restart all

If the issue persists, restart the container:
Terminal window
```
docker restart <container_name>
```
Monitor for recurrence and contact support if it repeats.

Performance much worse than a server install

Docker overhead is exceeding the application’s requirements.

Compare resource utilization:
Terminal window
```
docker stats <container_name>
```
Test with increased resource limits:
```
mem_limit: 16g
cpus: 8
```

Benchmark storage performance:

docker exec <container_name> dd if=/dev/zero of=/var/www/html/rconfig/storage/test bs=1M count=1000

If performance remains inadequate, plan a migration to a server install.

Support for Docker deployments

rConfig support provides limited assistance for Docker-specific issues.

Supported: application-level issues reproducible on a server install, configuration guidance, and functional troubleshooting.
Limited: Docker networking, storage driver problems, orchestration complications, and performance tuning in containers.
Not supported: custom Docker configurations, Docker Swarm or Kubernetes, third-party orchestration tools, and Docker infrastructure faults.

When raising a support request for a Docker deployment, state that it is Docker-based, attach the Docker configuration (Dockerfile and docker-compose.yml), include container logs alongside application logs, and note whether the issue also reproduces on a server install. Be prepared for a recommendation to migrate.

If a Docker-specific issue proves unresolvable, the options are migration to a server install (strongly recommended, with support assistance), acceptance of the documented limitations at increased operational risk, or a paid Professional Services engagement for complex scenarios. Contact support@rconfig.com to discuss.