# EC-CUBE 4.4 is a Symfony shop built around Japanese tax and shipping rules > EC-CUBE is an open source e-commerce platform aimed at the Japanese market, written on Symfony 7.4 with Doctrine ORM and Twig. It is a full product rather than a library, and the pieces a developer touches first are the docker compose setup and the esbuild based frontend build. **EC-CUBE/ec-cube** — EC-CUBE is the most popular e-commerce solution in Japan - Repository: https://github.com/EC-CUBE/ec-cube - Website: https://www.ec-cube.net - Stars: 788 · Forks: 719 - Language: PHP - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/ec-cube-ec-cube ## The differentiators are Japanese tax rules, points and multi address shipping EC-CUBE describes itself as Japan's leading open-source e-commerce platform, powering over 35,000 online stores, and says it provides a full-featured, highly customizable solution designed specifically for the Japanese market. The customisation claim comes with a plugin marketplace, the Owners Store, and the repository's own line about a dedicated marketplace for extensions. The features listed as differentiators are the clearest statement of who the project is for. Native support for Japan's reduced tax rate and consumption tax rules comes first, which tells you the target customer is a domestic retailer rather than an international seller. A built-in point system for customer rewards comes next. Then multiple shipping, meaning a single order can be sent to several addresses, which is a normal request in Japan and a real feature gap in many generic carts. None of these are hard for a capable team to build. The point of shipping them in the box is that they are decisions with legal and accounting consequences, and getting Japanese consumption tax handling right is the sort of work that produces support requests rather than feature requests. The project also splits its maintenance by major version. Development for the 3 series lives in the EC-CUBE/ec-cube3 repository and for the 2 series in EC-CUBE/ec-cube2, while the repository you are reading holds the 4.4 line. ## Symfony 7.4, Doctrine ORM 3, Twig 3 and a jQuery carrying frontend The technology stack table in the README is precise: PHP 8.2, 8.3, 8.4 or 8.5; Symfony 7.4 as the framework; Doctrine ORM 3.x with DBAL 4.x; Twig 3.x for templates; PostgreSQL 13 to 18 or MySQL 8.4 LTS for storage; and on the frontend Sass, esbuild, Bootstrap 5.3 and jQuery. The layout follows a familiar Symfony arrangement. The tree contains app/, src/, bin/, tests/, e2e/, html/, var/, scripts/, and the usual configuration files, with composer.json and composer.lock at the root alongside symfony.lock, which records the exact Symfony component versions in use. Two entries are unusual enough to notice. AGENTS.md collects layer specific implementation rules, which means the project has written down conventions that an automated contributor is expected to follow. CLAUDE.md, GEMINI.md, a .claude/ directory and a .codex/ directory sit next to it, and the README links an LLM-friendly documentation file at ./llms.txt. In other words, the repository is being packaged for machine contributors, not only human ones. The frontend stack deserves a caveat, because the table and the manifest disagree. The README lists jQuery 4.x, while package.json depends on jquery ^3.7.1, alongside bootstrap ^5.3.8, chart.js ^4.5.1, sortablejs, slick-carousel, filepond and ladda. Whichever is authoritative, a customiser should check the installed version rather than assume 4.x. ## Two installation paths, docker compose or Composer The README gives a Docker path as the recommended quick start, with PostgreSQL selected by an extra compose file: ```bash git clone https://github.com/EC-CUBE/ec-cube.git cd ec-cube docker compose -f docker-compose.yml -f docker-compose.pgsql.yml up -d # Access http://localhost:8080 ``` A MySQL variant exists as docker-compose.mysql.yml, and the Compose file publishes port 8080 on the host mapped to 80 in the container, with 4430 mapped to 443 for the TLS port. The Composer path creates the project and runs the console installer: ```bash composer create-project ec-cube/ec-cube ec-cube "4.4.x-dev" --keep-vcs cd ec-cube bin/console eccube:install ``` The eccube:install command is the concrete first use in both paths. It is the step that turns a checked out or created project into a working shop, and it is the point at which you will be asked for the pieces of configuration that the platform needs. The Composer path pulls the 4.4.x-dev branch rather than a tagged release. That is a deliberate consequence of the current release state, and it is also a reason to pin a version rather than tracking the branch in production. ## Frontend assets are built by esbuild and Sass, and bundle.js is edited by hand Styles are written in Sass, with the sources under html/template/{admin,default}/assets/scss, and the build writes CSS into the assets/css directory of each template under html/template. Node.js has to be installed first. ```shell npm start ``` That is the watch mode: it runs the esbuild config with the watch flag so CSS and JavaScript are rebuilt as you edit. The full build is the npm run build script, which maps to node esbuild.config.mjs and handles both Sass and JavaScript, and npm ci is the dependency install step to run on a first checkout or whenever package-lock.json changes. The JavaScript libraries used by the frontend are managed through npm and bundled and minified with esbuild. To change which libraries get bundled, the README instructs you to edit the per template bundle.js files and rebuild. The files named are html/template/admin/assets/js/bundle.js, html/template/default/assets/js/bundle.js, and html/template/install/assets/js/bundle.js. If you develop inside docker compose, the same build runs inside the nodejs service instead: ``` shell docker compose -f docker-compose.yml -f docker-compose.dev.yml -f docker-compose.nodejs.yml run --rm -T nodejs npm ci docker compose -f docker-compose.yml -f docker-compose.dev.yml -f docker-compose.nodejs.yml run --rm -T nodejs npm run build ``` Editing a checked-in bundle file by hand is the unusual part of this workflow. Bundled output usually belongs to the build, so treat those three files as configuration rather than generated assets. ## The default container environment runs SQLite while the requirements list PostgreSQL and MySQL The Compose file sets development environment variables for the ec-cube service, and one of them is worth reading before you trust the container. DATABASE_URL is set to sqlite:///var/eccube.db with DATABASE_SERVER_VERSION: 3 and DATABASE_CHARSET: 'utf8', and MAILER_DSN points at smtp://mailpit:1025. Other keys are present but commented out, including ECCUBE_LOCALE, ECCUBE_TIMEZONE, ECCUBE_CURRENCY, ECCUBE_ADMIN_ROUTE and ECCUBE_USER_DATA_ROUTE, so the shipped defaults are Japanese yen and Japanese locale with an English database. The documented system requirements list PostgreSQL 13.x to 18.x and MySQL 8.4.x LTS as the supported databases, and the base image installs the pgsql and pdo_pgsql extensions alongside mysqli and pdo_mysql. The SQLite default in the development Compose file is a convenience for a quick start, not a statement that SQLite is a supported production database. The image itself is parameterised. The Dockerfile starts from php:${TAG} with TAG defaulting to 8.2-apache, and the Compose file exposes TAG, IMAGE_NAME and REGISTRY variables so a build for another PHP version is a matter of setting TAG. The extension install list EXT_INSTALL_ARGS is version aware, and the Dockerfile comments explain that opcache becomes statically built in from PHP 8.5, which changes what has to be installed. ## CI, static analysis and Rector run before a pull request is merged The badges at the top of the README point at four workflows, and they describe the shape of the project. There is a unit test workflow, an E2E test workflow, a plugin test workflow and a PHPStan workflow. The E2E directory and the tests directory in the tree match those jobs, and the presence of a dedicated plugin test job means plugins are exercised against the core rather than only type checked. The contribution guide is where the required checks are spelled out. The README says to refer to CONTRIBUTING.md for the concrete procedure, which covers building the development environment, branch handling with pull requests targeting the 4.4 branch, the CI checks that should pass before a pull request is opened, those being code style, static analysis, Rector and tests, and licence headers. Layer specific implementation rules are collected in AGENTS.md. The tooling matches. phpstan.neon.dist configures static analysis, rector.php with a rector/ directory configures automated refactoring, .php-cs-fixer.dist.php handles code style, and phpunit.xml.dist configures the test runner. package.json wires php-cs-fixer into lint-staged for staged PHP files, and husky runs through the prepare script, so a local commit can be checked before it reaches GitHub. One rule is worth knowing before you write any code: the README asks contributors to open an issue or a proposal in the issue tracker first, and the pull request template asks for the intent to be stated in the pull request description when the change is not a refactoring or a bug fix. ## Licence wording is inconsistent across the repository and needs checking The licence picture is the least tidy part of the repository. The repository record classifies the licence as a custom one that GitHub cannot classify, and points to the LICENSE file, which at the top level is LICENSE.txt, with a separate COPYING file also present. Meanwhile package.json declares the license field as GPL-2.0. Two different signals about terms are visible in the tree, so a team that intends to modify EC-CUBE in-house and ship the result should read both files rather than assume which one governs. There is a further condition attached to contributing rather than to use. The README states that contributing code, filing issues or opening pull requests counts as agreement with the EC-CUBE copyright policy, and that you need to understand and accept it. A project that treats issue filing as a licence acceptance is signalling that the copyright holder wants visibility into outside contributions, which is a normal position for a commercial-backed open source product but does put the terms of use itself somewhere other than a plain MIT or GPL grant. For maintenance, the last push was on 2026-10-20 and the repository is not archived. The release history shows 4.4.0-alpha-1 published on 2026-09-25, and two patch releases from March 2026, 4.3.1-p1 and 4.2.3-p2, both on 2026-03-04. The roadmap for the 4.4 release content and plans is tracked in an issue in the repository, so the plan for the current branch lives there rather than in a release note. ## Conclusion EC-CUBE is a good fit for a team selling in Japan that wants a storefront with consumption tax handling, reduced tax rate support, customer points and multi address shipping already built in, and that accepts working inside a full application rather than assembling its own. It is the wrong choice for a single market store outside Japan, where the Japanese tax rules are dead weight and the plugin marketplace offers little, and for teams unwilling to carry a PHP and Symfony stack. Verify three things before committing: the database you plan to use, since the default docker compose environment points DATABASE_URL at SQLite while the documented requirements list PostgreSQL 13 to 18 and MySQL 8.4 LTS, the licence terms in LICENSE.txt and COPYING, since package.json declares GPL-2.0 while the repository licence is recorded as a custom one GitHub cannot classify, and the release you pin, since the default branch 4.4 currently sits at the 4.4.0-alpha release published on 2026-09-25. ## FAQ ### How do I install EC-CUBE 4.4 locally? The README gives a Docker path with git clone, cd ec-cube and docker compose -f docker-compose.yml -f docker-compose.pgsql.yml up -d, which serves the site on http://localhost:8080, and a Composer path with composer create-project ec-cube/ec-cube ec-cube "4.4.x-dev" --keep-vcs followed by bin/console eccube:install. ### Which databases does EC-CUBE 4.4 support? The documented system requirements list PostgreSQL 13.x to 18.x and MySQL 8.4.x LTS. The default docker compose environment sets DATABASE_URL to a SQLite file for convenience, while the Docker image installs the pgsql, pdo_pgsql, mysqli and pdo_mysql extensions. ### How do I rebuild the CSS and JavaScript after editing templates? Styles are written in Sass and compiled into the assets/css directory of each template under html/template, and JavaScript is bundled and minified with esbuild. Run npm ci followed by npm run build, or npm start to watch for changes. To change which libraries are bundled you edit the per template bundle.js files and rebuild. ### What licence does EC-CUBE use? The repository licence is recorded as a custom licence that GitHub cannot classify, with the terms in LICENSE.txt and a separate COPYING file at the top level, while package.json declares the license field as GPL-2.0. Read both files to confirm the terms that apply. Contributing code or filing an issue counts as agreement with the EC-CUBE copyright policy. ### Is EC-CUBE 4.4 a stable release yet? The newest release is 4.4.0-alpha-1, published on 2026-09-25, and the Composer quick start installs the 4.4.x-dev branch. The plan for the 4.4 release is tracked in a roadmap issue in the repository. ## Sources - [EC-CUBE/ec-cube on GitHub](https://github.com/EC-CUBE/ec-cube) - [Issues](https://github.com/EC-CUBE/ec-cube/issues) - [Project website](https://www.ec-cube.net) - [README](https://github.com/EC-CUBE/ec-cube/blob/4.4/README.md) - [Releases](https://github.com/EC-CUBE/ec-cube/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ec-cube-ec-cube