Magento Open Source
Magento Open Source costs nothing in licence fees but demands operation that thinks ahead: monthly security patches, a fixed end of support for every release line, and a stack of PHP, database, OpenSearch, Valkey, Varnish and message queue that moves with each version. Release 2.4.9 showed it again: PHP 8.5, MariaDB 12.3, OpenSearch 3. Sharpness Solutions GmbH in Oldenburg builds new Magento shops where Magento fits, takes over existing ones, keeps them current and runs them on its own servers in Germany. This page explains how Magento Open Source differs from Adobe Commerce and Mage-OS, how a takeover works, how patches and upgrades are planned and what operation demands. It also says when Shopware 6 is better. A Magento shop is only as secure as its last applied patch.
Most Magento shops have been running for years and bring in revenue. The questions arrive all the same, usually with a date attached: an end of support, a critical bulletin, an update that fails on the server. Six starting points come up again and again. What they have in common: with Magento, the work does not come as a surprise — it comes by the calendar.
Regular support for Magento 2.4.6 ended on 11 August 2026; for 2.4.4 and 2.4.5 it ended in 2025. Adobe describes extended support explicitly for Adobe Commerce customers, so anyone running Magento Open Source plans with the regular date. A shop without a support commitment is not broken — it just takes more effort to secure with every month.
In September 2026 Adobe closed a critical vulnerability with APSB26-146 that, according to Adobe, was already being exploited — with a hotfix of its own. The October bulletin APSB26-153 does not contain that hotfix; it has to be applied separately. Install only the latest package and that exact hole stays open.
According to Adobe's system requirements, 2.4.9 runs on PHP 8.5, MariaDB 12.3 or MySQL 8.4, OpenSearch 3 and Valkey 9. Before the update comes a rebuild of the server, not just a Composer command. Budget the upgrade as a version bump and you get a figure that falls apart during the project.
The shop was built years ago, the developers from back then are out of reach, the documentation is thin. Whether anyone changed the core, which extension overrides what and which cron job does what — nobody knows for certain. All of that can be found out: before the first change, not after it.
With 2.4.9 Adobe replaces Zend_Cache with symfony/cache and the Laminas MVC layer with its own implementation. Extensions built on them have to be adapted before the update can go live. Whether the vendor does that in time is written in no contract; whether it is needed shows up in a test on the staging system.
Shop prices lag behind the ERP, mass actions stall, stock levels are wrong. With Magento, symptoms like these often come down to cron jobs that do not run or queue consumers that nobody started. A Magento shop without monitoring does not report such faults — it shows them to your customers.
Magento Open Source is the freely available edition of Magento 2. Its source code is licensed under the Open Software License 3.0, and the repository also carries the Academic Free License 3.0; there are no licence fees. It is installed with Composer from Adobe's package repository, and even open-source shops need access keys from the Commerce Marketplace for that. The shop runs on infrastructure of your choosing: servers, hosting and maintenance sit with whoever operates it. The package contains more than many expect — Page Builder, Inventory Management (MSI), REST and GraphQL APIs, two-factor authentication for the admin and reCAPTCHA. No licence does not mean no effort, though. The cost simply moves from the licence to operation.
Adobe Commerce is the licensed edition with additional features. According to Adobe, only it offers, among other things, Content Staging for scheduled content changes, customer segments, Reward Points, returns via RMA, Live Search, Product Recommendations and the B2B module, which needs a separate licence on top. Adobe's cloud infrastructure and the SaaS offering Adobe Commerce as a Cloud Service also belong to Adobe Commerce. For many shops that is more than they use; customer-specific prices, approvals or returns workflows can be built in Open Source as custom modules, as our Magento development page describes. Where an Adobe Commerce licence is already in place, we work with that too. What matters is not the edition but whether its features are actually needed.
Mage-OS is an independent, community-driven distribution of Magento Open Source. Behind it stands the Mage-OS Association, a non-profit organisation registered in Poland whose board is elected by its members every year. Mage-OS stays compatible with Magento Open Source, and a way back to the original is part of the design. The 3.x line is based on 2.4.9; version 3.6.0 of 14 October 2026 contains the security fixes from Adobe's October bulletin. For a shop, Mage-OS is therefore not a different platform but a different delivery route for the same code. Whether it brings you any advantage is something we assess against your extensions and the update rhythm you want. Operation, patching and development work the same way for both.
Magento plays to its strengths where catalogues are large and rules are many: lots of products with lots of variants, several stores, languages and currencies in one installation, a great deal of custom logic in pricing, checkout and ordering, and B2B with customer-specific prices and approvals. Its attribute model carries technical ranges whose properties need to be filterable. For projects like these we build new shops on Magento Open Source, free of licence fees and on our own servers in Germany. A new shop starts on 2.4.9, the current line with regular support until 31 May 2029. For the frontend, the Hyvä Theme is an option — free since 10 November 2025 and under the same licences as Magento. Magento is the right choice when a shop has to carry more than the standard.
One example is the Magento shop of Manotura GmbH & Co. KG for irrigation technology. The range needs explaining — sprinkler systems, pipe systems, accessories — and the attribute model maps the technical properties, so customers filter by real selection criteria rather than category names. Variants, tiered prices and accessory links are part of the data structure. Item master data, prices and stock come from the ERP and orders flow back, through scheduled jobs with logging and retry logic. More than 12,000 products are synchronised, prices and stock are reconciled every hour, and maintenance effort is around 40 % lower than with double data entry. The shop runs with Docker on our servers in Germany, including updates, backups and monitoring. Data is maintained in one place, not two.
Magento is powerful, and that comes at a price: more services to operate, a tight rhythm of patches and upgrades, development that needs experience with the framework. For a mid-sized shop with a manageable range and little custom logic, Shopware 6 is usually the more economical choice — leaner to run and close to the German market. We build that as well: Sharpness is a Shopware Extension Partner, and migrating from Magento to Shopware 6, with data, redirects and a tested cutover, is part of our project work. What speaks against a switch is a well-maintained Magento shop whose custom logic would be expensive to rebuild. A working system is no reason for a new build. We do this sum before the project, not halfway through.
Taking over a Magento shop that someone else built is routine for us. It starts with an audit: Magento version and patch level; PHP, database, search service and cache compared with Adobe's system requirements; installed extensions with their origin and version; custom modules in app/code; and whether anyone has changed the core or the vendor directory. Add to that cron jobs, queue consumers, interfaces and the server environment. The result is a written report with risks, sequence and effort in person-days. An audit costs less than the first outage that would otherwise take its place.
The report shows what has to happen at once and what can be planned. At once means: apply missing security patches, test backups that have never been restored, tidy up admin accounts, enforce two-factor authentication and set up monitoring. Planned means: replace extensions nobody maintains, move core changes into custom modules, bring the stack up to a supported level. Adobe provides its Upgrade Compatibility Tool for Adobe Commerce only; for Magento Open Source we check extensions and custom code against the target version ourselves, using the Magento Coding Standard and tests on the staging system. Keep urgent and important apart, and you do not have to pay for everything at once.
A takeover also covers access and ownership. Before anything else — not during an incident — we establish where code, database and media live, who holds the access keys for Adobe's Composer repository, and in whose name the domain, payment providers and extension licences are registered. The code goes into a Git repository that belongs to you, the domain stays registered in your name, and the Marketplace keys run through your company. If you wish, we move the shop to our servers, first as a staging copy, then in an agreed maintenance window. If Magento 1 is still running, the situation is different: it has received no security updates since June 2020, and the way forward is a new build with data migration. A shop is only taken over once all access is settled.
Adobe delivers security fixes for Magento in two ways. The -p releases such as 2.4.8-p5 are cumulative levels of a release line and are installed with Composer; according to Adobe, at least one appears each year for every supported line. In between, Isolated Security Patches arrive monthly on Patch Tuesday, the second Tuesday of the month — explicitly for Magento Open Source too. They are code diffs rather than Composer packages, do not build on one another and are applied in order, starting from the latest -p level. Then there are emergencies such as the hotfix from APSB26-146. The Commerce Version Tool checks which level is installed. We apply every patch on staging first, then in the live shop, and record it. A patch that has only been downloaded protects nothing.
Under Adobe's lifecycle, every line has a fixed end of regular support: 2.4.6 on 11 August 2026, 2.4.7 on 31 May 2027, 2.4.8 on 31 May 2028, 2.4.9 on 31 May 2029. Adobe describes a further year of extended support explicitly for Adobe Commerce customers; for Magento Open Source, plan with the regular date. On top of that come the lifecycles of the services underneath. MySQL 8.0 reached its end of support on 30 April 2026, Elasticsearch 7.17 on 15 January 2026, and Adobe supplies no fixes for third-party components after their end of life. Plan upgrades by the calendar and you never have to rush them.
Magento 2.4.9 has been available since 12 May 2026. According to the system requirements table it runs on PHP 8.5, MariaDB 12.3 or MySQL 8.4, OpenSearch 3, Valkey 9, Varnish 8, nginx 1.30, Composer 2.10 and RabbitMQ 4.3 or ActiveMQ Artemis 2; Redis and Elasticsearch are no longer listed. Adobe's own example is to raise MariaDB to 12.3 before upgrading. In the code, 2.4.9 replaces Zend_Cache with symfony/cache, moves Symfony to 7.4 LTS and swaps the TinyMCE editor in the admin for HugeRTE. We set the sequence — stack, extensions, custom code, Magento — in the audit and test it in full on staging. How the search service switch works is described on our OpenSearch shop search page. An upgrade is a scheduled piece of work, not a click in the admin.
A Magento shop is not a single program but a set of services: PHP behind nginx, MariaDB or MySQL, OpenSearch for catalogue and search, Valkey for cache and sessions, Varnish as the HTTP cache in front, plus RabbitMQ or ActiveMQ Artemis for the message queue. If one of them fails, the shop notices at once. At Sharpness these services run on our own servers — Proxmox PVE clusters in the Hetzner data centre in Falkenstein, Germany — containerised with Docker, with each client environment kept separate. Staging and live run the same versions, so an update is tested where it will later run. Search service and cache are reachable only by their own shop. A staging system built differently from the live shop is testing something else.
Much of what Magento does happens in the background. Cron jobs keep the indexers current — a one-off reindex is no substitute — send emails and clean up. Queue consumers work through mass actions, stock changes from Inventory Management and bulk calls to the REST API; if they are not running, the work piles up without anyone seeing an error message. That is why we monitor not only servers and response times but also indexer status, cron runs and queue lengths. Deployments run through Composer in production mode with setup:upgrade, setup:di:compile and setup:static-content:deploy, with versioned configuration and a backup immediately beforehand. Incidentally, Content Staging in Adobe Commerce is something quite different from this staging system. A fault found by monitoring costs less than one reported by a customer.
After the takeover or go-live, we run and maintain the shop under a service level agreement. There are three tiers: BASIC with 24, STANDARD with 8 and ADVANCED with 4 hours response time. An SLA is a standby commitment — the response time is booked for a year, while the work itself is billed by effort or within an individually agreed framework that already includes hours. The hourly rate is tiered: weekdays during working hours, weekdays outside them, and weekends and public holidays; we quote the rates on request. Without an SLA we handle requests within 48 hours during our business hours, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET); on-call cover is available only with an SLA. Patches, upgrades, operation and further development thus come from a single source.
Process
Send us your Magento version, your hosting and a few lines on what is coming up: an end of support, a bulletin, an upgrade, a takeover or a new shop. You will get an initial assessment, without obligation, of which route fits and what the effort depends on in your case. Phone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). We work remotely across Germany; meetings in Oldenburg and north-west Germany by arrangement.
You describe the situation: Magento version, hosting, what is pressing — an end of support, a bulletin, an upgrade — or what the new shop needs to do. We tell you whether Magento Open Source fits, whether Adobe Commerce or Mage-OS plays a role and when Shopware 6 would be the better choice. Without obligation and before any quote.
For an existing shop we look into code, extensions, patch level, server environment, cron and queues and write a report with risks, sequence and effort in person-days. For a new build we use a workshop to clarify range, stores, languages, currencies, pricing logic and connected systems.
Whatever the report flags as urgent comes first: missing security patches, tested backups, tidied admin accounts, monitoring for services, indexers and queues. The code goes into a Git repository that belongs to you, and all access is documented.
We set up the environment with Docker on our servers in Germany, first as a staging system with a copy of the live data. There we test checkout, interfaces and background jobs; the move happens in an agreed maintenance window, with a backup beforehand and a way back.
We apply patches on a monthly rhythm. Upgrades to a new line such as 2.4.9 are planned as a project of their own: first the stack, then extensions and custom code, then Magento — each tested in full on staging before it goes live.
From then on we run and maintain the shop under an SLA, watch services, indexers and queues and keep an eye on the lifecycle. New features and interfaces are built as custom modules; our Magento development page describes how that works.
Projects on this system
A selection — not the full client list.
Magento Open Source is the licence-free edition under the Open Software License 3.0; Adobe Commerce is the licensed edition with additional features. According to Adobe, only Adobe Commerce offers, among other things, Content Staging, customer segments, Reward Points, returns via RMA, Live Search, Product Recommendations and the B2B module, which needs a separate licence; Adobe's cloud infrastructure and SaaS offering belong to it as well. Open Source, for its part, includes Page Builder, Inventory Management, REST and GraphQL APIs and two-factor authentication. Much of what Adobe Commerce brings can be built in Open Source as a custom module. Where an Adobe Commerce licence is already in place, we work with that too.
Magento Open Source itself costs nothing in licence fees; the cost lies in building, running and maintaining it. Besides PHP and a database, a shop needs OpenSearch, Valkey, Varnish and a message queue, plus monthly security patches and, every few years, an upgrade to a new line. These items arise regardless of how many orders come in. Extensions from the Marketplace and custom modules come on top. We estimate in person-days, with separate items for audit, implementation, upgrades and operation. We give concrete figures after an audit or workshop, and the hourly rate on request.
Mage-OS is an independent, community-driven distribution of Magento Open Source, not a separate platform. It is maintained by the Mage-OS Association, a non-profit organisation registered in Poland. Mage-OS stays compatible with Magento Open Source and provides a way back to the original; the 3.x line is based on 2.4.9, and version 3.6.0 of 14 October 2026 contains the security fixes from Adobe's October bulletin. Whether Mage-OS brings your shop any advantage depends on your extensions and the update rhythm you want. Operation, patching and development work the same way for both with us.
Under Adobe's lifecycle, regular support ends on 31 May 2027 for 2.4.7, on 31 May 2028 for 2.4.8 and on 31 May 2029 for 2.4.9; for 2.4.6 it ended on 11 August 2026, and for 2.4.4 and 2.4.5 back in 2025. Adobe describes extended support explicitly for Adobe Commerce customers, so for Magento Open Source we plan with the regular date. On top of that come the lifecycles of PHP, database and search service, for which Adobe supplies no fixes once they have ended. We schedule upgrades so that they are finished before the end of support, not after it.
Monthly: on Patch Tuesday, the second Tuesday of the month, Adobe publishes Isolated Security Patches, explicitly for Magento Open Source too. They are not cumulative, are applied in order and require the latest -p level of the line. At least once a year there is also a cumulative -p release via Composer that rolls the fixes in. Then there are emergencies: in September 2026, APSB26-146 closed a vulnerability that, according to Adobe, was already being exploited, with a hotfix of its own that is not included in the October patch. We test every patch on staging and record the level for each shop.
Above all, the stack: according to the system requirements, 2.4.9 runs on PHP 8.5, MariaDB 12.3 or MySQL 8.4, OpenSearch 3 and Valkey 9; Elasticsearch and Redis are no longer listed. In the framework, Adobe replaces Zend_Cache with symfony/cache and the Laminas MVC layer with its own implementation, Symfony moves to 7.4 LTS, and HugeRTE takes over from TinyMCE as the admin editor. For the message queue, Adobe recommends ActiveMQ Artemis for the long term. Extensions built on the replaced libraries have to be adapted. That is why every upgrade starts with a test of all extensions and custom modules on the staging system.
Plan an upgrade, in the right order: regular support for 2.4.6 ended on 11 August 2026. Shops on 2.4.4 or 2.4.5 use OpenSearch 2.19 according to Adobe and first need a version that knows both lines — 2.4.6 or 2.4.7 — before moving to OpenSearch 3. Whether the route to 2.4.9 takes one step or several depends on extensions, custom code and server. Until then we secure the current level with the patches available. Our OpenSearch shop search page describes how the search service is switched.
Yes, that is routine for us. It starts with an audit: version and patch level, extensions, custom modules, any changes to the core, cron jobs, queues, interfaces and server environment. The result is a written report on what needs securing at once and what can be planned, with effort in person-days. Access, Composer keys and licences are settled beforehand, not during an incident. If you wish, we move the shop to our servers in Germany, first as a staging copy, then in an agreed maintenance window. Afterwards the code sits in a Git repository that belongs to you, and the domain stays registered in your name.
On our own servers: Proxmox PVE clusters in the Hetzner data centre in Falkenstein, Germany, containerised with Docker. A Magento shop involves PHP behind nginx, MariaDB or MySQL, OpenSearch, Valkey for cache and sessions, Varnish as the HTTP cache and a message queue with RabbitMQ or ActiveMQ Artemis, plus cron jobs and queue consumers. Each client environment runs separately, with a staging system, backups and monitoring that also watches indexers and queues. Search service and cache are reachable only by their own shop. Staging and live run the same versions, so a test checks what will actually run later.
The SLA guarantees you a response time: BASIC 24, STANDARD 8 or ADVANCED 4 hours. It is a standby commitment booked for a year; the work itself is billed by effort or within an individually agreed framework that already includes hours. The hourly rate is tiered by working hours, weekdays outside working hours, and weekends and public holidays; we quote the rates on request. Without an SLA we handle requests within 48 hours during our business hours, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). On-call cover outside these hours is available only with an SLA.
Magento suits a shop that has to carry a lot: large catalogues with many variants, several stores, languages and currencies, a great deal of custom logic, or B2B with customer-specific prices and approvals. For a mid-sized shop with a manageable range, Shopware 6 is usually the more economical choice because it is leaner to run. We build both: new Magento shops start on 2.4.9, Shopware shops on the current Shopware 6 release, and Sharpness is a Shopware Extension Partner. Migrating an existing Magento shop to Shopware 6 is part of our project work too. Which route pays off is something we clarify in the first conversation, before any quote.
Replace it, and do so to a plan: Magento 1 has received no security updates since June 2020. There is no update path from Magento 1 to Magento 2; the route is a new build with data migration, in which products, customers and orders come across while theme, extensions and interfaces are built afresh. Whether the target is Magento Open Source 2.4.9 or Shopware 6 depends on your range, custom logic and operating effort. Until the cutover we keep the old shop as well secured as is possible without vendor patches. Every month without a plan extends the time in which known vulnerabilities stay open.
Enquiry
A few lines are enough: Magento version, hosting, what is pressing or what the new shop needs to do. We will get back to you with questions and an initial assessment — without obligation and before any quote is discussed.