The production industry still runs on a surprising amount of fragile infrastructure.
A critical automation script lives on a programmer’s laptop. A utility app runs on an aging Mac Mini under a desk. A show control tool is configured once and never documented again because “it works, don’t touch it.” A monitoring dashboard was built three years ago by someone who no longer works there.
If you have worked in live production long enough, you have seen systems held together with static IP notes, USB adapters, remote desktop shortcuts, and sheer optimism.
We are trying to move away from that.
At Stranger Production, Docker has become an increasingly important part of how we build and maintain infrastructure across our projects. Not because containers are trendy, and not because we believe everything should run in Kubernetes on a cluster of glowing servers in a rack somewhere.
Quite the opposite.
One of the most important lessons we have learned is this:
Not everything belongs in Docker.
Some applications absolutely need direct hardware access. Some production software depends heavily on GPU acceleration, capture hardware, low-latency interfaces, or operator-focused GUIs that simply work better on dedicated Windows or macOS systems. Broadcast and production environments still rely heavily on software that was designed for direct interaction with hardware, not for containerized deployment.
That is fine.
Docker is not replacing operator workstations.
Docker is replacing the infrastructure around them.
That distinction matters.
The Infrastructure Layer
Modern production systems are becoming increasingly API-driven, automated, monitored, and remotely managed. Even when the core production software still runs natively on a workstation, the supporting infrastructure around that system can often be containerized cleanly and reliably.
This is where Docker excels.
We use containers primarily for:
- Automation systems
- APIs and middleware
- Monitoring and telemetry
- Messaging systems
- Dashboards
- Databases
- Remote support tools
- Utility services
- Logging infrastructure
- Workflow orchestration
These systems benefit enormously from portability, reproducibility, and centralized management.
Instead of rebuilding utility servers manually every time a machine fails, infrastructure can be redeployed from version-controlled configurations. Services become easier to migrate between hosts. Updates become more manageable. Backups become more predictable. Testing becomes cleaner.
Most importantly, systems become less dependent on one specific machine hidden somewhere backstage.
That alone is worth the effort.
Where Docker Actually Works Well in Production
There are already several excellent production-adjacent tools that run well in containers.
Bitfocus Companion is a strong example. Companion works exceptionally well when deployed as part of a centralized automation layer instead of being tied to a single operator workstation. Running Companion in Docker allows it to become infrastructure instead of “that app running on somebody’s laptop.”
Other tools that fit naturally into this model include:
- Node-RED
- n8n
- MQTT brokers
- Grafana
- PostgreSQL
- InfluxDB
- Uptime Kuma
- FastAPI services
- Redis
- WireGuard
- Remote access gateways
- Telemetry collectors
- Logging systems
Most of these services are not directly driving the show itself.
They are supporting the show.
That is the difference.
A production switcher operator still needs a responsive workstation. A media server still needs direct GPU access. A graphics operator still needs immediate low-latency interaction with their tools.
But the systems that monitor, automate, integrate, report, trigger, log, and coordinate those environments increasingly behave more like modern IT infrastructure than traditional AV systems.
That infrastructure layer is where Docker becomes incredibly valuable.
The Real Goal Is Operational Stability
Containers are not magic. They do not automatically make systems reliable.
Bad infrastructure inside Docker is still bad infrastructure.
Containers introduce their own challenges:
- networking complexity
- persistent storage management
- permissions issues
- update procedures
- backup planning
- orchestration problems
- dependency management
You still need documentation. You still need monitoring. You still need backups. You still need engineering discipline.
What Docker provides is consistency.
A properly designed containerized service can be rebuilt quickly, migrated easily, backed up cleanly, and deployed repeatedly without relying on undocumented machine state.
That is a major improvement over the traditional “golden laptop” model that still dominates large parts of the production industry.
Looking for Better Infrastructure Tools
One of the more interesting shifts happening in production engineering is the growing availability of lightweight, API-driven, self-hosted tools that can replace fragile desktop utility applications.
We are increasingly evaluating software based on questions like:
- Can this run as infrastructure?
- Does it expose an API?
- Can it be monitored?
- Can it recover automatically?
- Can it be deployed remotely?
- Can multiple operators access it safely?
- Can it survive hardware failure without rebuilding from scratch?
These are infrastructure questions, not just software questions.
That shift changes how systems get designed.
The production industry has historically focused heavily on hardware reliability while often neglecting software infrastructure. As automation, remote workflows, distributed production, and centralized management continue to expand, that approach is becoming harder to maintain.
Infrastructure matters now.
Probably more than most people realize.
Where We Are Going Next
This is only the beginning of our containerized infrastructure work.
Future projects will dive deeper into:
- Companion deployments
- Docker Compose strategies
- API-driven automation
- Monitoring production environments
- MQTT architectures
- Remote engineering systems
- Backup strategies
- VPN-connected production infrastructure
- Raspberry Pi utility nodes
- Distributed telemetry systems
- Self-hosted engineering platforms
Not every production application belongs in Docker.
But production infrastructure increasingly does.
And the line between production engineering and infrastructure engineering is getting thinner every year.