deployed_code docker + devops · containerization guide

Docker & DevOps —
build · ship · run · scale

Containerization has transformed how modern software is built, shipped, and scaled. By packaging applications with their entire runtime environment, containers ensure reliable execution across any infrastructure.

package Container
sync_alt
Orchestrate rocket

What containers are

01 · fundamentals

A container is a lightweight, standalone, executable software package that contains everything needed to run an application: code, runtime, system tools, libraries, and settings.

Unlike traditional deployments where applications are installed directly onto an OS — leading to the infamous "it works on my machine" problem — containers isolate the application from its host environment.

This guarantees consistency from local development through testing, staging, and production.

~/container-basics
$ docker run -it alpine sh
/ # echo "Hello from a container!"
Hello from a container!
/ # exit
$ docker ps -a
CONTAINER ID STATUS IMAGE
a1b2c3d4e5f6 Exited (0) alpine

Docker fundamentals

02 · core components

settings Docker architecture

  • build Docker Daemon (dockerd) — background service managing containers
  • terminal Docker Client — CLI for issuing commands
  • description Dockerfile — text document for assembling images
  • cloud Registries — storage for images (Docker Hub, private registries)

layers Docker images

An image is an immutable, read-only template that contains instructions for creating a container. Images are built in layers — each Dockerfile instruction creates a new layer.

  • check Layered architecture — union file system stacks layers
  • check Base images — alpine, ubuntu, node:alpine, python:3.11
  • check Caching — drastically speeds up builds

Containers vs. Virtual Machines

03 · architecture
FeatureContainersVirtual Machines (VMs)
ArchitectureShare host OS kernel; isolate user spacesRun full guest OS on hypervisor
Startup TimeMilliseconds (instantaneous)Minutes (boots full OS)
Resource FootprintMegabytes; highly efficientGigabytes; heavy consumption
Isolation LevelProcess-level isolation (lighter)Hardware-level virtualization (stronger)

Containers share the host kernel, making them significantly lighter and faster than VMs, while VMs offer stronger isolation by virtualizing hardware.

Docker Compose

04 · multi-container

As applications grow from single services into complex microservices, managing multiple containers individually becomes cumbersome. Docker Compose is the tool for defining and running multi-container applications.

  • description YAML configuration — one file defines services, networks, volumes
  • play_arrow Single command — docker compose up spins up your entire stack
  • clean Clean teardown — docker compose down removes everything

yaml Example compose.yml

services: web: image: nginx:alpine ports: - "80:80" api: build: ./api environment: DB_HOST: postgres postgres: image: postgres:16 environment: POSTGRES_PASSWORD: secret

Container-based deployments

05 · CI/CD & orchestration
pipeline

CI/CD integration

Build images on code commit, run tests in disposable containers, push verified images to registries — all automated.

deployed_code

Orchestration

Kubernetes automates deployment, scaling, networking, and load balancing across clusters of servers.

shield

Immutable artifacts

Containers are the ultimate deployment artifact — built once, deployed anywhere with complete consistency.

Benefits of containerization

06 · why containers
portable

Portability

"Build once, run anywhere." Containers run identically on laptops, on-premise, or any cloud provider.

trending_up

Scalability & efficiency

Share the host OS kernel — pack significantly more applications onto the same hardware compared to VMs.

isolation

Isolation

Applications and dependencies are sandboxed — preventing version conflicts between projects on the same host.

speed

Speed & agility

Rapid startup times and streamlined CI/CD enable zero-downtime deployments and faster feature shipping.

cloud

Cloud-native

Containers are the foundation of modern cloud architectures — microservices, serverless, and hybrid clouds.

repeat

Consistency

Eliminate environment drift — dev, test, and production are identical.

security container security · complete guide

Container Security —
build · ship · run · secure

Container security best practices that work across the entire lifecycle — from the image you build to the network policy that contains a breach. Make security part of your workflow, not an afterthought.

package Image
sync_alt
Runtime rocket

What are container security best practices?

01 · foundation

Container security best practices are the specific configurations, tools, and habits applied across the container lifecycle — covering build, ship, and run — that reduce your attack surface and catch vulnerabilities before they become incidents.

Every container on a host shares that host's kernel. A gap in any layer — image, runtime, or network — can expose the host system and every other container running on it.

Containers are ephemeral, built and torn down constantly. Traditional security tools designed for long-lived servers assume a stable target. To apply container security effectively, you need to adapt your existing measures to that pace.

~/container-security
$ whatis container-security
container security (n.) — build + runtime + network
  practices that reduce attack
  surface across the container
  lifecycle.
 
$ container-security --pillars
  ✓ image integrity
  ✓ runtime restrictions
  ✓ network segmentation
  ✓ access control

Build and secure your images

02 · image integrity

Every layer of container security you add later is compensating for problems that could have been avoided when you built your images. A smaller, cleaner image is the right starting point.

minimize Minimal base images

Full OS base images ship with package managers, shell utilities, and OS packages your application will never touch — every one is a vulnerability scanner check and a potential attack surface.

  • check_circle Use distroless or minimal base images
  • check_circle Strip down to what the app genuinely needs

layers Multi-stage builds

Compiling code needs a full build environment, but none of that belongs in the image you deploy. Multi-stage builds keep build tools in an early stage and copy only the finished artifact.

# Dockerfile FROM golang:1.22 AS build WORKDIR /src COPY . . RUN CGO_ENABLED=0 go build -o /app FROM gcr.io/distroless/static-debian12 COPY --from=build /app /app USER nonroot:nonroot ENTRYPOINT ["/app"]

Final image has no shell, no package manager, no build tools — only the compiled binary and a non-root user.

verified Sign your images

Use Sigstore's cosign or Notation to attach a cryptographic signature at build time. Verify signatures before deployment to confirm the image came from your pipeline.

scan Scan at every stage

Scan at build time, before registry push, before deployment, and periodically against running images. New vulnerabilities are disclosed in packages long after an image has shipped.

Integrate code scanning into the SDLC

03 · shift left

code SAST

Static Application Security Testing analyzes your source code for SQL injection risks, hardcoded credentials, insecure deserialization, and similar issues.

Every pull request gets checked automatically, rather than depending on someone remembering to run a scan.

dependencies Dependency scanning

Applications pull in far more third-party code than they write. Dependency scanning checks packages against known vulnerability databases.

SAST looks at code you wrote; dependency scanning looks at code you didn't write but are still responsible for running.

cost Cost efficiency: Fixing a flagged issue at this stage costs minutes and a code review comment. Fixing the same issue after it's shipped and turned into an incident costs considerably more.

Restrict container privileges

04 · lock down runtime

A vulnerability that gets past image scanning still has to be exploited. Restricting privileges limits how much damage a container can cause.

person_remove Run as non-root

  • check runAsNonRoot: true
  • check allowPrivilegeEscalation: false
  • check readOnlyRootFilesystem: true

security Kernel security mechanisms

  • check Seccomp profiles — restrict syscalls
  • check AppArmor / SELinux — mandatory access control

settings Security context

securityContext: runAsNonRoot: true allowPrivilegeEscalation: false capabilities: drop: ["ALL"] readOnlyRootFilesystem: true

Drops all capabilities by default and only adds back what's genuinely required — cuts off common paths to container escape.

speed Set resource limits

Unbounded, compromised containers can exhaust host resources. Set explicit CPU and memory limits on every container.

Runtime security & monitoring

05 · detect behavior

monitoring Detect behavior, not just vulnerabilities

Runtime security tools watch what a running container actually does — processes, files, network connections — and flag behavior that doesn't match what that container should be doing.

  • check If a web server suddenly spawns a shell → signal
  • check No static scan would have caught this

settings Watch for configuration drift

A secure environment that started out locked down can drift back toward defaults over time — a capability re-added, a network rule loosened.

  • check Regular audits against your baseline
  • check Automated runtime monitoring

insight Key insight: The Sysdig 2026 report found that running container images carrying a known exploited vulnerability dropped nearly 75% year over year — continuous scanning is worth the effort.

Network policies & access control

06 · contain the breach
block

Default deny network

Most container platforms default to open networking. Network policies that block unnecessary traffic by default prevent lateral movement.

manage_accounts

RBAC everywhere

Scope who can deploy, view logs, manage registries, or touch production secrets — least privilege for people, not just containers.

history

Audit trails

Record deployments, permission changes, and access to sensitive data. Essential for routine review and incident investigation.

Docker container security

07 · Docker specifics

checklist CIS Docker Benchmark

Use Docker Bench for Security — an open-source script that checks a host against the CIS Docker Benchmark automatically.

Covers host configuration, the Docker daemon, container images, and runtime settings.

hard_drive Harden the Docker daemon

  • check Keep it patched
  • check Don't expose Docker socket over network without auth
  • check Consider rootless Docker mode

warning Docker Content Trust is retired

Action required: If you have DOCKER_CONTENT_TRUST=1 set anywhere, remove it now — it will cause image pulls to fail.

Use Sigstore's Cosign (keyless signing) or Notation (certificate-based) for OCI-native image signing going forward.

storage Registry configuration

A misconfigured private registry — public read access left on, credentials shared too broadly — undoes many of your other security practices. Treat registry access with the same rigor as production infrastructure.

Cloud container security

08 · shared responsibility

balance Shared responsibility

Cloud providers secure physical infrastructure, host virtualization, and managed control planes. Everything above that is your responsibility — image contents, runtime config, network policies, access controls.

cloud Use cloud-native tools

Most providers offer native registry scanning and IAM roles scoped to a single service. Use them alongside generic scanners.

warning Don't assume defaults are secure

Cloud platforms are built for ease of use. Default network rules, storage permissions, and IAM policies often aren't secure by default. Review everything against your own baseline.

dns Self-hosting shifts more onto you

If you self-host on your own VPS, you're also responsible for the host OS, patching, and configuring the container runtime itself. Container security best practices for managed vs. self-hosted aren't the same.

Benchmarks & vulnerability scanning

09 · verification

checklist What a benchmark checks

NIST SP 800-190 and CIS Benchmarks define specific, testable controls:

  • check Is the container running as root?
  • check Is an API exposed without authentication?
  • check Is a capability present when it shouldn't be?

scan Vulnerability scanner

A scanner checks images and running containers against known vulnerability databases. It's a verification tool, not a replacement for the practices covered above.

  • check Tells you an image has a known issue
  • check Won't restrict privileges or segment networks

Treat scanning as the audit layer on top of everything else.

Incident response basics

10 · be prepared
description

Write the runbook

Decide which images get rebuilt vs. patched live. Specify who gets notified, who can isolate a container, and where the rebuilt image gets deployed from.

history

Review access logs

Don't wait for an incident. Regular log reviews surface misconfigured roles and over-permissioned accounts before they cause problems.

experiment

Test the plan

Run through response steps against a simulated compromised container — surfaces gaps between what the plan assumes and what actually happens.

Where Dokploy fits in

11 · platform foundation

Dokploy doesn't replace scanning or runtime tools, but it handles a meaningful share of the access-control and configuration work by default.

  • manage_accounts RBAC — scopes who can deploy, access servers, or view project data down to individual projects and environments
  • layers Environment isolation — staging and production services are isolated, secrets kept separate from build-time secrets
  • history Audit trails & registries — enterprise features include access logs and organization-level registry integration

check_circle What Dokploy handles

  • check Removes manual setup from configuration and access
  • check Tools you add on top work on a reasonably secure environment
  • check Not a replacement for scanners or runtime threat detection

Sign up for Dokploy →

Container security FAQs

12 · quick answers

question_answer How often should you scan container images?

Scan at build time, again before a registry push, and on a recurring schedule for anything already running in production. New vulnerabilities get discovered in existing packages long after an image has shipped. A weekly scan of production images is a reasonable minimum. Scan anything handling sensitive data daily.

question_answer Do container security best practices differ for Kubernetes versus standalone Docker?

The core practices — minimal images, non-root containers, network segmentation, resource limits — apply to both. Kubernetes adds pod security standards, namespace-level RBAC, and cluster-wide network policies that don't have a direct equivalent in standalone Docker.

References & further reading

13 · resources
article
Dokploy — Container Security Best Practices: A Complete Guide
article
CIS — Docker Benchmark and Kubernetes Benchmark
article
NIST — SP 800-190: Application Container Security Guide
article
Sysdig — 2026 Cloud-Native Security and Usage Report