What is a Dockerfile and what is it used for?

A Dockerfile is a declarative text file containing instructions for building a Docker image. It defines the base operating system, runtime versions, packages, libraries, application files, and environment variables. Its purpose is to package everything into a reproducible image that runs identically in any environment.

How does a Dockerfile solve the 'works on my machine' problem?

By packaging the application with all its dependencies, runtime versions, and system configurations into a single immutable image, the Dockerfile eliminates differences between environments. The same image built locally deploys to staging, production, or any cloud provider, ensuring identical behavior without surprises.

When should you use a Dockerfile to deploy external applications?

A Dockerfile is recommended when you need portability across environments or cloud providers, when your application has complex dependencies, when teams work with disparate configurations, or when you require reproducibility in CI/CD pipelines. It is especially useful for multi-service applications or microservice architectures.

What elements are defined inside a Dockerfile?

A Dockerfile defines the base operating system (Alpine, Debian, Ubuntu), exact runtime versions, required packages and libraries, application files to copy, environment variables, and startup commands. Each instruction creates an immutable layer in the resulting image that is reused in subsequent builds.

Does a Docker container work the same on AWS, GCP, and Azure?

Yes, as long as you use the same image. Docker abstracts the underlying operating system differences, making the image portable. However, you should account for differences in network configuration, persistent volumes, and provider-specific environment variables. The image is portable; orchestration may require platform-specific adjustments.

Back to blog

DevOps and ContainersMay 19, 202622 min read

External Apps with Dockerfile: The Path to Consistent Deployments on Any Cloud

A Dockerfile defines declarative instructions for building Docker images that package your application with all its dependencies. This ensures consistent deployments across local, staging, production, and any cloud provider, eliminating the environment differences that cause unexpected failures.

CodiflyDocumentation

External apps with Dockerfile: the path to consistent deployments in any cloud

In modern DevOps, one of the biggest challenges is ensuring that an application worksexactly the sameacross all environments: local, staging, production, on-premises, and in the cloud. Differences in libraries, operating system versions, or configurations can break deployments that "worked on my machine".
This is a well-documented problem in container ecosystems. (Docker Docs)

This is where Docker —and especiallyDockerfile— they solve the problem at its root.

What is a Dockerfile and why does it matter?

ADockerfileis a declarative file that describeshow to build a Docker image, precisely defining:

Base system (Alpine, Debian, Ubuntu, etc.)
Exact runtime versions
Required packages and libraries
Application files
Environment variables
Startup commands

Según Docker, esto permite crear un entorno reproducible y portable que encapsula todo lo que una aplicación necesita para ejecutarse.

En otras palabras: captura todo lo que tu aplicación necesita para vivir, en un blueprint confiable y replicable.

Esto transforma una app en un artefacto portátil, aislado del sistema operativo y del servidor donde se ejecuta.

El valor para apps externas: cero sorpresas, máxima portabilidad

Cuando se trabaja con external applications or custom services—proprietary APIs, batch workers, integrations, ETLs, dashboards, scrapers, small microservices— the problem is amplified:

Difficult or specific dependencies
Non-standard binaries or runtimes
Different versions of Python, Node, Java
Required system libraries
Configuration distributed across environments

This is exactly what Docker seeks to solve: packagingeverythingin a single image.

This ensures that:

It runs the same on AWS, GCP, Azure, Kubernetes, ECS, Cloud Run, or on-premises
It does not depend on the server where you deploy
You can version and audit each change
You can replicate the exact environment in QA or staging
The app does not break due to changes on the host

How Docker ensures consistency: the full cycle

1. Reproducible build

The Dockerfile defines exact versions, avoiding surprises.
(Docker:Reproducible builds)

FROM node:20-alpine
WORKDIR /app
COPY package*.json .
RUN npm ci
COPY . .
CMD ["node", "src/index.js"]

If two people build this image on different machines, the result will beidentical.

2. Immutable containers

Once created, the image isimmutable:
it does not change depending on the host.

This principle is key in the immutable infrastructure model.

It prevents:

“Contaminated” environments
Manually installed dependencies
Hidden settings

3. Total portability

The container runs the same on:

Docker Desktop
Kubernetes
Amazon ECS / EKS
Google Cloud Run
Azure AKS
Proxmox + Docker
Raspberry Pi clusters

According to Docker and Red Hat, this is one of the pillars of the ecosystem:build once, run anywhere.

4. Natural integration with CI/CD

Pipelines can:

Build the image
Scan for vulnerabilities
Version it (tags v1.2.3)
Push it to a registry (ECR, GCR, Docker Hub)
Deploy it automatically

This standardizes how changes are promoted across the organization.

Typical use cases in DevOps

✔️ External microservices
APIs and services outside the core.

✔️ Workers and scheduled jobs
Cron jobs, ETLs, scrapers, batch tasks.

✔️ Third-party integrations
Connectors that require uncommon dependencies.

✔️ Dashboards and internal tools
Without having to install anything on the server.

✔️ Modernized legacy tools
Encapsulate old apps without rewriting them.

Best practices for advanced Dockerfiles

1. Use minimal images

Alpine, Slim, or Distroless → smaller attack surface.

2. Multi-stage builds

You compile in one image and produce an ultra-lightweight one:

FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN go build -o app

FROM gcr.io/distroless/base
COPY --from=builder /src/app /app
CMD ["/app"]

Recommended in Docker Docs as an optimization pattern.

3. Do not mix configuration in the image

The image should contain only the code and dependencies,never configurations.
This means:

Do not include .env files inside the image
Do not hardcode sensitive or environment values inside the Dockerfile
Useenvironment variables, secret managersandconfig mapsfor each environment

This practice allows the same image to be used indev, QA, staging, and production, changing only the external configuration.

4. Do not run as root

Running the container as root increases the risk in the event of a compromise.
Better to create an unprivileged user:

RUN adduser -D appuser
USER appuser

Benefits:

Aísla mejor el proceso del host
Reduce el impacto de vulnerabilidades de librerías
Se alinea con estándares como CIS Benchmarks

5. Versiona cada build

Tags predecibles facilitan rollback:

mi-app:1.3.2
mi-app:latest

¿Por qué las nubes aman Docker?

Cloud platforms adopt containers as a standard because:
(Google Cloud, AWS, and Azure docs agree)

Scale easily
Start quickly (low cold start)
Fit with horizontal autoscaling
Isolated by design
Replaceable without downtime
Come with native health checks

In short:
Docker is the basic unit of modern deployment.

AtC4C7USwe help companies bring their internal, external, or legacy applications to modern cloud environments using containers, standardized pipelines, and reproducible architectures.

We implement well-designed Dockerfiles, secure images, faster deployments, and consistent environments that eliminate the typical friction between development and operations.

If your organization needs topackage custom services, modernize integrations, migrate workloads to the cloud, or standardize its infrastructure, at Cactus we build the technical platform so you can deploy faster, with fewer errors and a solid foundation to scale.