Best Containers for DevOps in 2025

I use a LOT of Docker containers in the home lab and in my DevOps journey to continually work with various code projects, automation, and just running applications in containers. There are myriads of DevOps containers to be aware of that provide a lot of value and can help you achieve various business and technical objectives. There are several DevOps containers that I want to share with you that I use. Let’s look at the best Docker containers for DevOps in 2025 and see which ones I am using.

Why run Docker Containers?

There may be a question as to why you would run containers for DevOps tools instead of VMs? That is a great question. Virtual Machines are still very important and provide the foundation for virtual infrastructure and container hosts. I don’t think they will go away for a long time. However, containers are my favorite way to run apps and DevOps solutions.

Docker containers allow you to easily spin up new applications in seconds and not minutes or hours. You can simply pull an application container and spin it up with a one-line docker command instead of having to install a VM operating system, install all the prerequisites, and meet all the requirements of the application, which might take a couple of hours total.

Instead, spin up a Docker container host on a virtual machine and then spin up your applications in containers on top of your container host.

Best Docker Containers for DevOps beginning in 2025

Below is my list of best Docker containers for DevOps in 2025 broken out in sections. You will note a few repeats in the sections as some solutions do more than one thing.

CI/CD:

• GitLab
• Jenkins
• Gitea
• ArgoCD

Container registries

• GitLab
• Gitea
• Harbor

Secrets management

• Hashicorp Vault
• CyberArk Conjur
• OpenBAO

Code Quality

• Sonarqube
• Trivvy

Monitoring stack

• Telegraf
• InfluxDB
• Prometheus
• Grafana

Ingress

• Nginx Proxy Manager
• Traefik
• Envoy by Lyft

CI/CD and Container Registries

GitLab

GitLab is the CI/CD solution and code management repo that I have been using to version my DevOps code in the home lab and in production environments. If you want to self-host your code repos and do extremely cool CI/CD pipelines for infrastructure as code, GitLab is a free solution that is easy to stand up in a Docker container.

You can use it to automate testing, build and automate, and deployment to your environments. You can also integrate third-party solutions in GitLab, which is a great way to extend what it can do

Pros:

• It is an all in one solution for DevOps and code
• Good CI/CD pipeline features
• Has third-party tools and integrations
• Good community support

Cons:

• Can be resource-intensive
• Some features may be in the paid product
• Is rumored to be in talks of a buyout by someone?

Docker Compose Code:

version: '3'
services:
  gitlab:
    image: 'gitlab/gitlab-ee:latest'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.example.com'
    ports:
      - '80:80'
      - '443:443'
      - '22:22'
    volumes:
      - './config:/etc/gitlab'
      - './logs:/var/log/gitlab'
      - './data:/var/opt/gitlab'

Learn more about GitLab here: The most-comprehensive AI-powered DevSecOps platform | GitLab

Jenkins

Jenkins is an OSS tool that most know. It will come up in just about any DevOps conversation around a self-hosted code repo. Many have a love/hate relationship with Jenkins. It can literally do anything you want it to, which is a plus. But the downside is, it can literally do anything. You can use it to build your projects, test code, and deploy to your infrastructure.

It also has a ton of third-party apps you can integrate with the solution and the CI/CD pipeline. Just about every other DevOps solution has an integration with Jenkins so it is supported across the board.

Pros:

• It has been around forever so great support
• Active community
• distributed builds are supported
• Everything seems to integrate with Jenkins

Cons:

• Can be complex to set up and manage
• Interface feels a little outdated

Docker Compose Code:

version: '3'
services:
  jenkins:
    image: 'jenkins/jenkins:lts'
    restart: always
    ports:
      - '8080:8080'
      - '50000:50000'
    volumes:
      - './jenkins_home:/var/jenkins_home'

Learn more about Jenkins here: Jenkins

Gitea

Gitea is a newcomer on the block. It has a modern feel about it, but isn’t as fully featured as other solutions like GitLab or Jenkins. It is easy to deploy and manage for Git repos. It has features that include issue tracking, CI/CD, and code reviews.

Pros:

• Lightweight and easy to configure
• Has CI/CD pipelines
• Lower resource requirements compared to other solutions

Cons:

• Fewer features compared to other solutions like GitLab and Jenkins
• Smaller community

Docker Compose Code:

version: '3'
services:
  gitea:
    image: 'gitea/gitea:latest'
    restart: always
    ports:
      - '3000:3000'
      - '222:22'
    volumes:
      - './gitea:/data'

Learn more about Gitea here: Gitea Official Website

ArgoCD

ArgoCD is a more Kubernetes-centric solution for GitOps. Its purpose is to supply continuous delivery for Kubernetes. It automates application deployment by tracking changes in a Git repository. It continuously monitors and synchronizes Kubernetes clusters which is a more proactive solution to make sure that applications are always deployed in the desired state.

Pros:

• GitOps-centric
• Real-time synchronization
• Kubernetes native solutions

Cons:

• Can be complex with GitOps and Kubernetes knowledge needed

Docker Compose Code: ArgoCD is usually installed using Kubernetes manifests or with Helm charts. So, not typically Docker Compose. Here is an example of a manifest:

apiVersion: v1
kind: Namespace
metadata:
  name: argocd
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: argocd-server
  namespace: argocd
---
apiVersion: v1
kind: Service
metadata:
  name: argocd-server
  namespace: argocd
spec:
  ports:
    - name: http
      port: 80
      targetPort: 8080
    - name: https
      port: 443
      targetPort: 8080
  selector:
    app: argocd-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-server
  namespace: argocd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: argocd-server
  template:
    metadata:
      labels:
        app: argocd-server
    spec:
      serviceAccountName: argocd-server
      containers:
        - name: argocd-server
          image: argoproj/argocd:v2.0.0
          ports:
            - containerPort: 8080
          command:
            - argocd-server
          args:
            - --staticassets
            - /shared/app
            - --repo-server
            - argocd-repo-server:8081
            - --dex-server
            - argocd-dex-server:5556
          volumeMounts:
            - name: static-files
              mountPath: /shared/app
      volumes:
        - name: static-files
          emptyDir: {}

Learn more about ArgoCD here: Argo CD – Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io).

Harbor

Harbor is a well-known container registry solution. It supports features that most want for their registries like role-based access control, image replication, multiple registries, vulnerability scans, and others.

Pros:

• Good security
• Role-based access control (RBAC)
• Image replication and vulnerability scanning

Cons:

• More complex setup
• No less than 6 containers for the solution
• Requires additional resources

Docker Compose Code:

version: '3.5'
services:
  log:
    image: goharbor/harbor-log:v2.0.0
    restart: always
    volumes:
      - /var/log/harbor/:/var/log/docker/:z
  registry:
    image: goharbor/registry-photon:v2.0.0
    restart: always
  core:
    image: goharbor/harbor-core:v2.0.0
    restart: always
  portal:
    image: goharbor/harbor-portal:v2.0.0
    restart: always
  jobservice:
    image: goharbor/harbor-jobservice:v2.0.0
    restart: always
  proxy:
    image: goharbor/nginx-photon:v2.0.0
    restart: always

Learn more about Harbor registry here: Harbor (goharbor.io).

Secrets Management

HashiCorp Vault

The Vault solution allows you to store secrets and pull these dynamically when you are using IaC solutions like Terraform. You can store many types of secrets, including things like API keys, passwords, and certificates. It is easy to stand up as a solution in either Docker or Kubernetes.

It provides a secure way for code builds and other things like CI/CD to grab secrets on the fly from the secrets vault.

Pros:

• Secure secrets management
• Dynamic secrets can be used
• Audit logging

Cons:

• It can get complex to build out
• Learning curve

You can see my full blog post on how to install Hashicorp Vault inside Docker here: Hashicorp Vault Docker Install Guide.

Docker Compose Code:

version: '3.8'

services:
  vault:
    image: hashicorp/vault:latest
    container_name: vault
    ports:
      - "8200:8200"
    volumes:
      - ./config:/vault/config
      - ./data:/vault/file
    cap_add:
      - IPC_LOCK
    command: "vault server -config=/vault/config/vault-config.json"

vault-config.json

{
  "storage": {
    "file": {
      "path": "/vault/file"
    }
  },
  "listener": {
    "tcp": {
      "address": "0.0.0.0:8200",
      "tls_disable": true
    }
  },
  "ui": true
}

Learn more about Hashicorp Vault here: Vault by HashiCorp (vaultproject.io).

CyberArk Conjur

CyberArk Conjur provides a community edition for secrets management. It focuses on CI/CD pipelines. You can integrate various tools and platforms for credentials, API keys, and other secrets.

It has detailed audit logging and other features that can help with security.

Pros:

• Strong integration with DevOps tools
• Robust access controls
• Detailed auditing

Cons:

• Added features may require enterprise version (paid)
• Complicated setup and management for those not familiar with the solution

Docker Compose Code:

version: '3'
services:
  conjur:
    image: cyberark/conjur:latest
    restart: always
    environment:
      CONJUR_AUTHENTICATORS: authn
    ports:
      - "443:443"
    volumes:
      - ./conjur/data:/var/lib/conjur

Learn more about CyberArk Conjur here: Secrets Management | Conjur.

OpenBAO

If you are a looking for a free and open source secrets management solution, then OpenBAO is one to try. It is from the Linux Foundation and allows you to store passwords and other secret information. Like Vault, you can use it to store things such as API keys, passwords, etc.

Pros:

• Simple solution that is lightweight
• Encryption support and RBAC
• Open-source and free

Cons:

• Limited features
• Smaller community

Docker Compose Code:

version: '3'
services:
  openbao:
    image: openbao/openbao:latest
    restart: always
    ports:
      - "8080:8080"
    volumes:
      - ./openbao/data:/var/openbao

Learn more about OpenBAO here: OpenBao | OpenBao.

Code Quality

SonarQube

You can use SonarQube for scanning code quality, and things like linting, etc. It can help do automatic code reviews and detect bugs in code. You can also use it as a vulnerability scanner and find code smells.

It supports many different programming languages and scripting languages. You can integrate it with CI/CD pipelines and give you a report of what it finds, etc.

Pros:

• Code quality analysis
• Multiple languages supported
• Integrates with CI/CD

Cons:

• Can be resource-intensive
• Doesn’t support some languages like PowerShell

Docker Compose Code:

version: '3'
services:
  sonarqube:
    image: sonarqube:latest
    restart: always
    ports:
      - "9000:9000"
    volumes:
      - ./sonarqube/conf:/opt/sonarqube/conf
      - ./sonarqube/data:/opt/sonarqube/data
      - ./sonarqube/logs:/opt/sonarqube/logs
      - ./sonarqube/extensions:/opt/sonarqube/extensions

Learn more about SonarQube here: Code Quality, Security & Static Analysis Tool with SonarQube | Sonar (sonarsource.com).

Trivvy

Trivvy is another solution I have used that allows you to scan for vulnerabilities (CVEs) and also for misconfigurations in your code (IaC). You can scan things like repositories, artifacts, container images, and you can even scan things like Kubernetes clusters.

Take a look at the example Docker compose code below:

version: '3.8'

services:
  trivy:
    image: aquasec/trivy:latest
    container_name: trivy
    entrypoint: ["trivy"]
    volumes:
      - ./trivy-cache:/root/.cache
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - TRIVY_SEVERITY=HIGH,CRITICAL 
      - TRIVY_EXIT_CODE=1            
      - TRIVY_IGNORE_UNFIXED=true   
    command: --help #Replace this with what you want to scan like, "image <image-name>"

Learn more about Trivvy on the official site here: Trivy.

Monitoring Stack

Telegraf

Telegraf collects and reports on metrics. It is part of the very well known “TICK” stack that many use for monitoring.

Pros:

• Many plugins to extend its features
• Lightweight
• Integrates with various systems

Cons:

• Requires configuration that is customized for different solutions
• Learning curve

Docker Compose Code:

version: '3'
services:
  telegraf:
    image: telegraf:latest
    restart: always
    volumes:
      - ./telegraf/telegraf.conf:/etc/telegraf/telegraf.conf

Learn more about Telegraf here: Telegraf Documentation (influxdata.com).

InfluxDB

InfluxDB is an open-source time series database. It is also part of the “TICK” stack. It is often used for housing metrics, events, and logs. There are many integrations with InfluxDB and you will find a lot of community projects using it.

Pros:

• Great for time-series data
• High performance
• Integrates with many solutions

Cons:

• Can require large resources depending on data
• Complex queries may result in a learning curve

Docker Compose Code:

version: '3'
services:
  influxdb:
    image: influxdb:latest
    restart: always
    ports:
      - "8086:8086"
    volumes:
      - ./influxdb/data:/var/lib/influxdb

Learn more about InfluxDB here: InfluxDB Time Series Data Platform | InfluxData.

Grafana

Grafana is the de facto tool that is used in the open-source world to visualize data gathered from other solutions. It is commonly used in solution “stacks” of things like InfluxDB, Prometheus, etc. Combined with other tools it makes a great open-source monitoring solution that can replace even enterprise solutions for data views.

Pros:

• Powerful for dashboarding and visualizing data
• Many integrations
• Intuitive interface
• Thousands of community dashboards available

Cons:

• Configuration may be complex depending on the integration
• Learning curve

Docker Compose Code:

version: '3'
services:
  grafana:
    image: grafana/grafana:latest
    restart: always
    ports:
      - "3000:3000"
    volumes:
      - ./grafana/data:/var/lib/grafana

Learn more about Grafana here: Grafana: The open observability platform | Grafana Labs.

Ingress

Nginx Proxy Manager

Nginx Proxy Manager is a great solution that I use a lot in the home lab and it provides an easy way to add SSL termination to your Docker containers. Instead of having to configure SSL inside the container you are hosting, you configure the SSL cert in Nginx Proxy Manager and then proxy the requests for your containers inside the proxy network.

Pros:

• User-friendly
• Lots of features
• Easy SSL configuration for Docker containers

Cons:

• Limited to Nginx features
• May need more advanced configuration for complex setups

Docker Compose Code:

version: '3.8'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      # These ports are in format <host-port>:<container-port>
      - '80:80' # Public HTTP Port
      - '443:443' # Public HTTPS Port
      - '81:81' # Admin Web Port
      # Add any other Stream port you want to expose
      # - '21:21' # FTP

    # Uncomment the next line if you uncomment anything in the section
    # environment:
      # Uncomment this if you want to change the location of
      # the SQLite DB file within the container
      # DB_SQLITE_FILE: "/data/database.sqlite"

      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'

    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Learn more about Nginx Proxy Manager here: Nginx Proxy Manager.

Traefik

Similar to Nginx Proxy Manager, Traefik is a way to provide reverse proxy features for containers. It is also a load balancer and can automatically discover services and apply routing to your containers. You can use it to manage SSL certificates as well like LetsEncrypt to automatically provision those.

It is more difficult to use than Nginx Proxy Manager since most configuration is done in the Traefik configuration itself which can be tedious.

Pros:

• Automatic service discovery
• Great integration with Docker and Kubernetes
• Lightweight

Cons:

• Configuration can be complicated
• Certificates can be complex to get working
• More complicated to use than Nginx Proxy Manager

Docker Compose Code:

version: '3'
services:
  traefik:
    image: traefik:v2.4
    restart: always
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./traefik/traefik.yml:/etc/traefik/traefik.yml

Learn more about Traefik here: Traefik Labs.

Envoy by Lyft

Envoy is a reverse proxy solution that was originally developed by Lyft and it is now part of the Cloud Native Computing Foundation (CNCF). It is built with distributed communication systems in mind. It can be used as a sidecar proxy that can be used in things like service meshes. Also, it can simply be used as a standalone proxy solution.

Note the following example Docker compose code below:

version: '3.8'

services:
  envoy:
    image: envoyproxy/envoy:v1.26.0 
    container_name: envoy
    ports:
      - "9901:9901" # Admin interface
      - "10000:10000" # Example listener port
    volumes:
      - ./envoy.yaml:/etc/envoy/envoy.yaml:ro 
    command: ["-c", "/etc/envoy/envoy.yaml"] 
    networks:
      - envoy-net
    restart: unless-stopped

networks:
  envoy-net:
    driver: bridge

Below is an example of the envoy.yaml configuration file:

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        config:
          codec_type: AUTO
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: service_backend
          http_filters:
          - name: envoy.filters.http.router
  clusters:
  - name: service_backend
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_backend
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 8080
admin:
  access_log_path: /dev/stdout
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 9901

Learn more about Envoy here: Envoy proxy.

Wrapping up

Hopefully this list of what I think are some of the best DevOps containers in 2025 will help you discover some solutions that you may not have used before. All of these solutions are a great way to start learning DevOps practices and workflows and it will take your home lab or production environments to the next level.