Skip to main content





Highly available infrastructures and architectures with an extensive range of tailor-made services and solutions, whether Shopware, Spryker, e-commerce or TYPO3: simply PREMIUM.


And there is more.




Continuous Delivery. The major goal of continuous delivery processes must be to shift the "aches" further to the left, i.e. to the beginning of the pipeline, in the direction of the developers.

The earlier there is a unique version in a defined state, the less complicated even complex deployments become. Especially in an agile environment like Spryker, a build server can generate the desired left-swing.

In the basic constellation, a Spryker release goes through various processes: From Git to Composer and npm to webpack or other frontend compilers to code generators at the end of the toolchain. This whole process is time-consuming and has a number of dependencies on external resources. In addition, the results of many tools are version dependent. A build that was successful on one tier/stage can fail on another system, or - even nastier - have deviations that are not immediately noticeable.

Similar questions arise over and over again: Do all developers and stages have the same version of the tools? Do they all work on an identical setup of their development environment? What does it look like on the server? Are the external resources available? These questions become obsolete if you include a build server in the continuous delivery process.


A build server enables small-scale, atomic deployments, since the release is available in one piece and is not created during the release process. It is also possible to switch directly to the latest release. Since no further build tools are used on production environments, no new dependencies arise during deployment on external registries and the results of the tools themselves. The unique version of the build artifact then forms the basis for further testing and customer communication. Identical setups of the other tiers or stages, such as a preview environment followed by the production system, thus ensure that problems already fall on the developer's feet in the dev environment and are fixed at an early stage so that no new problems can be created by the build process.


What the build server ultimately presents as an artifact is very flexible. From tarball to Debian or rpm packages, containers to complete VMs, everything is possible.

But beware: You have to make sure that configurations with environment variables such as different URLs or databases of different stages are handled dynamically in the build and can be parameterized from outside. For this reason, you should also clarify responsibilities at an early stage with regard to the following aspects:

  • When is the hoster in charge? (entrances, paths, etc.)
  • What is the developer's responsibility (e.g. interfaces to ERP or Google Analytics etc.)?

You should also separate the configs - the hoster config comes over ENV, everything else is part of the project in git! This is the only way to ensure that there can be an identical build for all environments.


The build server's toolchain can take many forms. You can choose your favorites for the builds: Shellscripts, psh (php shell helpers), rocketeer, deployer, capistrano grant, gulp ... The tools should be part of the project, so that they are versioned in the repository or kept on a consistent level via versioned dependencies.

A build service, including ticketing, can easily be set up as an agency service, even if corporate customers in particular would like to have their hands on it in order not to become too dependent or to operate a multi-agency setup. The flexible build pipe is also very helpful in this case, in particular to be able to play on different platforms such as Jenkins, Bamboo or Gitlab.

Bottom line

A build server is not a witchcraft, it facilitates daily work in agile teams and takes continuous delivery processes to a new level. For agencies, this opens up real added value, which, especially in conjunction with a multi-level hosting concept, leads to relaxing deployments that even on Friday afternoons no longer cause headache. A picture-perfect process!



The Shopware Community Day gave the visitors a first insight into Shopware 6. The colleagues on site were very impressed with the versatility of the new e-commerce system, but also saw the first hooks.

The positive first: The API-first approach is very exciting because it enables a high degree of flexibility and promises sustainability. Regular web shops, mobile shopping worlds, IoT, support for voice assistants - all combined in one backend that handles the various channels. In addition, there are numerous administration improvements that also take headless e-commerce into account.

Shopware 6 relies on a new technological foundation, e.g. with Symfony as standard framework, Bootstrap 4 and vue.js. In our experience, these are very interesting, versatile technologies, which also provide more performance in terms of hosting the company.

However, this new substructure also contains a catch of the new Shopware 6: The migration from Shopware 5 to the new system is a challenge. All plugins for Shopware 6 have to be checked, adapted and rewritten in case of doubt, which can bring some imponderables with complex Shopware 5 installations.

One point, which unfortunately, from our point of view, has not received an entry into Shopware 6, are geobased databases. The possibility of maintaining identical databases at different geolocations worldwide in order to be able to answer inquiries on the other side of the globe as quickly as possible would be a real killer feature for us.

But Shopware 6 is still a great new e-commerce system at first glance, and we're looking forward to it. From the middle to the end of the year, the development should be so far that nothing stands in the way of productive use. There are two good news for everyone who wants to take a look at the 6 version first. Firstly, Shopware 5 will be supported for another five years, so that there will be no pressure to switch. On the other hand, the developer version can already be downloaded and tested. All necessary information can be found on the Shopware page.



The Hamburger Tafel collects surplus food and distributes it to 27 food distribution points in and around Hamburg. Metaways supports the mostly honorary work with free hosting.

"Hamburg is the most beautiful city in the world," say many locals out of conviction. Of course there are also downsides, but through great honorary commitment, there are attempts at every nook and corner of society to alleviate need.

One example is the Hamburger Tafel, which describes itself as a "social logistician". 400 helpers collect surplus food from numerous retailers and companies and take it to distribution points for the needy.

In the beginning, a card box was sufficient to manage the helpers and donors, but in the meantime the Hamburg Tafel has grown so much that software support was urgently needed. The administration system was provided by our partner SoftwareLoft, who then asked Metaways if we could take over the hosting.

Of course we didn't hesitate and now the administration and the website run on our highly available servers - pro bono. Now we hope that we can also contribute a tiny bit to more people saying: "Hamburg is the most beautiful city in the world!"