- What is smorken/docker and how does it fit into a Laravel project?
- Smorken Docker is a set of Laravel base Dockerfiles that bundle containerized PHP-FPM, Nginx, MySQL and related services so a team can spin up a consistent local stack quickly. It is build-time infrastructure rather than a runtime library, so it does not execute inside your application and is not tied to a particular Laravel version. Treat it as an infrastructure-as-code template you review and own, not a package you upgrade.
- Is smorken/docker a Composer package or a repository I should clone?
- Both consumption styles are plausible: it may be installed through Composer to publish a docker directory, or cloned as a reference repository, and the overview does not settle which is intended. Either way the artifacts you end up with are Dockerfiles, not PHP code. Integration is a code-review-and-fork exercise rather than a versioned dependency upgrade.
- How do I install smorken/docker in an existing Laravel application?
- If you take the Composer route, require smorken/docker and publish the docker directory into your project; if you clone, copy the Dockerfiles in manually. Then point docker compose at those files and build the images. Because no vendor publish step or versioned release is documented, verify the resulting directory layout against the repository before relying on it.
- Which PHP and Laravel versions does smorken/docker support?
- The package does not version or pin PHP or Laravel versions itself, so compatibility depends entirely on the base images and extensions inside the Dockerfiles. You have to check the PHP minor version, required extensions such as pdo_mysql, redis, intl, gd and opcache, and the Nginx document root at public against your application's real needs. Verify each of these manually rather than assuming a supported matrix.
- What services and containers are included in the smorken/docker stack?
- The overview describes a runtime topology of PHP-FPM, Nginx, MySQL and related services, which maps onto what a typical Laravel application needs. Whether it also models a queue worker, scheduler, separate dev and production targets, multi-stage builds or a non-root user is not documented. Read each Dockerfile line by line to confirm what is actually there.
- Can I use smorken/docker in production?
- It is aimed primarily at local development, and the technical evaluation recommends adopting incrementally: local Compose first, then CI image builds, then production only after validation. Before any production use, pin every FROM reference to a digest, add a non-root user, keep the app image stateless with logs to stdout, and pass secrets as runtime environment variables rather than build args. Given the lack of maintenance signals, forking and hardening is a prerequisite, not an option.
- Is smorken/docker actively maintained?
- There is no visible maintenance signal: the repository is hosted on Bitbucket, shows zero stars and zero dependents, and the evaluation records no CI, image signing, SBOM generation or digest-pinned base references. Base images are the highest-leverage security surface in a Laravel deployment, so an unmaintained set of Dockerfiles is a liability that compounds every quarter. Assume you will own these files the moment you adopt them.
- How does smorken/docker compare to Laravel Sail or serversideup/php?
- Laravel Sail is the officially maintained development option for Laravel, and serversideup/php offers hardened, production-oriented PHP images with active maintenance. Smorken Docker is a smaller, unvalidated alternative with no community traction, which makes it hard to justify for a new project. The evaluation expects that comparison to conclude with replacing it, unless you specifically want a starting point to fork.
- How do I keep the base images in smorken/docker patched and free of CVEs?
- Fork the Dockerfiles into your own repository rather than tracking upstream, then pin every FROM to a digest so builds are reproducible. Wire Renovate or Dependabot to bump those digests and run Trivy or Grype against the built image in CI. Rebuild regularly and compare against a hardened baseline, since PHP minor versions and OS packages determine your entire CVE posture.
- How do I run Laravel tests and Artisan commands inside the smorken/docker containers?
- Run PHPUnit, Pest and Artisan through docker compose exec against the PHP-FPM or a dedicated workspace container so they use the same PHP version and extensions as the app. If no CLI service ships with the package, add one, and keep a separate dev build target so test dependencies never leak into the production image. Confirm the queue worker and scheduler run as their own services if your tests depend on them.