Overview: A Worm That Targets Misconfigured Docker Daemons

A cryptomining worm discovered by Cado Security exposed a serious and widespread Docker security problem: insecure remote API connections. The worm — attributed to a threat actor group known as TeamTNT — targeted Docker daemons that had been left open to unauthenticated remote connections, stole AWS credentials stored on the host, and used those credentials to spread further. The attack is a sharp reminder that containerized environments carry their own distinct security risks, many of which go unaddressed in traditional DevSecOps frameworks.

How the Attack Worked

The attack chain followed a clear pattern:

1. Credential theft: The worm scanned for and harvested AWS credentials stored locally on the compromised host (typically in ~/.aws/credentials).
2. Internet scanning: TeamTNT used those stolen credentials and automated scanning tools to discover other Docker hosts exposed to the internet with unauthenticated remote APIs.
3. Container compromise: Once inside, the attackers deployed cryptomining malware to generate cryptocurrency using the victim’s compute resources.
4. Potential escalation: Security researchers noted that the same access vector could be used to “jailbreak” from the container to the underlying host, enabling the attacker to run arbitrary code, exfiltrate data, or install persistent malware.

While cryptomining is often treated as a nuisance-level threat, the underlying vulnerability is far more dangerous. An attacker with remote API access to a Docker daemon has, in effect, root-level access to the host.

Root Cause: Insecure Docker Remote API Defaults

The Docker daemon can be configured to accept connections over a TCP socket, which enables remote management. The problem is that enabling remote connections without TLS authentication exposes the daemon to anyone who can reach the port — by default, TCP port 2375 for unencrypted traffic and 2376 for TLS-encrypted traffic.

According to Sergei Shevchenko, CTO of Prevasio (a container vulnerability scanning service), the core issue is a gap between Docker’s flexibility and most developers’ security knowledge. Securing the remote API requires generating TLS certificates, configuring mutual TLS (mTLS) authentication, and correctly referencing those certs in the daemon configuration — steps that many developers skip in the interest of simplicity.

The result is a large number of Docker hosts reachable from the public internet with no authentication required whatsoever.

Immediate Mitigations

If your organisation runs Docker daemons accessible over a network, the following steps should be treated as non-negotiable baselines:

• Disable the unauthenticated TCP socket. Unless you have a specific need for remote API access, bind the Docker daemon to the Unix socket only (unix:///var/run/docker.sock). Remove any -H tcp://0.0.0.0:2375 flags from your daemon configuration.
• Enable TLS mutual authentication. If remote access is required, configure the Docker daemon to use TLS with client certificate verification (--tlsverify, --tlscacert, --tlscert, --tlskey). Both the server and the client must present valid certificates.
• Restrict access with firewall rules. Use host-based firewalls or cloud security groups to allow inbound connections to port 2375/2376 only from known management IPs.
• Audit AWS credential storage. Avoid storing long-lived AWS credentials in ~/.aws/credentials on hosts running Docker. Use IAM roles for EC2 instances or environment-specific credential injection via secrets management tools (AWS Secrets Manager, HashiCorp Vault, etc.).
• Scan for exposed Docker APIs. Use network scanning tools internally, or services such as Shodan alerts (externally), to detect any Docker API endpoints accidentally exposed to the internet.

Why Container Escape Is a Serious Risk

When an attacker gains access to a Docker daemon over an unauthenticated remote API, they are not confined to a single container — they have access to the Docker control plane itself. This means they can:

• Start new privileged containers that mount the host filesystem.
• Inspect environment variables and secrets injected into running containers.
• Stop or tamper with legitimate containers.
• Use the host network stack for lateral movement within your internal network.

This makes an exposed Docker API functionally equivalent to unauthenticated SSH access to the underlying host. The cryptomining payloads observed in the TeamTNT campaign represent the least harmful use of such access.

The Broader Container Security Challenge

This attack is not an isolated incident — it reflects a structural tension in how container technology has been adopted at scale.

Containers are not inherently more secure than monolithic applications. They offer benefits such as isolation, reproducibility, and the ability to quickly redeploy patched images. However, in practice the complexity of container orchestration introduces new attack surfaces: misconfigurations, overly permissive network policies, insecure image registries, excessive container privileges, and — as demonstrated here — unprotected management APIs.

As Docker and Kubernetes adoption has grown, so has attacker interest. Threat actors are actively scanning for misconfigured container infrastructure because the population of targets is large enough to make the effort worthwhile. Security research teams are also publishing new container-specific CVEs at an increasing rate, meaning the threat landscape continues to evolve.

The key principle Shevchenko highlights is that container security requires dedicated tooling and processes — not just a translation of existing practices from the VM or bare-metal era. Authentication, least-privilege networking, image scanning, runtime anomaly detection, and secrets management must all be addressed as first-class concerns in any container-based deployment.

Recommendations for DevSecOps Teams

• Integrate container-specific security scanning into CI/CD pipelines to catch misconfigured Dockerfiles and insecure default settings before deployment.
• Adopt a secrets management strategy that avoids placing cloud credentials on container hosts in plaintext files.
• Apply the principle of least privilege to container networking: containers should only be able to communicate with the services they need, and management APIs should never be exposed to untrusted networks.
• Monitor container runtime behaviour with tools capable of detecting anomalous process execution, unexpected network connections, or cryptocurrency mining activity.
• Establish a container security baseline using hardening guides such as the CIS Docker Benchmark as a starting reference point.
• Train developers on container-specific security risks, including the implications of enabling TCP-based Docker API access without TLS.

Key Takeaway

The TeamTNT campaign is a textbook illustration of how operational convenience — leaving a management API open for ease of use — can create critical security exposure. For DevSecOps teams, the lesson is unambiguous: container security is a discipline of its own. Legacy assumptions about network perimeters and application security do not translate directly to containerized environments. Proactive configuration hardening, continuous scanning, and developer security education are not optional extras — they are the baseline required to run containers safely in any internet-connected environment.

Guest

Gareth Rushgrove is a Director of Product at Snyk, working remotely from Cambridge, UK, helping to build interesting tools for people to better secure infrastructure and applications. He has previously worked for the UK Government Digital Service focused on infrastructure, operations and information security, as well as at Puppet and Docker. When not working he can be found curating the Devops Weekly newsletter, hiking or reading a good book.

Transcript

Jon Collins: Hello and welcome to this episode of Voices in DevOps, where I’m here to speak to Gareth Rushgrove who’s got a diverse set of experiences in the bag. I’ll leave you to talk about all of that, Gareth. Essentially, as you know, this series is about how we’re looking to help enterprise organizations scale up their DevOps efforts. Why don’t we just start? Just tell us about yourself, Gareth and what you’ve seen in your career to date. How did you end up being on a Voices in DevOps podcast with me? I guess that’s the question of the moment.

Gareth Rushgrove: Yeah. First off, thanks for having us, Jon. Looking forward to chatting. Yeah, I’m Gareth Rushgrove. I’m currently the Director of Product Management at Snyk. That’s a small security software vendor. Prior to that, I was basically working in Product Management at Docker. Before then, mainly on the engineering side in other places. I was also a Technical Architect at the UK Government for a number of years. It was something like on the other side of the fence, if you like.

Can you say which bit?

Yeah. I worked for the Government Digital Service as part of the Cabinet Office for a number of years. I was involved quite heavily early on with gov.uk. That’s the single domain in project in the UK. I then ended up moving into doing more working with other government departments on infrastructure automation and information security, really being part of that help with digital transformation, adopting DevOps practices. Before then, [I had] various software engineering roles. I’ve always been a programmer of some sort, but I generally like the things around the edges. I’ve done a bunch of automations of CI systems.

I did quite a bit of work going back probably ten years ago now with—I was the developer to a couple of other people. They were on the operations side. I didn’t really know much about that. I was a developer looking to get my software deployed. I just built up a really good working relationship with them. Learned a load. That ended up—no telling with when ‘DevOps’ the word was coined in the first DevOps days. I wasn’t at the first one, but one of my colleagues I was working with was. He said, “Oh, you would have loved that.” I was along at the second one in Hamburg, and really just part of that very early conversation that got brought together by the word DevOps.

So you could comfortably say “I was that soldier who sat in that room. I had those conversations, and I watched as they went, ‘ah, we can get them with this guy.’”

To a certain extent I’ve made a lot—at least some of the mistakes as well. The disadvantage I guess of being both a developer at certain times and an operator at certain times is I’ve made a lot of mistakes on both sides as I’ve learned the practices around them. Which I think is then useful when you’re talking to people who were knee-deep in thorny problems that you have some empathy for, like the challenge they’re trying to address.

There are several directions we could take this conversation. You’ve got the background in security which is still in a lot of places the missing trough, if you like. I’d love to call it a link, but putting security into the DevOps process is still something that’s got to be force fitted sometimes. You’ve also got that big organization and big governmental public organization experience. Then you were breaking down little walls of confusion of your own in the very early days.

You’ve seen DevOps go from a thing that people were talking about because it was a good idea to a thing that everyone’s talking about because everyone else is talking about it, and trying to do it. How would you like to—what do you see—out of all of that when you’re working with other organizations today—where things are at, in DevOps terms?

Yeah, good question. Similar to the software evolution of DevOps itself. It wasn’t that there was this word ‘DevOps’ and suddenly people started talking about infrastructure automation or developers and operators working together. Those things were starting to happen anyway. They were starting to happen in individual organizations. They were starting to happen with passionate open source developers. They were starting to happen in large organizations, but it was mainly separate. You’ve got those conversations happening in lots and lots of places, but there’s not one place for it to come together. That’s what the DevOps word and DevOps banner and the DevOps community developed into.

Honestly, I still see that happening today. Terms always cross through that somewhere in the hallways, and successful terms cross over that barrier of, now everyone’s talking about it because everyone needs to be talking about DevOps apparently. Some people get quite cynical about that because they’re like, ‘what does DevOps mean?’ The reality is that, compared to five years ago, six years ago, seven years ago, more people today are talking about the need for development operations to work together fundamentally. The need to automate the patterns that we see that allow us to go faster without sacrificing security, without sacrificing safety. I just think it’s grown—we’re having the same conversations and that’s a good thing because they’re reaching more people.

That’s an interesting philosophical difference compared to some of the people I’ve discussed DevOps with. I’m just going to play this through in my head and make sure I remember it all. You’re saying that this need for—I like what you said: “There are patterns to move faster without sacrificing certain elements to get the two sides to work together.” That’s a very ‘both sides of the divide’ kind of way of presenting it, whereas some of the people I’ve spoken to have come much more from the developer side, and said, “If we’re going to work faster, we need to bring the ops people on board.” I think when we think about what we’re trying to do with enterprises, it is about aligning with the conversations maturing within those enterprises rather than bringing it in as a big new thing.

I’ve seen and talked to people who have said, “oh, DevOps is driven—it’s a plot by developers to get rid of the operations people.” I’ve also seen operations people saying the opposite—where it’s a plot by the ops people to control developers. I’ve seen DevOps events where it’s been mainly about developer conversations. I’ve seen DevOps events where it’s mainly been about operations conversations. Some of this is just about—it’s very local and that might be a local event. It might be local companies. Who is driving this in your organization turns out to be really interesting. Who’s driving the change? In large organizations, sometimes that’s: who’s got the budget? Who’s got the political capital to make this change?

I think where DevOps works it’s fundamentally about acknowledging it a bit more of ‘yes there are specialists and yes, they’re skilled. Yes, there are separate budgets or separate organizations, but we’re better off individually and collectively if we work together.’ Some of it is giving up some of that ‘I’m an operator,’ ‘I’m a developer’ tribalism in pursuit of ‘What does our company do? What does our organization do?’ That’s the primary driver.

It’s funny. It’s a bit like when you say, “Oh, I work with computers,” and they say, “What printer should I buy?” I was speaking to someone who worked for utility at running club last night, and he said, “We’re looking to expand our use of DevOps across the organization.” (I thought, I’m trying to have a run here.) He was asking me things and then there was one moment he said, “Because they…” I said, “There’s your problem. How can you get above that ‘because they?’” Who’s above it that can see it as a ‘we’ thing rather than a ‘they’ thing. It wasn’t just a waffley thing that someone says. He absolutely engaged with that and said, “You know what, that’s absolutely it.”

Often organizations have quite reasonable reasons at the time, structured themselves in such a way that you build those barriers. You build those incentives that literally pit people further down the organizational tree against each other. I think appreciating those incentives are often like, why is someone working like that? Oh, it’s because literally that’s how they grow as a person. They’ve been told that’s how they reach the next level in their career, and not because it affects you, but because that’s the thing you’re optimizing for.

I think if you can go visit people in your organization on ‘the other side’ who you perceive [as ‘other’] organizationally, structurally, socially, and asking them “What are your incentives? What are the main things you’re trying to optimize?” It’s the classic developer thing of… the operations people want to maximize stability and the developers want to maximize velocity.

If you don’t acknowledge that those two things are in opposition, you have incentivized your two bits of your own organization to ultimately never get on. I think incentives are high under the management thing or a big part of embracing DevOps especially in large organizations. Smaller organizations, it’s true, but those people probably sit next to each other. In larger organizations, there’s probably several layers of hierarchy between you and the people setting those incentives.

Yeah, different building, different sites, whatever. I was thinking the security people are there to enforce policy as well which is another dimension to it.

The DevOps banner I think has been just something where people can come and talk about their different incentives and try and build some things together including the security community. The very early DevOps events definitely had no security. They weren’t in the room. Similarly they weren’t in the room as those people went back to their organizations. It was maybe three years in or so, like seven, eight years ago when early inquisitive security people started showing up at some of the DevOps events. That was the topic that was suddenly really interesting in those events. Maybe like chaos engineering today or observability is today. We’ve seen I guess over the last ten years of having that banner, having that lens, security with definitely—it’s still critically important, but it wasn’t until maybe five, six years ago, when people really started showing up to have those joint conversations.

It was almost given where it’s coming from. I was doing this stuff in the ‘90s when dev and ops were certainly not talking to each other. If they were, it was all a bit fraught, and just getting them to talk to each other was—you’re not done, but boy you just need to fall back and regroup and get your breath back before then moving on to other stakeholder groups. We used to, in ISDN days, we use to talk about multifunctional teams, but I’m pretty confident that we didn’t have a security person in that team.

Yeah, and it’s still true in lots of organizations. Again, people need to feel bad about that. I think their acknowledging that ‘wouldn’t it be great if they were there?’ I think that’s the mental model change. Where I’ve seen that work, suddenly the security people are in demand. They’re having things brought to them, and their problems change from playing whack-a-mole after the fact, to going ‘there are too many people asking for my time here,’ and I can really see a sea change there.

Given how you said that different organizations will see it more as a developer thing or an operations thing or a top-down thing, where is the budget, etc, etc. Should all organizations be trying to do DevOps, or should all organizations be just trying to evolve in the right direction?

You could put a digital transformation hat on some of this, but just get to a state where they’re working together better and more agile so on and so forth, and DevOps just naturally falls out of that? Their own blend of DevOps. How does it work?

Yeah. I would say all organizations would surely benefit to a certain extent of having empathy across roles and working together more closely. I think it’s easy to say that; it’s also what was actually needed on the ground. I think it’s easy to be cynical there. To me, to a certain degree, doing that really is DevOps. It’s like that cultural aspect of it because that’s probably the bit that is often more ignored in the pursuit of the other properties.

I quite like the ‘CAMS’ description of DevOps if you like: the ‘culture, automation, measurement, and sharing.’ Ultimately metrics and automation can be tricky, but most organizations will have some pursuit of those. Most people are not today saying “We shouldn’t automate these things.” They might say “It’s expensive to automate these things; we’re automating these things first,” but most of them are not in my experience completely anti-automation.

In a similar way, most are not anti-collection of metrics and actually measuring things. Again, the DevOps community has a lot of material and so do others about improving those things. If you combine them with a culture that really emphasizes sharing, to me that is just DevOps. Whether you’re doing the long list of different practices, the different people like the cloud.

I think DevOps avoids the peril here by being undetailed and unspecified in comparison to something like an Agile process or an SRE more opinionated take on this. I think when it comes to the opinions there is no universal ‘everyone should be doing X.’ I’m a fan of Agile for all sorts of different development activities, but it’s not the panacea. It’s not the only thing you should ever do to your problem. If agile is the solution, it’s great. SRE similarly is a much more opinionated take on the higher-level DevOps practices. Again, that’s very suitable in some organizations. Maybe it’s too much in others.

DevOps I think is such a broad banner. To me, it’s just a word under which we have all these conversations about this space. That has downsides, but I do think it makes it universally that you should be adopting some of those things.

Is it a journey or a state of mind?

To me, it’s a banner. It’s the sign under which we have these conversations at the moment in time. At some point, that will, the banner will move to something else. It’s just a pointer. I wouldn’t say it’s a destination certainly, and I guess ‘state of mind’ isn’t a bad description. I generally just describe it as the banner under which we have the conversation happening at the moment.

Yeah, so it’s more setting the direction than getting to the place.

Yeah, absolutely.

With that in mind, that all just got very, very philosophical. (Laughter) In your experience, is it just the case of literally printing something out in a big piece of cloth and sticking it at the front of the building or given your background, with the Docker side of things, with the automation and CI/CD side of things, etc. What are the things that catalyze the ability to move within that banner? Below that banner that you just do.

I think some of it comes down to you need concrete things at the end of the day, and that’s where the tools come in. Ultimately, finding tools that cross boundaries. I guess the pathological case is when your security team buy separate tools and they’ll do it under a banner of a CIO, and your operations team buys monitoring tools. Again, separate budget, separate organization. The overlap in the tool is actually quite large, but the presentation of the information might be different for a different audience. Your developers now have application level monitoring. Suddenly you’re all using separate tools that overlap quite a bit. The fact you’re using separate tools means you don’t have to collaborate. You don’t have a way of collaborating across data, even though that’s security data about the applications you’re running on your infrastructure.

I think sharing tools brings people together in the same way as sharing physical space brings people together. You suddenly see things that you wouldn’t have seen otherwise. ‘Oh, look. My application—it’s not just that the frontend has been responsive, but actually, look, the backend process is taking up too much disk space’ or ‘oh, look. The cluster it’s running on, why do we need this much capacity versus this other application that another team is running?’ I think shared tooling helps. Continuous integration I think is often at the heart of that because it’s one place where the pipeline metaphor can really be useful for a shared set of tooling and different teams, different types of teams injecting things into a shared pipeline over which we’re deploying software.

The security team introducing security checks is just a step in a pipeline. They’re not trying to take over your application. They’re injecting something that’s useful to everyone, and it’s visible to everyone, but it’s about addressing the security team needs or providing information to the developers.

I think shared tooling is super important. Monitoring, visibility, tooling, logging, tooling similarly. I think a lot of that, when it comes to the software delivery side, continuous integration is key. If you have that and you have that shared across the different disciplines in your organization, and that might be service management people, that might be asset inventory, that might be the security teams, the operations teams, the developers. You can have these conversations often in code in a shared setting versus ‘oh no that’s, only the development team have access to this tool. Only the operations team have access to this tool.’

That’s making it very delivery-centric and as you say, operations is fantastically important, and all that monitoring and so on. First thing you need to do is streamline how you deliver with everyone as part of that streamlined delivery.

I think it depends where—what the pain point is in your organization. There are organizations [where] the priority is delivering new functionality and features or whole new services; where all of those services actually have an active development team and that development team is in-house. There’s also organizations where actually, the majority of the work they’re doing is running software. Actually, the majority of that software isn’t even first party, it’s third party. I think all of these shared tools that benefit which ever end of that spectrum you’re on.

Where you start, I think depends on your starting point. If you are actually starting your applications and you’re undergoing that digital transformation then maybe your insourcing, you’re seeing a lot of that at the moment back in-house.Then step one, you have to get a continuous integration set up in place, share that across your different disciplines and have the conversation in code and configuration about what’s in the pipeline with everyone because then you can then have a really reasoned debate about what’s going on there.

If you’re mainly running things, I would say start with monitoring, start with logging and again, having the visibility into what’s happening, but can be used for debugging applications and capacity planning. It can be used for security analysis. Have one thing like one source code to them. That might be the best place to start. Obviously, there are others. I think it’s contextual.

Excellent. This is not a completely glib question, but it’s going to come across like one. Surely the answer is ‘microservices for everything’ and then the tooling fits with the architecture and the targets and people just need to align around that?

Again, I don’t think there’s generally speaking one size fits all, especially in that case of: ‘Look, we’re not actually building loads of software, we’re just running third party software.’ I guess this is one of those things where surely as a developer earlier in my career, I just knew the software I was building and I thought about the software I was building. I knew other teams adjacent to me were building software. Actually, then you would talk to the operations people and they would be like “We’re running 100 different applications. We have to care about many different things.” I think the trade-offs there were different. If you think about microservices and individual teams going, ‘oh, I’ve gone from managing and writing one application to splitting that into five or six services.’ That is amplified on the operation side.

I think there are operational advantages to that, but there are disadvantages as well. I think in organizations which were embracing a ‘you build it, you run it’ type of approach where you’re pushing the operational responsibilities down to the development teams themselves with often assistance from operators and security teams. In that world, ultimately the trade-offs you’re making from an architecture and development point of view, you’re bearing the cost of them as well. That can work really well because you create the services that work for the domain that make it easy to develop and deploy them independently, but you’re bearing the operational cost, so you understand that it’s not free.

I think if you have a disconnected organization that doesn’t get on, that hasn’t really built up that relationship yet, microservices can just make that worse. Suddenly instead of throwing over the wall one thing every six months, I’m now throwing 100 things every day from the operations side.

It’s gone from granite blocks to tennis balls, isn’t it?

Tennis balls fired via cannon from multiple different angles at a rate that’s going on 24/7. I think…

I just like to say for the record I apologize for putting that in and I in no way think that the whole lot of microservices… but it was a good way to ask the question.

Yeah, I think that’s the thing with all of the, there are patterns and practices around the DevOps community that actually are absolutely the right thing to be knowledgeable about and interested in and consider in your organization. I think asking and answering questions like that is an important way of people realizing: put it in your context. Understand the problems that it’s solving and then say, “Do you have those problems?” or “Is that the most important problem we should solve first?”

Awesome. I think that’s possibly a good point to leave it on, which was absolutely excellent. What have we learned? It’s about understanding the needs of your own organization. It’s about not trying to apply DevOps as a conceptual thing but working with it as a banner below which you should be migrating things that you actually understand and know about. (I hate the word ‘’ by the way.) I mean should in the context of don’t try and do it the wrong way. Do it the easy way. We’ve learned that it’s about getting that continuous integration in place and sharing that across different parts of the organization and building up from there. Have I missed anything?

No. Especially you should start with a focus on individual practices, whether that is getting really good at continuous integration, becoming really good at deployment, and becoming really good at monitoring, becoming really good at securing your applications, becoming really good at asset management. Pick practices that represent problems and focus on those. Be knowledgeable about what’s going on in the DevOps community and the conversation around those things that’s happening. Don’t just do it how you’ve always done it. Actually, yeah, it’s the practices that will move you forward, not ‘doing DevOps.’

Awesome. Gareth, thank you so much for your time. Everyone listening out there, if you’ve got any questions at all for us, do send them over. You know where to find us on Twitter, etc. I really appreciate it. Any last glib single sentence from yourself?

Don’t be too cynical about the benefits of people talking about empathy and talking to each other. There’s just a load of things to learn and generally speaking [it’s] quite interesting at the same time.

What Is the DevOps Market?

DevOps — short for Development to Operations — refers to the set of cultural practices, toolchains, and organisational patterns that unify software development (Dev) and IT operations (Ops). The commercial market around DevOps encompasses platforms, tooling, professional services, and training that help organisations implement continuous integration, continuous delivery (CI/CD), infrastructure automation, monitoring, and security integration (DevSecOps).

The market is not a single product category. It spans source control and collaboration tools, container and orchestration platforms, configuration management systems, observability stacks, and cloud-native deployment services — making it one of the more fragmented and fast-moving segments in enterprise software.

Key Vendors Shaping the Market

Several large enterprise technology vendors and specialist platforms have been consistently cited as significant players in the DevOps space:

• IBM Corporation — offers DevOps capabilities through its Cloud and Watson AIOps portfolios, as well as integration with Red Hat OpenShift and Ansible following its 2019 Red Hat acquisition.
• CA Technologies (now Broadcom) — historically provided application lifecycle management and release automation tools targeting large enterprises.
• EMC Corporation (now part of Dell Technologies) — contributes storage, infrastructure automation, and hybrid cloud capabilities relevant to the operations side of DevOps pipelines.
• Cisco Systems, Inc. — addresses network automation, security integration, and cloud-native application networking, increasingly relevant as DevOps pipelines extend to infrastructure provisioning.
• Docker, Inc. — the company behind the Docker container runtime and image format, which became foundational tooling for packaging and distributing application workloads in DevOps workflows.

Beyond these names, the competitive landscape also includes Microsoft (Azure DevOps, GitHub), GitLab, HashiCorp, Atlassian, JFrog, and a large ecosystem of open-source projects and cloud-native foundations.

Industry Segments and Use Cases

DevOps tooling and practices are adopted across a broad range of verticals. The segments most commonly highlighted in market analyses include:

• Information Technology (IT) Services — the largest adopter segment, where DevOps underpins managed services, SaaS delivery, and internal platform engineering.
• Banking, Financial Services, and Insurance (BFSI) — strong demand driven by regulatory pressure for auditability, rapid product iteration, and modernisation of legacy core banking systems.
• Retail and eCommerce — continuous deployment of customer-facing features, seasonal scaling, and tight integration with supply chain systems.
• Telecommunications — network function virtualisation (NFV) and software-defined networking (SDN) are closely aligned with DevOps and DevNetOps practices.
• Healthcare, Manufacturing, and Government — emerging adopters with compliance and security requirements that shape how DevOps practices are implemented.

Delivery and Channel Models

DevOps products and services reach buyers through two primary channels:

• Direct Sales — enterprise agreements negotiated directly between vendors and large organisations, typically including professional services, training, and support.
• Distributor and Partner Channels — system integrators, managed service providers (MSPs), and cloud marketplace listings that bundle DevOps tooling with broader transformation engagements.

The rise of self-serve SaaS models (GitHub, GitLab.com, CircleCI, Datadog) has added a third, product-led growth channel that largely bypasses traditional enterprise procurement — a structural shift that continues to compress margins for legacy vendors.

Regional Distribution

DevOps adoption and market revenue are distributed unevenly across geographies:

• North America — historically the largest market by revenue, with a high concentration of early-adopter technology companies and mature DevOps practices.
• Europe — strong growth, particularly in the UK, Germany, and the Nordics, shaped in part by GDPR compliance requirements that intersect with DevSecOps tooling.
• Asia-Pacific — the fastest-growing region through the forecast period, driven by digital transformation initiatives in India, China, Australia, and Southeast Asia.
• Rest of World — Latin America, the Middle East, and Africa represent smaller but expanding markets as cloud infrastructure availability increases.

Drivers of Market Growth

Several structural forces continue to drive investment in DevOps tooling and practices:

• Cloud-native architectures — the shift to microservices, containers, and Kubernetes increases the operational surface area and makes automated CI/CD pipelines a practical necessity rather than a nice-to-have.
• Competitive pressure on release velocity — organisations that can ship reliable features faster than competitors gain measurable business advantage, making DevOps adoption a strategic imperative.
• Talent economics — automating repetitive operational tasks reduces the per-unit cost of software delivery and allows engineering teams to focus on higher-value work.
• Security and compliance requirements — shifting security left into the development pipeline (DevSecOps) is increasingly mandated by regulators, insurers, and enterprise procurement teams.
• Hybrid and multi-cloud complexity — managing workloads across on-premises infrastructure and multiple cloud providers creates demand for unified tooling, observability, and policy enforcement.

Competitive Dynamics

The DevOps market exhibits several competitive characteristics worth understanding:

• Platform consolidation pressure — buyers increasingly prefer integrated platforms (end-to-end CI/CD, security scanning, observability) over best-of-breed point tools, favouring larger vendors and well-funded scale-ups.
• Open-source commoditisation — core tooling such as Git, Jenkins, Kubernetes, Terraform, and Prometheus is open source, compressing the addressable market for proprietary equivalents and shifting vendor revenue toward services, support, and adjacent features.
• Hyperscaler competition — AWS, Microsoft Azure, and Google Cloud each offer native DevOps services (CodePipeline, Azure DevOps, Cloud Build) that compete directly with independent vendors for workloads already running on their platforms.
• Acquisition activity — the market has seen significant M&A, including IBM’s acquisition of Red Hat, Broadcom’s acquisition of CA Technologies, and Atlassian’s acquisitions of Bitbucket and Opsgenie, reshaping the vendor landscape considerably since 2019.

What Practitioners Should Watch

For DevOps engineers and platform teams evaluating the market, a few practical considerations stand out:

• Assess total cost of ownership across the full toolchain, not just licensing or subscription costs. Integration complexity and operational overhead often exceed licensing spend.
• Evaluate vendor roadmaps against your own cloud and container strategy. Tooling that does not support your target platform natively will accumulate technical debt.
• Consider ecosystem health — active open-source communities, plugin ecosystems, and third-party integrations reduce lock-in risk and extend platform capability.
• Security posture is now a first-class evaluation criterion. Vendors without mature supply chain security, secrets management, and SBOM support are increasingly disqualified in regulated industries.

The DevOps market continues to evolve rapidly. Staying current with vendor positioning, open-source project maturity, and emerging practices such as platform engineering and internal developer portals is essential for teams making long-term toolchain investments.

Red Hat Brings Containers and Kubernetes to Its OpenStack Distribution

At the OpenStack Summit in Sydney, Australia in November 2017, Red Hat announced Red Hat OpenStack Platform 12, a significant release that containerizes the majority of OpenStack services using Kubernetes. The move reflects a broader industry trend toward treating infrastructure components as containerized workloads rather than monolithic, bare-metal or VM-hosted processes.

Red Hat is well-positioned to make this shift. Its engineers have been central contributors to container ecosystem tooling, and the company’s OpenShift Container Platform — built on Kubernetes and Docker — has been one of the most widely deployed enterprise Kubernetes distributions. OpenShift 3.0 formalized that Kubernetes-native approach, and subsequent releases, including OpenShift Container Platform 3.6 (launched in September 2017), added enhanced security features and improved consistency across hybrid and multi-cloud environments.

Why Containerize OpenStack Services?

Containerizing OpenStack services is not a new idea. As far back as 2015, eBay was running Kubernetes and containers within its OpenStack infrastructure to manage large-scale cloud operations. The upstream OpenStack community has also pursued this direction through projects like:

• Kolla – provides production-ready containers and deployment tools for operating OpenStack clouds.
• Magnum – an OpenStack API service that makes container orchestration engines (like Kubernetes and Docker Swarm) first-class resources in OpenStack.

Red Hat OpenStack Platform 12 takes this upstream work and integrates it into a supported enterprise distribution. The practical benefits cited by Red Hat include:

• Easier scaling of individual OpenStack services without redeploying the full stack.
• Reduced operational complexity through standardized container lifecycle management.
• Faster upgrades by updating individual service containers rather than full-host package updates.
• Better isolation between services, improving fault containment.

Radhesh Balakrishnan, General Manager of OpenStack at Red Hat, framed the release as part of a larger enterprise modernization effort to “better support the next generation of applications that take advantage of multiple hardware architectures, Linux container technologies and cloud computing.”

Key Features of Red Hat OpenStack Platform 12

Based on the upstream OpenStack “Pike” release, Platform 12 delivers improvements across containerization, security, networking, and composable infrastructure.

1. Containerized OpenStack Services

Most core OpenStack services are containerized in this release. Networking and storage services are offered as a containerized Technology Preview, meaning they are available for evaluation but not yet fully supported for production workloads.

2. Composable Networks

Red Hat has progressively expanded composable infrastructure support across recent OpenStack Platform releases:

• Platform 10 introduced customizable service profiles, allowing operators to tailor individual service deployments.
• Platform 11 made deployment and upgrade workflows more adaptable.
• Platform 12 adds composable networks, enabling operators to define their own network topology rather than selecting from predefined configurations.

This includes support for L3 spine-and-leaf topologies, which are common in large data center environments. Users can now create any number of networks suited to their specific physical infrastructure layout.

Platform 12 also adds support for the Redfish API, defined by the Distributed Management Task Force (DMTF), enabling interoperability with composable infrastructure solutions such as Intel’s Rack Scale Design.

3. Security Enhancements

• Automated infrastructure enrollment service for lifecycle management of security certificates.
• Updated volume encryption support in OpenStack Block Storage.
• Improved disk partitioning capabilities in bare-metal provisioning.
• A new security guide available in Red Hat’s customer portal to assist with understanding and implementing security controls.

4. OpenDaylight SDN Integration

Red Hat extended its Technology Preview of OpenDaylight integration in Platform 12. OpenDaylight is an open-source software-defined networking (SDN) and network functions virtualization (NFV) platform. Deeper integration enables more programmable, automated network management within OpenStack environments.

5. Distributed Continuous Integration (DCI) Improvements

Red Hat’s DCI technology, first introduced in its OpenStack distribution approximately five years prior to this release, automates deployment, testing, and the customer feedback loop. In Platform 12, DCI was updated to deliver actionable logs automatically to Red Hat’s quality engineering teams, shortening the cycle for identifying, patching, and releasing fixes.

Target Use Cases and Availability

Red Hat OpenStack Platform 12 targets both private and public cloud IaaS deployments. It was made available through:

• Red Hat’s customer portal.
• As a component of Red Hat’s Cloud Infrastructure and Cloud Suite subscription offerings.

Context: Containers in OpenStack vs. OpenStack for Containers

It is worth clarifying a distinction that often causes confusion in this space:

• Containers in OpenStack (this release) means running OpenStack’s own control-plane services — Nova, Neutron, Cinder, Keystone, etc. — as containers managed by Kubernetes, rather than as packages installed directly on host operating systems.
• OpenStack for Containers (Magnum, Zun) means using OpenStack as the underlying infrastructure layer to provision and manage container clusters for application workloads.

Platform 12 focuses primarily on the former: making the OpenStack control plane itself more cloud-native and operationally manageable through containerization.

Summary

Red Hat OpenStack Platform 12 represents a meaningful architectural shift in how enterprise OpenStack deployments can be operated. By containerizing core services with Kubernetes, introducing composable networking, extending SDN integration with OpenDaylight, and hardening security automation, Red Hat aimed to give operators the flexibility and operational tooling needed to run OpenStack at scale while aligning with modern DevOps and cloud-native practices.

Docker Was Not the First Container Platform

It’s worth establishing upfront that Docker is neither the first nor the only container platform. Other frameworks — notably OpenVZ and LXC — were available from the mid-2000s. Container-like isolation technologies such as FreeBSD jails go back even further. Docker was released in 2013, making it a relatively young technology compared to most mainstream enterprise infrastructure tools.

Yet it was Docker, not those more mature alternatives, that achieved widespread commercial adoption and reshaped the way software is built and shipped. Understanding why requires looking at two distinct questions: why containers in general became appealing, and why Docker specifically won out over earlier implementations.

Why Containers Became Appealing

Containers as a technology class offer concrete operational advantages over traditional virtual machines (VMs):

• Faster startup and shutdown. Containers share the host OS kernel rather than booting a full guest OS, so they start and stop in seconds rather than minutes.
• Greater portability. Container host environments are highly consistent regardless of the underlying OS distribution or cloud provider, dramatically reducing environment-specific bugs and the classic “works on my machine” problem.
• Easy horizontal scaling. Because containers are lightweight, they can be spun up or torn down rapidly to meet demand, making scaling applications significantly simpler than provisioning new VMs.
• Natural fit for microservices. Containers make it practical to decompose large monolithic applications into smaller, independently deployable services, each running in its own isolated environment.

These characteristics addressed genuine pain points that development and operations teams were experiencing as application complexity grew. The demand was real — containers just needed a form that organizations could readily adopt.

Why Docker Specifically Succeeded

The harder question is why Docker, and not LXC or OpenVZ, became the dominant container platform. Several converging factors help explain this:

1. Open Source From Day One

Docker was released as an open-source project from the outset. By 2013, open source had become the default expectation for infrastructure tooling in the technology industry. Developer communities, cloud providers, and enterprises were far more willing to invest in and build on open-source foundations than they had been in the mid-2000s. Docker’s openness lowered the barrier to contribution, experimentation, and ecosystem growth.

2. It Arrived at the Right Moment

By 2013, traditional virtual machines — while still useful — were beginning to feel heavy and slow relative to the demands of modern application deployment. Organizations were actively searching for leaner approaches. When OpenVZ and LXC appeared in the mid-2000s, conventional virtualization still felt fresh and adequate. Docker appeared precisely when the industry was ready to move on.

3. Alignment With the DevOps Movement

DevOps — the set of practices emphasizing collaboration between development and operations, continuous delivery, and rapid iteration — gained significant momentum in the early 2010s. Docker containers turned out to be an almost ideal building block for DevOps workflows: they made it straightforward to package an application with its dependencies, move that package through a CI/CD pipeline, and deploy it consistently across environments. Docker didn’t create the DevOps movement, but it accelerated it considerably.

4. Developer Experience and Simplicity

Docker introduced a clean, approachable abstraction — the Dockerfile and the image-layer model — that made containerization accessible to developers who were not Linux kernel experts. Earlier tools like LXC required considerably more low-level configuration knowledge. Docker’s tooling reduced that friction substantially, which drove grassroots adoption within engineering teams before Docker even had strong enterprise backing.

The Linux Parallel

Docker’s rise has notable parallels with the Linux kernel’s emergence in the 1990s. Linux began as a personal project with no institutional funding, yet it eventually dominated server computing, while better-resourced kernel efforts such as GNU Hurd saw limited real-world adoption. The reasons are complex and debated, but timing, community dynamics, and the practical needs of users all played roles.

The gap between Docker and alternatives like LXC was arguably less dramatic than that between Linux and GNU Hurd. Nevertheless, both stories illustrate how a well-timed, developer-friendly, open-source project can leapfrog technically older alternatives to become an industry standard.

Conclusion: Timing, Tooling, and Context

Docker’s dominance is not accidental. It is the product of genuine technical merit combined with exceptional timing. Containers solve real problems in software delivery — portability, speed, scalability, and environment consistency — but those problems became acutely pressing right around the time Docker appeared. Earlier container frameworks offered similar technical solutions but arrived before the industry had reached the point where it urgently needed them.

Add to that Docker’s open-source model, its alignment with the DevOps wave, and its focus on developer experience, and the result is a technology that was positioned perfectly to become the default container platform for a generation of cloud-native applications.

For DevOps engineers today, Docker remains a foundational skill — not just because of its technical capabilities, but because understanding why it succeeded helps illuminate the broader forces shaping how modern infrastructure is built and operated.

This guide walks through the core docker logs workflow: finding a container identifier, viewing its full log output, and tailing the log in real time.

How Docker Logging Works

By default, Docker uses the json-file logging driver, which captures a container’s standard output and standard error streams and stores them as JSON-encoded lines on the host filesystem. The docker logs command reads those stored lines and presents them to you. Because logging is tied to the process streams rather than to files inside the container, this approach works for every container regardless of what is running inside it — a web server, a database, a bare shell session, or anything else.

One important caveat: docker logs only works with the json-file and journald logging drivers. If your Docker daemon is configured to use a remote logging driver such as syslog, fluentd, awslogs, or gelf, log entries are forwarded externally and docker logs will return no output. Check your daemon configuration if the command returns nothing for a container you expect to have logs.

Step 1 — Find the Container Name or ID

Every docker logs invocation requires either the container’s name or its ID. List all running containers with:

docker ps

The output table includes the following columns relevant here:

• CONTAINER ID — a 64-character hex string, usually displayed truncated to 12 characters (e.g., e7565ec8e16d).
• IMAGE — the image the container was started from (e.g., nginx, debian).
• NAMES — a human-readable name, either assigned with --name at run time or auto-generated by Docker (e.g., loving_hopper).

You can pass either the full container ID, a unique prefix of the container ID (even four characters is usually enough), or the container name to docker logs. To include stopped containers in the listing, use docker ps -a.

Step 2 — View a Container’s Full Log Output

The basic syntax is:

docker logs CONTAINER

Replace CONTAINER with the name or ID from the previous step. For example, if you have an nginx container named web:

docker logs web

Or using a container ID prefix:

docker logs e7565ec8e16d

This prints everything the container has written to stdout and stderr since it started. For a long-running, busy container this can be a very large amount of text, which is why the options in the next sections are so useful in practice.

Step 3 — Follow Logs in Real Time

The -f (or --follow) flag streams new log lines to your terminal as they are written, similar to tail -f on a traditional log file:

docker logs -f CONTAINER

Combine -f with --tail to start from only the most recent lines instead of replaying the entire history first:

docker logs --tail=50 -f CONTAINER

This is the most practical form of the command for active troubleshooting. You can trigger the behaviour you want to investigate — a failing login, a bad request, a crash loop — and watch the relevant log lines appear immediately. Press Ctrl+C to stop following.

Useful docker logs Options at a Glance

Practical Examples

Show the last 100 lines with timestamps:

docker logs --tail=100 -t web

Show only entries from the past 10 minutes:

docker logs --since 10m web

Follow logs for a container started interactively (e.g., a Debian shell) from a second terminal:

In terminal 1, start the container:

docker run -it debian /bin/bash

In terminal 2, tail its logs using the first four characters of its ID:

docker logs --tail=10 -f 692a

Commands you run inside the Debian shell — such as apt-get update — will produce output that appears in the following terminal as it happens.

Viewing Logs for Stopped Containers

Log data persists after a container stops, as long as the container itself has not been removed. You can still run docker logs CONTAINER against a stopped container to inspect what happened before it exited. This is particularly useful when a container crashes on startup before you have a chance to follow its output live. Once you run docker rm, however, the log data is gone.

Next Steps: Centralised Logging

For a single host and a handful of containers, docker logs is sufficient. At scale — multiple hosts, dozens of services, high log volumes — you will want to route container logs to a centralised log management system. Docker supports a range of logging drivers out of the box (including syslog, journald, fluentd, awslogs, gelf, and splunk) that forward log entries to an external destination without changing anything inside the container. Configuring a logging driver is done either per container (--log-driver flag on docker run) or globally in the Docker daemon configuration file.

Understanding docker logs and how Docker captures stdout/stderr is the essential foundation before moving on to any of those more advanced setups.

What Is Watchtower?

Watchtower is a free, open-source application that monitors your running Docker containers and automatically updates them when it detects changes in their base images. The update process works as follows:

• Watchtower polls the image registry to detect changes to base images used by running containers.
• When an update is found, it gracefully stops the affected container by sending it a SIGTERM signal.
• It pulls the updated image from the registry.
• It restarts the container using the same runtime options — volumes, environment variables, port bindings, etc. — that were used when the container was originally launched.

The entire lifecycle is handled automatically in the background. No manual intervention is needed, making Watchtower useful in environments where keeping containers up to date is a routine operational requirement.

The steps in this guide were originally tested on CentOS 7 minimal edition, but the procedure applies to any Linux distribution that supports Docker.

Prerequisites

Watchtower is itself distributed as a Docker image, so the only prerequisite is a working Docker installation. Install Docker for your distribution before proceeding:

• For RPM-based systems (CentOS, RHEL, Fedora): follow the official Docker documentation for your distribution.
• For DEB-based systems (Ubuntu, Debian): follow the official Docker documentation for your distribution.

Installing Watchtower

Because Watchtower is packaged as a Docker image, deploying it requires only a single docker run command. Run the following as root or as a user with Docker socket access:

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  v2tec/watchtower

Breaking down the flags:

• -d — Run the container in detached (background) mode.
• --name watchtower — Assign the container a recognisable name.
• -v /var/run/docker.sock:/var/run/docker.sock — Mount the Docker daemon socket so Watchtower can inspect and manage other containers on the host.
• v2tec/watchtower — The official Watchtower image (pulls latest by default).

Expected output when the image is pulled for the first time:

Unable to find image 'v2tec/watchtower:latest' locally
latest: Pulling from v2tec/watchtower
a3ed95caeb02: Pull complete
802d894958a2: Pull complete
9916c27d2815: Pull complete
Digest: sha256:d89ea18b6332cc83639771fda274ebfd76f7042856d8f4997e99c7925ad02ae9
Status: Downloaded newer image for v2tec/watchtower:latest
e85c923f2e4dd22a62c12b038ea9694ba9245dcd835f210e1

Verifying the Watchtower Container Is Running

Confirm that Watchtower is running alongside your other containers:

docker ps

Sample output:

CONTAINER ID   IMAGE              COMMAND          CREATED         STATUS         PORTS   NAMES
e85c923f2e4d   v2tec/watchtower   "/watchtower"    3 minutes ago   Up 3 minutes           watchtower
58543e6ed18a   centos:latest      "/bin/bash"      5 minutes ago   Up 5 minutes           myapp

Watchtower is now running and will begin polling all other running containers on the host for image updates at regular intervals.

Monitoring All Containers vs. Specific Containers

Monitor All Containers (Default Behaviour)

By default, Watchtower monitors every container managed by the Docker daemon it is connected to. No additional configuration is needed — the basic docker run command above is sufficient.

Monitor Only Specific Containers

If you want Watchtower to watch only certain containers, append the container names as arguments at the end of the docker run command:

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  v2tec/watchtower myapp

In this example, Watchtower will watch only the container named myapp. All other running containers are ignored. You can supply multiple container names as space-separated arguments:

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  v2tec/watchtower myapp nginx redis

How the Update Cycle Works

Once Watchtower is running, it periodically checks the image registry for updates to the base images of each monitored container. The default polling interval is every 5 minutes. When an updated image is found:

1. Watchtower sends a SIGTERM to the running container, allowing it to shut down gracefully.
2. The new image is pulled from the registry.
3. A replacement container is started using the exact same configuration — including environment variables, port mappings, volume mounts, and network settings — as the original.

This behaviour means that Watchtower is best suited for stateless or semi-stateless workloads where restarting the container with the same options produces the desired result. For stateful services, consider whether an automated restart without a migration or data-backup step is appropriate for your workload.

Security Consideration: Docker Socket Access

Mounting the Docker socket (/var/run/docker.sock) into any container grants that container root-equivalent access to the Docker daemon and, by extension, to the host. This is an inherent requirement of how Watchtower operates. Ensure that:

• The host’s Docker socket permissions are appropriately restricted.
• You trust the Watchtower image source and pin to a specific image digest in production environments rather than using the latest tag.
• You review Watchtower’s own release notes before allowing it to update itself.

Summary

Watchtower provides a straightforward mechanism for keeping Docker containers up to date without manual re-deployment steps. By running it as a sidecar container with access to the Docker socket, it can monitor any number of containers and automatically apply base-image updates on a configurable schedule. For simple, stateless container workloads, this can significantly reduce operational overhead.

For more advanced use cases — such as sending update notifications, configuring custom polling intervals, or integrating with private registries — consult the official Watchtower documentation.

Below are five Docker containers that form a solid foundation for a home server. Each one is mature, well-maintained on Docker Hub, and genuinely useful in day-to-day life.

1. OwnCloud — Self-Hosted Cloud Storage

OwnCloud is a self-hosted alternative to Dropbox or Google Drive. You run the server, you own the data. Desktop sync clients are available for Linux, macOS, and Windows; they keep selected local directories in sync with the server automatically, just as commercial cloud-storage clients do.

In addition to file sync, OwnCloud provides a full web interface that lets you access, upload, and manage files from any browser. You can also generate shareable links to send specific files or folders to colleagues or friends without requiring them to have an account.

Why Docker? The OwnCloud Docker image bundles the PHP application and its dependencies together, so you avoid conflicts with other PHP applications on the same host. Data is stored on a mounted host volume, keeping it safe across container upgrades.

docker run -d \
  --name owncloud \
  -p 8080:8080 \
  -v /srv/owncloud/data:/mnt/data \
  owncloud/server

Tip: Upload bandwidth from your home ISP is the main performance bottleneck for remote access. If you plan to access OwnCloud from outside your home network, check your ISP’s upstream speed before storing large files.

2. Plex Media Server — Stream Your Own Media Library

Plex Media Server organises and streams your locally stored video, music, and photo libraries. Clients are available for smart TVs, Roku, Apple TV, Chromecast, iOS, Android, and most browsers — so you can watch your content on virtually any screen in the house, or remotely over the internet.

Plex scans your media directories, fetches metadata (cover art, descriptions, ratings) automatically, and presents everything through a polished Netflix-style interface. Transcoding lets it adapt the stream quality to match the available bandwidth and the capability of the client device.

OwnCloud + Plex synergy: If you store photos in OwnCloud, you can point a Plex photo library at the same directory. This makes it easy to pull up your photo collection on a TV when friends visit.

docker run -d \
  --name plex \
  --network=host \
  -e PLEX_CLAIM="<your-claim-token>" \
  -v /srv/plex/config:/config \
  -v /srv/media:/data \
  plexinc/pms-docker

Note: Hardware transcoding (GPU pass-through) requires additional Docker flags and a Plex Pass subscription. Software transcoding works out of the box but is CPU-intensive for high-resolution content.

3. Transmission — Headless BitTorrent Client with a Web UI

Transmission is a lightweight, open-source BitTorrent client. Running it as a Docker container on your server — rather than on your desktop — means downloads continue in the background whether your laptop is open or not. You interact with it through a browser-based web UI from any device on your network.

Common legitimate uses for BitTorrent on a home server include downloading ISO images of Linux distributions, large open-source dataset releases, and Creative Commons–licensed content.

docker run -d \
  --name transmission \
  -p 9091:9091 \
  -p 51413:51413 \
  -v /srv/transmission/config:/config \
  -v /srv/downloads:/downloads \
  linuxserver/transmission

The web interface is available at http://<your-server-ip>:9091 once the container is running. You can add torrents via magnet links or .torrent files directly from the browser.

4. OpenVPN — Secure Remote Access to Your Home Network

A VPN server running on your home server allows you to connect securely to your entire home network from anywhere — a coffee-shop Wi-Fi, a hotel, or a corporate network. Once connected, your device behaves as if it were physically sitting at home: you can reach OwnCloud, Plex, and any other local service by their internal IP addresses.

The kylemanna/openvpn image is a popular choice because it automates the PKI setup (generating the certificate authority, server certificate, and client certificates) with a few one-time commands. After that, generating a new client config is a single docker exec call.

# Initialise the configuration volume (run once)
docker run --rm \
  -v /srv/openvpn:/etc/openvpn \
  kylemanna/openvpn ovpn_genconfig -u udp://YOUR_PUBLIC_HOSTNAME

docker run --rm -it \
  -v /srv/openvpn:/etc/openvpn \
  kylemanna/openvpn ovpn_initpki

# Run the server
docker run -d \
  --name openvpn \
  -v /srv/openvpn:/etc/openvpn \
  -p 1194:1194/udp \
  --cap-add=NET_ADMIN \
  kylemanna/openvpn

Router configuration required: You need to forward UDP port 1194 from your router to the server’s local IP address. Pair this with the No-IP DDNS container (see below) so you always know the current public IP of your home connection.

5. No-IP DDNS — Keep Your Hostname Pointing to a Dynamic IP

Most residential internet connections use a dynamic public IP address assigned by the ISP. This address can change when your router reboots or when the ISP renews your lease. If you want to reach your home server from the internet, you cannot rely on a fixed IP.

Dynamic DNS (DDNS) solves this by mapping a stable hostname (e.g., myhome.ddns.net) to your current public IP. No-IP is a well-established DDNS provider that offers free hostnames. The No-IP Docker container runs a lightweight update client that periodically checks your public IP and updates the DNS record whenever it changes — so your hostname always resolves correctly.

docker run -d \
  --name noip \
  -e USERNAME=your_noip_username \
  -e PASSWORD=your_noip_password \
  -e DOMAINS=myhome.ddns.net \
  -e INTERVAL=5 \
  coppit/no-ip

Alternatives: If you prefer to avoid third-party DDNS providers, DuckDNS is a fully free, open alternative with good Docker support. Cloudflare’s API also works well if you already manage a domain through them.

Putting It All Together

These five containers complement each other well. A typical workflow looks like this:

• No-IP keeps your public hostname current so every other service is reachable by name.
• OpenVPN gives you an encrypted tunnel back to your home network when you’re away.
• OwnCloud keeps your files synced across devices and accessible from any browser.
• Plex streams your media library to any screen, at home or over the VPN.
• Transmission handles background downloads without requiring your laptop to stay on.

For production-quality management, consider writing a docker-compose.yml file that declares all five services, their volumes, and their network configuration in one place. This makes the entire stack reproducible and easy to migrate to new hardware.

For additional Docker learning resources, see the SCM Galaxy Docker training course.

This article explains Docker networking at a practical level: the terminology you will encounter, the three built-in network modes, and the CLI commands you need to inspect and reason about your container network topology.

Key Networking Terms

Before diving into modes and commands, it helps to define the terms you will see throughout any Docker networking discussion.

• Host network — your physical LAN. It consists of IP addresses (e.g. 192.168.1.x), subnet masks (e.g. 255.255.255.0), and is typically managed by your router. Every physical device on your network sits here.
• Docker network — a virtual network managed by Docker Engine. By default it runs on a separate address range (commonly 172.17.0.x) and a different subnet mask (255.255.0.0). Its scope and behaviour depend on the network mode you choose.
• Port — a number that identifies a specific service on a host. Web servers traditionally listen on port 80 (HTTP) or 443 (HTTPS). Media server apps are commonly reached over custom ports such as http://192.168.1.100:8096. The number after the colon is the port.
• Port forwarding (port mapping) — redirecting traffic arriving at a given IP-address/port combination to a different address/port. In Docker, this is how you make a containerised service reachable from your host network. Docker maps a port on the host to a port inside the container, bridging the two networks.

Docker Networking Modes

Docker ships with three built-in network drivers. Each involves different trade-offs between isolation, simplicity, and flexibility.

Bridge Mode (Default)

Bridge is the default network mode. When Docker Engine starts, it creates a virtual network interface called docker0 that acts as a software bridge between the isolated Docker network and your physical (host) network. Each new container receives an IP address on the Docker subnet (e.g. 172.17.0.2, 172.17.0.3, and so on).

Containers on the same host in bridge mode can communicate with each other directly by IP address with no extra configuration. However, for a container to be reachable from outside the Docker network — such as from your phone, TV, or another machine on your LAN — you must explicitly map a host port to the container port when you start the container.

You can verify the bridge interface is present by checking your network configuration. On Linux, the docker0 interface appears alongside your physical adapters:

ip addr show docker0

On Windows (with Docker Desktop), run the following from a Command Prompt to see the virtual DockerNAT adapter alongside your physical NIC:

ipconfig /all

The DockerNAT adapter typically uses its own address range (e.g. 10.0.75.x) separate from your LAN range.

On a Synology NAS running the Docker package, open Docker from the Package Center and select Network from the sidebar. Expand the bridge entry to see the subnet in use. On a QNAP NAS running Container Station, navigate to Preferences → Network to find the equivalent information.

Summary: Bridge mode gives you network isolation with explicit, controllable port mappings. It requires slightly more configuration up front but is the right default for most media server deployments.

Host Mode

In host mode, Docker does not create a separate network for the container. Instead, the container shares the host machine’s network stack directly — it binds to the same IP address and ports as the host OS. There is no NAT layer and no port mapping required.

This can simplify configuration and may improve network performance for certain workloads, but it removes the isolation that bridge mode provides. A port conflict between a container and a host service becomes possible, and the container can reach any service on the host network without restriction.

Note: Host mode networking on Docker Desktop for macOS and Windows behaves differently from Linux — on those platforms the Docker daemon runs inside a lightweight VM, so true host-mode networking against the Mac or Windows host is not directly available in the same way.

None Mode

The none driver gives the container a private network namespace with only a loopback interface (lo). The container has no external network connectivity whatsoever. This is useful for containers that perform purely local computation and must be completely network-isolated, but it is rarely used in media server scenarios.

Viewing and Inspecting Docker Networks

Docker provides straightforward CLI commands to list and inspect the networks available on your host.

List All Networks

docker network ls

A fresh Docker installation shows three default networks — bridge, host, and none — each with a unique ID and its associated driver. These default networks are required by Docker and cannot be removed, though you can create additional user-defined networks alongside them.

Inspect a Specific Network

docker network inspect bridge

This returns a JSON object containing the subnet, gateway, and — once containers are running — the IP address assigned to each connected container. For example, if you have two containers named Container1 and Container2 running on the default bridge network, the output will list both with their respective internal IP addresses (such as 172.17.0.2 and 172.17.0.3). This is a quick way to find a container’s internal IP when you need it.

Replace bridge with host or none to inspect those networks, or use the name of any user-defined network you have created.

Selecting a Network When Running a Container

When you start a container with docker run, use the --network flag to choose which network it joins:

# Use host networking
docker run --network=host my-image

# Use the default bridge (this is the implicit default if --network is omitted)
docker run --network=bridge my-image

# Use no networking
docker run --network=none my-image

If you omit --network entirely, Docker assigns the container to the default bridge network automatically.

Port Mapping in Practice

When running in bridge mode, use the -p flag to publish a container port on the host:

# Map host port 8096 to container port 8096
docker run -p 8096:8096 my-media-server-image

The format is HOST_PORT:CONTAINER_PORT. After this mapping is in place, any device on your LAN can reach the containerised service at http://<host-ip>:8096, even though the container itself lives on the separate Docker subnet.

You can publish multiple ports in a single docker run command by repeating the -p flag:

docker run -p 8096:8096 -p 8920:8920 my-media-server-image

Choosing the Right Mode for a Media Server

For most home media server setups, bridge mode with explicit port mappings is the recommended starting point. It matches Docker’s defaults, keeps containers reasonably isolated, and gives you fine-grained control over which ports are exposed. The trade-off — a few extra -p flags per container — is minimal.

Host mode is worth considering if a containerised application relies on network protocols that are difficult to port-map (such as multicast-based service discovery), or if you are troubleshooting connectivity issues and want to eliminate NAT as a variable. Be aware of the reduced isolation it implies.

None mode has no practical use in a media server context.

Once you are comfortable with these basics, Docker’s user-defined bridge networks — created with docker network create — offer additional benefits such as automatic DNS resolution between containers by name. That topic builds naturally on what is covered here.