TL;DR – The most important information at a glance
- local mc is a preconfigured DDEV integration that accurately maps the service environment of your maxcluster server locally – automatically, without manual mapping.
- You can develop and test changes locally in a production-like environment and detect errors earlier.
- The tool was developed based on specific requirements in customer projects and was further developed jointly in the Customer Advisory Board (CAB).
- The tool is currently in the beta phase and supports macOS and Linux.
- The result: more stable deployments, fewer surprises during operation, and less effort in the development process.
Good tools aren’t built in an ivory tower
If you develop software, you know the problem: everything works locally — then after deployment, reality suddenly looks different. Even small differences between the development and production environments can lead to bugs, extra effort, and uncertainty. The result is the familiar “works on my machine” syndrome.
And this isn’t just frustrating — it’s financially relevant, too. Recent studies underline the impact: according to the Tricentis Quality Transformation Report 2025, 42% of companies say poor software quality costs them more than USD 1 million per year (around EUR 930,000). In the US, 45% report losses of more than USD 5 million per year (around EUR 4.6 million). (Source: Tricentis Quality Transformation Report 2025).
A major cost driver is defects that are only discovered late in the development cycle. Findings often cited in the IBM/NIST context show that bugs found in production cost a multiple of those detected and fixed during development. (Source: Functionize).
That’s exactly where local mc comes in. It’s a local development environment that brings you closer to production reality — and makes issues visible before they hit live operations. This focus isn’t accidental: local mc was developed in close collaboration with the Customer Advisory Board (CAB) — an approach where customer feedback isn’t collected after release, but guides the entire process end to end.
local mc: Production-like development — built local-first
local mc stands for “local maxcluster”. In practice, it’s a preconfigured DDEV integration that mirrors the exact service definitions and versions of your maxcluster server environment locally — automatically, without you having to research and configure your PHP version, database type, or caching setup by hand.
Two ways to set it up
- Via Cluster-Control: local-mc:ddev:config:new --domain=example.com --doc_root=/var/www/html --domain_suffix=.local
- Via the GUI: Alternatively, you can download the configuration package directly in the Managed Center under “vHosts”.
In both cases, you get a local environment that matches your production setup structurally — reproducible, and without manually rebuilding individual services.
Technically, local mc is based on DDEV, an established open-source tool for local development environments. DDEV uses container technology and reliably maps typical e-commerce setups: web servers, PHP runtimes, databases, caching mechanisms, and search and messaging services. It is precisely this breadth that makes DDEV a suitable basis for production-oriented local development in the e-commerce environment.
The result: you work locally under realistic conditions. Errors become visible earlier, changes can be tested more reliably, and the need for additional test or staging instances on the cluster is significantly reduced.
local mc is currently in the beta phase and is being actively developed. Changes to the range of functions or individual commands are therefore possible. macOS and Linux are currently supported.
If you want to dive deeper, you can find all the technical details and complete step-by-step instructions in the Knowledge Base: https://knowledge.maxcluster.de/local-mc-informationen-und-einrichtung
What problem does local mc solve?
When you run applications such as Shopware or Magento on maxcluster, errors often arise due to small but crucial differences between the development and production environments—for example, in PHP versions, database setups, or caching configurations. It is precisely these discrepancies that cause errors to become apparent too late.
Typical consequences in everyday developer life
- Late error detection: Bugs are only noticed during deployment or during operation.
- High repair costs: Errors are significantly more expensive to fix in production than in the development phase.
- Additional infrastructure requirements: In order to be able to test close to production, separate staging environments are often operated on the cluster – with the corresponding resource and coordination costs.
This problem is well known in software development. The Twelve-Factor App describes it as a lack of Dev/Prod parity and explicitly recommends keeping development and production environments as similar as possible.
This is exactly where local mc comes in: the local development environment is structurally aligned with the production environment. This makes errors visible earlier – even before code is rolled out to a staging or production environment.
Important: local mc does not replace a staging or test environment on the cluster. Staging remains relevant for integration, load, and acceptance testing. However, local mc shifts a large part of error detection forward – to the local machine.
Why DDEV – a conscious decision
The technical basis focused on a practical question: Which tool works reliably in everyday development work – and can be realistically integrated into existing workflows?
The choice fell on DDEV. Alternatives such as Devenv (which Shopware officially recommends) were considered, but presented greater hurdles: translating Debian packages into Nix packages would be an additional effort for many teams without any direct added value. DDEV has been proven in the PHP community for years, and many developers are already familiar with it from projects with Shopware, Magento, Drupal, or WordPress—and it is precisely this familiarity that lowers the barrier to entry.
Why DDEV is a good fit for local mc
- Maturity & stability: DDEV is used productively in numerous projects and is correspondingly mature.
- Broad service support: PHP, Node.js, MySQL, Redis, Elasticsearch/OpenSearch, Varnish, RabbitMQ, and other components can be reliably mapped.
- Active community: Regular updates and continuous development ensure long-term maintainability.
- Suitability for everyday use: The entry threshold is low, and existing workflows can be quickly integrated.
From idea to tool: the role of the Customer Advisory Board (CAB)
local mc did not come about in isolation. The Customer Advisory Board (CAB) of maxcluster played a central role in this process – a well-established committee of selected customers designed for regular, open exchange on an equal footing.
The CAB is deliberately more than a classic feedback channel. It sees itself as a working and dialogue platform – not a one-way street – where customers are actively involved in the further development of products and services. Perspectives, requirements, and experiences are incorporated at an early stage, not only after a release, but already during the conception and development phase.
What topics are discussed in the CAB?
- Strategic questions about the further development of maxcluster
- Specific requirements for products, tools, and workflows
- Operational challenges from everyday customer life
- Technological trends relevant to e-commerce operations
- Not a sales format – but genuine collaboration
The CAB sees itself as a working and dialogue platform on an equal footing. The focus is not on communication, but on co-creation: customers actively contribute their requirements, experiences, and criticism, while maxcluster provides early insight into plans and roadmaps. Feedback does not remain theoretical, but flows directly into prioritization and implementation. A joint NDA framework creates the necessary confidentiality for open and constructive discussion.
How does the collaboration work?
- Online sessions for status updates, feedback, and focused discussions
- On-site meetings to explore more complex topics in depth together
- Asynchronous communication between meetings for ideas, questions, and ongoing feedback
local mc as the result of genuine collaboration
The starting point for the development of local mc were real challenges from ongoing customer projects that repeatedly arose in the daily operation of e-commerce applications.
Typical pain points from everyday developer life
- Different PHP versions, database setups, and toolchains led to inconsistencies within teams: inconsistent local setups
- A lot of time was lost clarifying whether an error could be reproduced locally or only occurred in the server environment: high debugging effort
- In order to be able to test close to production, separate test environments were operated on the cluster – with the corresponding costs and organizational effort: additional staging instances
- New team members often needed several days to set up a locally executable and realistic development environment: time-consuming onboarding
The joint analysis made it clear that many of these problems are structural in nature: regardless of project size, agency structure, or shop system used, similar patterns repeat themselves—especially when it comes to coordinating the local development environment and production operations.
The development of local mc followed an iterative approach in which the CAB was closely involved. Together, a minimum viable product (MVP) was first defined—with a clear focus on key practical requirements: reproducible environments, automated server configuration transfer, and the lowest possible barrier to entry for development teams.
Building on this, technical concepts were specified, prototypes were tested under production-like conditions, and gradually refined—until reaching the current beta phase, with continued close communication. Feedback was continuously incorporated. This did not happen via formal tickets, but rather through direct dialogue between developers, product managers, and users.
Benefits for CAB members
Participation in the Customer Advisory Board offers advantages that go far beyond traditional feedback formats. The focus is on active participation.
CAB members not only benefit from early information, but also from actual opportunities to participate in the design process:
- Early insight into plans, roadmaps, and new features
- Direct influence on product decisions and priorities
- Exchange with experienced developers, agencies, and technical decision-makers
- A confidential setting for open and honest discussions
Who can participate?
Membership in the CAB is deliberately limited to ensure a high-quality exchange. The decisive factors are not company size or turnover, but rather:
- technical expertise
- relevant use cases
- willingness to actively participate
📧 Contact: cab@maxcluster.de
👤 Contact person: Aleksandra Perko-Klomfaß (Product Owner)
CAB 2025/2026: The exchange continues
The Customer Advisory Board (CAB) is not a one-off project, but is designed as an ongoing dialogue. In the CAB year 2025, the focus was on close cooperation on specific topics – including the conception and development of local mc.
This approach will be consistently continued in 2026. The topics are not determined top-down, but are defined together with the CAB members. The decisive factors here are real requirements from everyday work and current technological developments in the e-commerce environment.
Planned focal points include:
- Perspective further development of local mc
- New functions and optimizations in the Managed Center
- Performance topics with a clear focus on visibility, transparency, and targeted optimization
Currently, the CAB's main focus is on performance: bottlenecks should be identified early on, optimization potential should be identified in a structured manner, and existing systems should be measurably improved.
The goal remains the same: transparency in communication, clear priorities in implementation, and solutions that work under real operating conditions – not just in theory.
Conclusion
local mc shows what production-oriented development can look like today: local, realistic, and closely aligned with actual operational requirements. Instead of accepting differences between development and production, the development environment is deliberately brought closer to reality—with measurable added value for stability, quality, and efficiency.
The decisive factor here is not only the tool itself, but also the path to it. Thanks to close cooperation in the Customer Advisory Board, customer feedback is incorporated into development at an early stage and in a structured manner. Requirements arise from real workflows – not from assumptions or theoretical ideals.
local mc is therefore more than just a local development environment. It is an example of how maxcluster develops products together with customers: practical, iterative, and with a clear focus on the everyday work of development teams.
We welcome feedback on local mc:
📧 feedback@maxcluster.de
Interested in joining the Customer Advisory Board?
📧 cab@maxcluster.de
FAQ: Frequently asked questions about local mc and the Customer Advisory Board
Does local mc replace a staging or test environment on the cluster?
No. local mc is intended to complement existing development and testing processes. The goal is to test changes locally at an early stage and in a production-like environment before rolling them out in staging or production environments.
Can I use local mc even if I am not a CAB member?
Yes. local mc is available to all customers who run applications on maxcluster. The CAB is a separate committee for anyone who wants to actively participate in further development.
Why is local mc still in the beta phase?
local mc is still in the beta phase. Further development is planned and will be based on specific requirements and feedback from practical use. Feedback from real projects will serve as the basis for possible adjustments to the range of functions and workflows.
What role does customer feedback play in the further development of local mc?
Customer feedback is a central component of further development. Feedback from the CAB and from the broader user base flows directly into the prioritization and implementation of new features.
Is the Customer Advisory Board only intended for large companies?
No. The decisive factors for participation are technical expertise, relevant use cases, and a willingness to actively participate—not the size of the company.
The CAB is not exclusively aimed at developers. Technical project managers are also welcome.
