laracom: a Laravel storefront with Docker Compose, mailhog and a seeded catalog

The feature list is a shopping domain, not a set of subsystems

laracom describes itself as free Laravel e-commerce software, and the features it names are Products, Cart, Checkout, Categories, Customers, Orders, Payment, Couriers and Employees. Read that list as a domain model rather than a promise of production readiness. A cart and a checkout tell you the customer-facing path is implemented, and orders give you the persistence boundary. Couriers and Employees point at a back office with two more actor types than a typical tutorial includes, and Payment is listed as a single word, which is the weakest signal in the whole list because no provider, gateway or flow is named anywhere on the page. The project also points to a full documentation site for details, and the repository carries a docs directory plus a project directory, a Dockerfile, an nginx configuration directory and a mailhog directory, so the code and its operational scaffolding are both in the repository. What the top of the repository does not show is any test suite, any CI configuration beyond a .travis.yml file, or a versioned release history, and those absences shape how much you can lean on this code.

The Docker Compose stack wires app, nginx, MySQL and mailhog

The Compose file is the clearest description of the intended architecture, because it names four services and the networking between them. The app service builds from the local Dockerfile, is named app, works in /var/www, mounts the./project directory there and mounts a PHP ini file from./php/local.ini. The webserver service is nginx:alpine, mounts the same project directory and the./nginx/conf.d/ directory into the container, and publishes port 8000 on the host. The db service is mysql:5.7 with homestead as both the database name and the user, plus a separate root password, publishing 3306, with the data directory mounted to./dbdata. The mailhog service builds from a local Dockerfile in the./mailhog directory and publishes 8025 for the web interface and 1025 for SMTP, with mail storage in maildir format under /home/mailhog/mails. All four services sit on a bridge network called app-network, and the only persistent volume beyond the project code is dbdata. The consequence for a reader is concrete: application code changes are picked up through the mounted directory, but database state survives in./dbdata, while files written outside the mounted paths are lost when the container is recreated.

Getting it running is a documented command sequence, not a one-line start

The README gives an explicit command list, and the order matters because the application container is built from the local Dockerfile, and the dependencies are installed inside it after the container exists. On a machine that is not Apple silicon, the first command builds and starts the stack in the background. On Apple silicon there is a separate compose file for that case.

docker-compose up -d --build
docker-compose -f docker-compose-m1.yml up -d --build
docker exec -it app bash
composer install && chmod -R 777 storage/ bootstrap/cache/
php artisan migrate --seed
npm i && npm run dev
php artisan storage:link

The first line builds the images and starts the containers detached, the second is the Apple silicon variant, the third opens a shell inside the app container, and the remaining four install the PHP dependencies, run the database migrations with their seed data, compile the front end assets and link the public storage directory for images. The README then says to open http://localhost:8000, which matches the port published by the nginx service in the Compose file. Two details are worth pausing on. The chmod of storage and bootstrap/cache to 777 is what makes the framework writable inside the container, and it is a permission model you would not ship to a shared host. And the migrate step uses --seed, so the catalog and demo data come from the seeders, which is exactly where you should look first to understand what a product row and an order row look like in this schema.

Mail testing goes through mailhog, and the env keys are fixed

Order confirmation emails are the first thing that breaks in a fresh Laravel install, and laracom has a specific answer for it. The README describes creating a ./mails directory, changing the .env file, and then visiting the mailhog interface on port 8025 to confirm the screen appears. The environment block it specifies is small and complete.

MAIL_DRIVER=smtp
MAIL_HOST=mailhog
MAIL_PORT=1025
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null
MAIL_FROM_ADDRESS="[email protected]"
MAIL_FROM_NAME="${APP_NAME}"

The host is the service name, which resolves inside the app-network, and the port is the SMTP port the mailhog service publishes. Setting the username and password to the literal string null rather than leaving them empty is unusual, and it is worth keeping exactly as written because the mailhog service in the Compose file is configured with no authentication. The MAIL_FROM_ADDRESS value of [email protected] is a placeholder for local use and has to change before anything real is sent. The value of this setup is that no credentials and no external service are involved, so you can develop the whole checkout and notification path offline and read the messages in a web interface.

The base image pins PHP 7.4 and Node 12.6.0, and that is the real risk

The Dockerfile is short, and the two version pins in it are the most consequential lines in the repository. The base image is FROM jsdecena/php74-fpm, which is a PHP 7.4 image published on Docker Hub for this project rather than an official image, so the base carries a third party's build choices and its own update schedule rather than upstream PHP patches. The environment sets NODE_VERSION=12.6.0, and nvm is installed by piping a script from a pinned tag of the nvm repository into bash, which then installs that Node version and aliases it as the default. The extension line installs mysqli, pdo_mysql and gd, so the container has the MySQL drivers and image processing but not the wider extension set. Composer is installed by piping the official installer into php. On the database side, the Compose file pins mysql:5.7, a version that has been superseded for a long time. So the stack runs, and it runs on a PHP major version, a Node major version and a MySQL major version that are all well behind current releases. That is fine for a local learning environment and a genuine liability for anything that will face the internet, and it also means that modern PHP tooling will not run inside this image without changes.

What the project leaves for you to build

Read the feature list against the repository layout and the gaps are visible. There is no mention of tax handling, no mention of discount or coupon logic, no shipping rate calculation even though couriers exist as a concept, and no refund, invoice or tax document model. Payment is a single line with no provider, which means either the project expects you to pick one or it defers the question entirely. There is no admin panel description, no multi-currency handling, no inventory or stock tracking, no review or rating model, and no email template or notification system beyond the mailhog plumbing. Some of these are ordinary scope choices for a free package. Others are decisions with a security dimension, since payment handling and stock accuracy are exactly the places where a demo implementation tends to be wrong. The repository also has a SECURITY.md file, so there is a disclosure path for problems in the code, but the page gives no detail about what security guarantees the package makes.

How laracom compares with building the same store on Laravel directly

The alternative is not a competing package so much as the two ends of the same spectrum. Starting from a fresh Laravel installation with an authentication scaffold, you get migrations, an ORM, a queue, a mail layer, a testing framework and a package manager for third party modules, and you assemble the store yourself: product and variant tables, a cart tied to a session or user, an order state machine, a payment abstraction and an admin scaffold. That route is slower to a working demo and much faster to a maintainable product, because every decision is explicit and you own the schema from the first migration rather than inheriting someone else's. laracom inverts that trade. You get a working store with a domain model, a Docker stack, seeded demo data and a documented setup in minutes, and you inherit the schema, the seeded assumptions, the old base image and the unanswered questions about payments. The sensible middle path is to run laracom locally to see the domain and read the seeders, then rebuild the parts that matter to you inside a Laravel version you can support, keeping the Docker Compose topology, which is the part that saves real time.

Editorial conclusion

Adopt laracom if you want a readable Laravel storefront to fork for a learning project or a prototype, and you are comfortable writing the parts it leaves out, such as taxes, shipping rates, refunds and a real payment provider. Do not adopt it for a store that takes money, because the payment layer is a single line in a feature list with no provider named, the Docker image is pinned to PHP 7.4 and Node 12.6.0, and the MySQL service is on 5.7. Before you build on it, check the current Laravel version the project directory targets, confirm that your provider's PHP extension set still matches the Dockerfile, and read the full documentation linked from the README for the parts this page cannot confirm.

Frequently asked questions

Official sources

1. Issues
2. jsdecena/laracom on GitHub
3. Project website
4. README