Docker Centos Laravel Package

Technical Evaluation

What this actually is. Despite being catalogued alongside Laravel/PHP packages, stackinstance/docker-centos is a Docker base-image repository — a Dockerfile (or set of them) wrapping CentOS — not a Composer package. It exposes no PHP namespace, no service provider, no composer.json-declared autoload, and no Packagist release. A TPM must first correct the category error: this cannot be composer required into a Laravel application, and it does not integrate with the framework at any layer (HTTP, queue, Eloquent, container bindings).

Architecture fit. Effectively zero for an application-level Laravel codebase. The only legitimate fit is as an upstream base layer for a custom PHP-FPM/Apache image — and even then, CentOS as a base is the wrong choice for a modern Laravel deployment given the ecosystem’s default alignment with Debian/Ubuntu (php:8.x-fpm, serversideup/php, Laravel Sail, etc.).

Integration feasibility. Blocked at multiple points:

• No semantic versioning or tags surfaced in the metadata, so no reproducible pin (FROM stackinstance/docker-centos:? is unresolvable).
• No CI badges, no published build matrix, no digest references.
• Zero dependents and zero stars means no field validation — no known production consumer to de-risk the choice.

Technical risk (high).

• Base-OS lifecycle: CentOS Linux 8 reached EOL in December 2021 and CentOS 7 in June 2024. Any image built on either inherits unpatched kernel/userspace packages and broken yum mirror URLs (mirrorlist.centos.org returns 404s), making yum install steps fail at build time.
• Supply chain: No provenance, no SBOM, no signing, no visible maintainer activity. Pulling an unmaintained, unsigned base image into a build pipeline is a direct CVE and reproducibility exposure.
• Support vacuum: No issue tracker activity, no release notes, no security contact.

Key questions for the maintainer (if pursued).

1. Which CentOS major/minor is pinned, and what is the patch cadence now that upstream is EOL?
2. Are images published to a registry with immutable digests, or must we build locally?
3. What PHP versions and extensions are pre-baked, and how are they updated?
4. Is there a migration statement to a supported base (Rocky, Alma, UBI, Debian)?
5. Who owns security triage, and what is the disclosure path?

TPM verdict: score 0, stars absent, dependents 0 — treat as an archived artifact, not a dependency. Do not adopt.

Integration Approach

Stack fit. Poor. A standard Laravel delivery stack is:

• Runtime: php:8.3-fpm-alpine or serversideup/php:8.3-fpm-nginx (actively maintained, signed, multi-arch).
• Web: nginx or Caddy in a sidecar/ingress.
• Data: managed MySQL/PostgreSQL + Redis.
• CI: GitHub Actions building multi-stage images with SBOM + Trivy scans.

stackinstance/docker-centos occupies only the "base OS" slot and does so with an EOL distribution. It contributes nothing to the Laravel-specific concerns (OPcache tuning, composer install --no-dev --optimize-autoloader, php artisan config:cache, queue worker supervision).

Migration path. There is nothing to migrate from — no consuming application exists. The realistic path is a substitution: if the team inherited a Dockerfile that FROMs this image, replace the base with a supported one and port the RUN steps:

1. Inventory the Dockerfile: OS packages, PHP build steps, extensions, entrypoint scripts.
2. Re-target to php:8.3-fpm (Debian bookworm) or serversideup/php, mapping yum install → apt-get install / docker-php-ext-install.
3. Replace supervisord-style process management with the maintained image’s s6-overlay or Laravel Octane/Sail conventions.
4. Validate parity: PHP version, extensions (pdo_mysql, redis, gd, intl, bcmath), OPcache settings, timezone, non-root UID.
5. Cut over in CI only after image scan is clean and a staging deploy passes.

Compatibility matrix to confirm before any port.

Sequencing. (1) Freeze any current use — do not rebuild. (2) Ratify a supported base image in an ADR. (3) Rebuild and scan. (4) Decommission the reference. There is no phase in which stackinstance/docker-centos is the correct forward dependency.

Operational Impact

Maintenance. This is the decisive factor. The repository shows no stars and no dependents, which for a Docker base image is the clearest possible signal of abandonment. An unmaintained base image is not a "low-maintenance" choice — it is deferred maintenance with compounding interest: every month it survives, the CVE delta grows and the rebuild path gets harder because yum repos have already rotted.

Support. No vendor, no community, no SLA, no CVE feed. In an incident, the team is the sole maintainer of the base layer — an implicit staffing commitment nobody has budgeted for. Escalation path is "read the Dockerfile."

Scaling. Container base images are horizontally agnostic; the image itself imposes no scaling ceiling. The real scaling cost is build-time and pipeline reliability: expired GPG keys and dead mirrorlists turn every CI run into a coin flip, and cache invalidation on a broken yum layer forces full rebuilds. At team scale, this becomes a shared tax on every service that inherits the image.

Failure modes.

• yum/dnf metadata fetch fails → build breaks with no code change (highest likelihood, near-certain).
• Registry pull fails or tag is mutable/missing → non-reproducible deploys.
• Undisclosed CVE in base packages → compliance/audit finding, potential breach exposure.
• Divergence from the PHP ecosystem → difficulty hiring, difficulty onboarding, snowflake image.
• Silent abandonment → no upgrade path discovered until a forced migration under pressure.

Ramp-up. The engineering friction is low in the narrow sense (a Dockerfile is readable), but the organizational ramp-up is high: someone must reverse-engineer intent, re-establish a supported base, and re-qualify the image through security review. Budget this as a small migration project, not a package evaluation.

TPM recommendation. Do not adopt; do not list as a dependency. Record it as archived / reference-only. If a team member has it in a Dockerfile, open a tech-debt ticket to re-base onto php:8.3-fpm or serversideup/php, gated on a clean image scan. Set a review checkpoint only if the maintainer publishes a supported base and versioned, digest-pinned releases — the current metadata (0 stars, 0 dependents, score 0) does not justify that checkpoint today.