About mypresta.rocks Info

Our Infrastructure: 100% Open Source Development Stack

How mypresta.rocks builds and ships PrestaShop modules: EU-owned infrastructure, realistic dev environments, and human-reviewed releases.

The stack we actually run on, and why we picked each piece

This is the infrastructure that builds, tests, and ships every module in our catalogue. We are writing it down because the question we get most often from agencies is some version of "are you a real team running real infrastructure, or are you three freelancers in a Discord?" Fair question. Here is the high-level answer.

Everything in our pipeline is open source or legally free. Not a brand position. A procurement decision we made years ago and have not had reason to revisit. No pirated software, no cracked seats, no proprietary vendor we cannot replace inside a weekend. The practical payoff is that nothing in our pipeline depends on a licence we could lose or a SaaS that could lock us out.

The server

We run on EU-based hardware we own. It uses checksummed storage with error-correcting memory and regular integrity checks. The host is ours; everything else is a container on top of it.

We picked that storage approach for one specific reason: every block is checksummed, and every dataset can be snapshotted in milliseconds. The snapshots are cheap enough that we take them before every PrestaShop upgrade test. When a 9.0 migration trashes a database (it has), we roll the dataset back and the container boots into the pre-broken state in seconds. The snapshot habit means a bad migration costs us minutes, not a day.

Why not a big public cloud

A comparable setup on a major public cloud, the RAM, the storage, the bandwidth our dev and staging containers consume, the egress to push ZIPs and demo data around. Would cost meaningfully more to run each month. Owning the hardware keeps it fixed-cost infrastructure with predictable bills, not a variable that surprises us when a client demo spins up dozens of parallel browsers.

The other reason is data jurisdiction. Our infrastructure is physically in the EU and under our control. No US Cloud Act exposure, no quiet log-export configuration we forgot to disable, no per-request surcharge on the support emails we send. For a small EU shop dealing with EU merchants, that is the simpler model, and it means the support conversation about your shop, including any logs you send us, stays on hardware we own.

Dedicated containers, versioned images, every version we still support

At any given moment we have a busy set of container-based environments running. Each is a complete PrestaShop install with its own database, its own admin user, its own modules directory. We keep parallel environments for:

  • PrestaShop 1.6.x: old, yes, but there are still shops running it and they still buy our modules.
  • PrestaShop 1.7.6 through 1.7.8: the long tail of "we'll upgrade next year".
  • PrestaShop 8.1 and 8.2: current production for the majority of new shops.
  • PrestaShop 9.0 and 9.1: the Symfony-heavy future, where we are doing most of our porting work this year.
  • Multistore variants for each of the above. Multistore breaks modules in its own special ways and we will not ship without testing it.

Each PrestaShop instance gets the MySQL/MariaDB version that release expects, rather than a single one-size-fits-all database. A shared cache layer handles session and object caching across the lot, mirroring how a production hoster actually sets things up.

This is the setup that catches the bugs you would otherwise discover in production. When a customer reports a fatal on an older PrestaShop and database combination with Smarty caching forced on, we have that exact combination running before lunch, rather than only a single "latest" install that quietly hides version-specific breakage.

Self-hosted, not SaaS

Everything we can reasonably host, we host. On EU-based hardware we own that means, among other things:

  • A self-hosted Git server: every module repository lives on hardware we own, so the canonical source of every release you receive sits with the people who write it.
  • A self-hosted mail stack with DKIM, SPF and DMARC. Your support replies do not pass through a third-party SMTP relay that scans them.
  • An internal documentation system for our knowledge base and runbooks, where a one-off fix becomes a repeatable procedure so the next person hits the same answer instead of re-discovering it.
  • An encrypted secrets vault for the credentials our internal tooling needs.
  • Service health monitoring, so we hear about a container being down before the client does.
  • A reverse proxy with automatic SSL on every internal hostname.
  • Internal DNS, so new dev environments come up on our private network with a single entry.

Self-hosting is more work than swiping a credit card at a SaaS, and we are aware of that trade. We do it because the alternative is having half a dozen vendor outages we cannot fix, scattered across a stack we do not control. When something misbehaves at 11pm we restart it ourselves; we do not file a support ticket and wait.

How releases are built and reviewed

A module's life does not end at purchase, so neither does the infrastructure behind it. The release that lands in your back office is built from the same self-hosted Git source we develop against. Deployment is deliberately a human-reviewed action: our automated jobs and AI coding assistants do not push releases on their own. A person reviews the change before it becomes a release. That review step is the gate that keeps an experimental change or a hallucinated method call out of the version you install. Access to our internal systems sits behind private, authenticated network access rather than an open port.

The development workstation

Our primary dev machine runs a modern, regularly updated Linux environment. We get the latest PHP, the latest Node, the latest everything without waiting for a distribution to bless it. That matters when PrestaShop 9 lands on PHP 8.2+ and we need to be testing on it the week the release notes drop.

Why Linux on the dev side

Because production is Linux. Case-sensitive filesystems, POSIX permissions, real symlinks, the lot. We have inherited too many modules from Windows-or-macOS developers that worked perfectly on the author's machine and broke instantly on a real shared-host Linux server because Module.php and module.php are two different files on one and the same file on the other. Developing on the same OS family as deployment cuts an entire category of bugs out of the workflow before they can ship.

We work in an open-source editor without vendor telemetry. Day-to-day runtime is container-based environments on the server, rootless containers locally, and full local VMs when we need them, usually to replicate a customer's cPanel or Plesk environment well enough to reproduce a hosting-specific bug.

AI coding assistants

The newer addition: AI coding assistants as part of the day-to-day workflow, useful where a second perspective speeds up the work. They run against the same repos and the same container-based environments as the humans. None of them has credentials to deploy to production, that stays a human action. They handle the long tail of "port this controller to PS 9", "audit for missing CSRF tokens", "translate the module wording to NL". Used carefully, force multiplier. Used uncarefully, they ship hallucinated method calls into a codebase, which is why we keep a human review step before anything reaches a release ZIP.

Design and creative

Module work is not all PHP. Every release ships with icons, banners, store screenshots, occasionally a custom icon font. All produced on open source tools, with zero Adobe spend per year.

Why this matters if you are buying a module from us

We test on what you run

Your shop runs Linux, a web server, a MySQL/MariaDB database, PHP, and a cache layer. Our dev environment runs the same stack, not a Windows-with-WAMP approximation that behaves differently in subtle and painful ways. When we mark a module "tested on a given PrestaShop and database version with cache enabled", that is because we literally have that container running, not because we read the PrestaShop requirements page.

We can reproduce issues on the version you run

Because every supported PrestaShop version stays running here, we are not debugging against a single "latest" install that quietly hides version-specific breakage. The snapshot habit means we can reproduce a regression on the exact version that hit it rather than guessing.

Lower overhead, no licensing surcharge

Zero spend on recurring proprietary software bills a typical dev shop carries. That is recurring cost we do not need to recover in module prices.

Same model as PrestaShop itself

PrestaShop is open source. You picked it for that reason. We picked our infrastructure for the same reason. When you buy a module from us, you are buying it from a team that lives inside the open-source model end-to-end, not one that sells modules for an open platform while running its own business on proprietary tooling it could not survive without.

How we got here

This setup did not appear on a whiteboard. Every piece of it replaced a previous piece that failed in a memorable way.

The separate containers exist because we got tired of "works on my machine" reports we could not reproduce. The storage snapshots exist because we once lost most of a day to a botched 1.7-to-8 migration and decided once was enough. The self-hosted mail stack exists because a big webmail provider started flagging our support replies as spam often enough that customers thought we were ignoring them. The internal DNS resolver replaced a hand-edited /etc/hosts file that broke every time someone added a new dev subdomain. The internal wiki replaced a pile of Markdown files in a repo that nobody read.

None of it is theoretical. Every change solved a problem that had cost us real time. That is the only reason it stuck, and it is the same reason it holds up under the modules you are running.

Related reading

Back to top