Containers, explained.

Coming from shared hosting or a classic server? Then most of what follows is something you already know under a different name. This glossary translates the container vocabulary into plain words — what each term means, why it matters for a PHP application, and how it shows up at customcontainer.

The basics

Five minutes of reading that make every other page on this site easier to follow.

Container #

A running, isolated process that brings everything it needs with it: PHP, its extensions, the system libraries and configuration. It shares the kernel of the host, so it starts in milliseconds and needs far less memory than a virtual machine. Think of it as your application packed together with its own small, private server setup.

At customcontainer Every image you build here runs as a container in Docker, Podman, Kubernetes or any other standard tool.

Image #

container image, Docker image

The read-only template a container is started from — a snapshot of a file system plus a bit of metadata such as which program to run. The image is the blueprint, the container is the house built from it. You can start any number of containers from one image.

At customcontainer We compose your image from your PHP version, architecture and the extensions your composer.lock needs — nothing else.

Layer #

image layer

An image is not one big file but a stack of layers, each one a set of files stacked on top of the one below. Layers are stored and downloaded separately: if two images share a layer, it is only fetched once, and if one layer changes, only that layer has to be downloaded again.

At customcontainer Every PHP extension lives in its own layer. When one extension gets a fix, only that layer changes, and your servers and CI runners pull just the difference.

See also: Image, Digest More on this →

Container engine #

container runtime, Docker, Podman

The program that downloads images and starts containers from them. Docker is the best known, Podman a drop-in alternative that runs without a background service. Both understand the same images and almost the same commands — docker run and podman run do the same thing.

At customcontainer The configurator shows every pull and run command for both, switchable with one click.

Dockerfile #

Containerfile, docker build

A text file with build instructions: start from this base image, install these packages, copy these files. docker build executes it step by step and produces an image. It is the classic way to build images — and the place where PHP extension installs, compiler packages and workarounds tend to pile up over the years.

At customcontainer You do not need one to get a PHP image from us. If you want to bake your code in, a two-line Dockerfile that starts FROM your image and COPYs your code is enough.

Base image #

parent image, FROM

The image a Dockerfile starts from with its FROM line, for example php:8.4-fpm from Docker Hub. Everything in the base image ends up in your image — including tools and libraries your application never uses, but which still need updates and still count as potential attack surface.

At customcontainer Your customcontainer image can serve as a lean base image for your own Dockerfile.

OCI #

Open Container Initiative, OCI image

The Open Container Initiative maintains the open standards for image formats and registries. Because Docker, Podman, Kubernetes and the big cloud providers all implement them, an image built by one tool runs with all the others. “OCI image” simply means: a standard image that is not tied to one vendor.

At customcontainer Our images and our registry are plain OCI — no proprietary client, no plugin, no lock-in.

Images & registries

Where images are stored, how you fetch them, and how a name points to exactly one build.

Registry #

container registry, image registry, Docker Hub

A server that stores images and hands them out on request — comparable to Packagist for Composer packages, just for images. Docker Hub is the best-known public registry; companies often run private registries for their own images.

At customcontainer Every account gets its own registry endpoint. Your images are served from there and nowhere else.

Pull & push #

docker pull, podman pull, docker push

pull downloads an image from a registry onto your machine, push uploads one. Only layers you do not already have are transferred, which is why the second pull of a similar image is much faster than the first.

At customcontainer You only ever pull: we build the image and put it into your registry, so there is nothing to push.

See also: Registry, Tag, Registry pull key

Tag #

image tag, latest

The part after the colon in an image name, as in php:8.4. A tag is a movable label: the same tag can point to a different image tomorrow. latest is just the default tag and means “whatever was published last”, not “the newest stable version”.

At customcontainer Every build gets a fixed version tag such as 1.4.2 that never moves, plus latest, which always points to the newest build.

Digest #

sha256, image digest, content hash

A fingerprint calculated from the content, written as sha256: followed by 64 characters. Unlike a tag it can never point to something else: change a single byte and the digest changes. Pulling by digest is the strictest way to make sure you get exactly the image you tested.

Manifest #

image manifest

The table of contents of an image: which layers belong to it, in which order, and which configuration goes with it — each referenced by its digest. The container engine reads the manifest first and then fetches the layers it is missing.

Architecture #

x86_64, amd64, aarch64, arm64, CPU architecture, Apple Silicon

The processor family an image is built for. x86_64 (also called amd64) runs on most servers and Intel/AMD machines, aarch64 (arm64) on Apple Silicon Macs, AWS Graviton and other ARM servers. An image for the wrong architecture either does not start or runs slowly under emulation.

At customcontainer You pick x86_64 or ARM in a dropdown and get a natively built image for it — same PHP version, same extensions.

PHP in a container

What actually ends up inside a PHP image — and which parts you get to choose.

PHP extension #

ext-, module, intl, gd, pdo_mysql, redis

A compiled add-on that gives PHP extra abilities, such as pdo_mysql for MySQL, intl for internationalisation or gd for images. Packages in your composer.json declare which ones they need as ext-… requirements. Some extensions are built into PHP itself; others have to be added separately.

At customcontainer We read the required extensions from your composer.lock, and you can add or remove any of them with a click. Every extension you leave out is one less thing to patch.

PHP CLI #

command line, php binary

PHP on the command line: php script.php, php artisan, bin/console, Composer, PHPUnit or a queue worker. A CLI container runs one command and ends when the command ends.

At customcontainer Tick “CLI Package” and the image starts php by default — the right choice for workers, cron jobs and CI.

PHP-FPM #

FastCGI Process Manager, FPM, php-fpm

The process manager that runs PHP for web requests. A web server such as nginx, Caddy or Apache receives the HTTP request and hands it to PHP-FPM over the FastCGI protocol. In container setups the web server and PHP-FPM usually run in two separate containers.

At customcontainer Tick “FPM Package” and the image starts php-fpm, listening on port 9000 for your web server.

composer.lock #

lock file, composer.json

The file in which Composer records the exact version of every installed package. It also lists which PHP extensions those packages require — which makes it the most reliable description of what your application needs to run.

At customcontainer Paste it on the start page and we derive the extension list from it — no guessing, no forgotten ext- requirement.

Distribution #

distro, Linux distribution, Rocky Linux, Debian, Alpine

The Linux flavour the files in an image come from — Debian, Alpine, Rocky Linux and so on. It determines where the system libraries come from, how fast they receive security fixes and how long a release is supported.

At customcontainer Our images are currently built on Rocky Linux 9, an enterprise distribution with long support cycles. They do not contain its package manager or tools — only the files PHP actually uses.

RPM package #

package, rpm, dnf

The package format of Red Hat–style distributions such as Rocky Linux. Every library and every PHP extension arrives as a package with a name, a version and a release number — which makes it possible to say exactly what is installed and when it changed.

At customcontainer Every build records the exact package versions it contains. That is where your build history and the update feed get their data from.

Shared library #

system library, .so file, libxml2, OpenSSL, ImageMagick

Code that several programs share instead of each bringing its own copy — OpenSSL for encryption, libxml2 for XML, ImageMagick for images. Many PHP extensions are thin wrappers around such a library, which means a security hole in the library is a security hole in your PHP application.

At customcontainer An extension’s layer contains the libraries it links against. Leave out the extension and its libraries go with it.

Locale #

glibc locale, setlocale, de_DE, language settings

Language and regional settings at system level: how dates, numbers and currencies are formatted, and how text is sorted. PHP functions such as setlocale() or strftime() only work for locales that are actually installed in the image.

At customcontainer Every image includes C.utf8. Further locales, such as German or French, you add in the configurator.

Time zone data #

tzdata, timezone, date.timezone

The database of the world’s time zones and their daylight-saving rules. Without it a container only knows UTC, and converting a timestamp to “Europe/Berlin” at system level goes wrong.

At customcontainer Optional: tick “Include timezones” to add the tzdata layer.

Shell #

sh, bash, BusyBox, docker exec

A command line inside the container — what you get with docker exec -it … sh. Handy for debugging, but in production it is also a handy tool for an attacker. Many minimal images therefore ship without one.

At customcontainer Optional: tick “Include shell” to add BusyBox, a single small program that provides sh and the usual basic commands.

Terms at customcontainer

Words you will meet in your dashboard, in the configurator and in our update mails.

Container definition #

container configuration, configurator

What you set up in the configurator: PHP version, architecture, distribution, CLI and/or FPM, the extensions and the optional extras such as shell, timezone data and locales. One definition can be shared with your whole team, so development, CI and production use the same image.

At customcontainer Free accounts store up to four definitions.

Core layer #

base layer

The one layer every image gets: the basic file system, system users, CA certificates for HTTPS connections, the default php.ini and the system libraries everything else depends on. All other layers are stacked on top of it.

Release & version #

semver, semantic versioning, major, minor, patch

Every build of your container gets a version number following semantic versioning, MAJOR.MINOR.PATCH. The number tells you what kind of change to expect: patch for an automatic security or bug-fix rebuild, minor when you added an extension, major when you removed one or switched the PHP version or architecture.

At customcontainer Each version is pullable as its own tag, so you can pin 2.3.1 and move on your schedule.

Build history #

diff, audit trail, changelog

The list of every version of a container with the packages, versions and layers it contained. Pick any two versions and compare them to see what was added, removed or updated.

At customcontainer Shown on each container’s detail page — useful before a deploy and when an auditor asks what was running in March.

Registry endpoint #

registry URL, registry address

The address your images are pulled from. Your account has its own, of the form <id>.registry.customcontainer.io/<container-name>, and it speaks the standard registry protocol — Docker, Podman, Kubernetes and CI systems can use it without any extra setup.

Registry pull key #

registry token, registry password, docker login, private registry

The password for your private registry. You log in once with docker login (or podman login), using your account email as user name and the pull key as password; after that, pulls just work.

At customcontainer You find the key in your profile. It cannot be edited — if it leaks, generate a new one and the old one stops working.

Webhook #

notification, callback URL

A URL of yours that we call as soon as something happens — here: as soon as a new version of your container is ready to pull. That way your CI pipeline or team chat learns about an update without anyone having to check.

At customcontainer Set it per container in the configurator, optionally with a bearer token, and send a test call right from there.

Update feed #

updates, changelog

The public list of extension and library updates our build pipeline picked up recently. It shows what changed and when, independent of any single customer’s container.

Operations & security

Running containers in production and keeping them safe — the terms that come up in pipelines, deployments and security reviews.

CVE #

Common Vulnerabilities and Exposures, vulnerability, security advisory

A publicly catalogued security vulnerability with an ID such as CVE-2024-4577. Security scanners compare the packages in an image against these lists and report every match — which is why images full of unused packages produce long reports.

Attack surface #

minimal image, hardening

Everything in a system an attacker could try to exploit. Every extension, library and tool in an image counts — whether your application uses it or not. The smallest attack surface is simply the software that is not there.

At customcontainer That is the core idea of customcontainer: only what your application actually uses goes into the image.

End of life (EOL) #

security support, end of support, unsupported PHP version

The date after which a software version no longer receives fixes. php.net supports each PHP version for a fixed period — currently four years. After that, security holes in it stay open in the official releases.

At customcontainer We still build and patch images for PHP versions past their php.net end of life, such as 7.4.

CI/CD pipeline #

continuous integration, continuous delivery, GitLab CI, GitHub Actions

Automated steps that run on every push: install dependencies, run tests, build and deploy. Each job usually starts in a fresh container, so the image it pulls and how big it is directly affect how long every pipeline run takes.

At customcontainer Your image works as a CI job image — PHP and the right extensions are already in, nothing to install per job. In GitLab CI add entrypoint: [""], because the image starts PHP by default.

See also: Webhook, Layer More on this →

Docker Compose #

compose.yaml, docker-compose.yml, podman-compose

A YAML file that describes several containers that belong together — for example nginx, PHP-FPM and MariaDB — including their ports, volumes and environment variables. docker compose up starts all of them at once. The usual way to run a PHP stack locally.

Kubernetes #

k8s, pod, cluster

A platform that runs containers across a cluster of servers: it starts them, restarts them when they crash, scales them and routes traffic to them. Kubernetes pulls images from registries exactly like Docker does.

Volume & bind mount #

mount, -v, persistent storage

A container’s own file system is thrown away when the container is removed. To keep data, or to make your source code visible inside the container during development, you mount a directory into it — for example -v $(pwd):/app.

Port mapping #

port forwarding, -p, expose

Connects a port on your machine to a port inside the container, for example -p 8080:80. Containers in the same Compose setup or network can reach each other directly; the mapping is only needed for access from outside.

Environment variable #

env var, .env, -e, getenv

Key-value settings passed to a container at start, such as -e APP_ENV=production. The usual way to configure the same image differently for development, staging and production, without building a separate image for each.

SBOM #

software bill of materials, inventory, compliance

A machine-readable list of all software components in a product, with their versions. Increasingly requested by customers, auditors and regulations such as the EU Cyber Resilience Act.

At customcontainer Your build history records every package in every image we built for you — the container side of such an inventory. It does not cover your own Composer dependencies.

Enough theory

See it with your own composer.lock.

Paste your composer.lock on the start page and you get a PHP image with exactly the extensions your application needs — pullable right away, no account and no Dockerfile required.

Try the demo Register