Our Infrastructure: 100% Open Source Development Stack

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 answer with model numbers.

Everything in our stack 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 server

One physical machine in our office, running TrueNAS Scale on Debian 12 Bookworm. 64GB ECC RAM, 3.5TB of SSD on ZFS. That is the host. Everything else is a container on top of it.

We picked TrueNAS for one specific reason: ZFS. Every block is checksummed, every dataset can be snapshotted in milliseconds, and 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 under ten seconds. We have lost exactly zero days of work to bad migrations since the snapshot habit became muscle memory.

Why not AWS or GCP

We ran the numbers. The equivalent of our server on AWS (64GB RAM, 3.5TB SSD, the bandwidth our dev and staging containers consume, the egress to push ZIPs and demo data around) comes out to four-figure euros per month. The TrueNAS box paid for itself inside the first year. After that it is fixed-cost infrastructure with predictable electricity bills, not a variable that surprises us when a client demo spins up forty parallel browsers.

The other reason is data jurisdiction. Our infrastructure is physically in the EU and the keys are physically in our office. 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.

Dedicated containers, versioned images, every version we still support

At any given moment we have a busy set of Docker containers 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 its own MySQL 5.7, MySQL 8.0, or MariaDB 10.11 container depending on what that PS version expects. A shared Redis instance 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 1.7.6 with MySQL 5.7 and Smarty caching forced on, we have that exact combination running before lunch.

Self-hosted, not SaaS

Everything we can reasonably host, we host.

Gitea — Git server. Every module repository lives on hardware we own.
Mailcow — full mail stack with DKIM, SPF, DMARC. Your support replies do not pass through a third-party SMTP relay that scans them.
Outline wiki — internal knowledge base and runbooks. We picked Outline over Confluence and Notion because it is open source, runs on Postgres we already had, and exports cleanly to Markdown if we ever want out.
Vaultwarden — Bitwarden-compatible password and secrets vault.
Uptime Kuma — service health monitoring. We hear about a container being down before the client does.
Nginx Proxy Manager with Let's Encrypt for automatic SSL on every internal hostname.
AdGuard Home — internal DNS resolver. Every *.mypresta.rocks dev subdomain resolves through it; new shops just need a DNS rewrite entry and they are live on the LAN.

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 Gitea misbehaves at 11pm we restart it ourselves; we do not file a support ticket and wait.

The development workstation

Primary dev machine is Arch Linux with KDE Plasma. Rolling release — 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.

Editor is VS Code (Code - OSS), the fully open build without Microsoft's telemetry. Container runtime is Docker on the server, Podman locally for rootless test containers, and QEMU/KVM when we need a full VM — usually to replicate a customer's cPanel or Plesk environment well enough to reproduce a hosting-specific bug.

Claude Code and Codex

The newer addition: Claude Code (Anthropic) as our day-to-day AI coding harness, OpenAI Codex for one-off investigations where a second model's perspective is useful. Both run against the same repos and the same Docker containers as the humans. Neither 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 your 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.

GIMP 3.0 for raster work. The 3.0 release finally got non-destructive editing right.
Inkscape for SVG icons and logos, straight into module assets, no Illustrator round-trip.
Photopea for the inevitable client PSD that arrives with twelve nested smart objects. Free, web-based, opens PSDs more reliably than any open-source desktop alternative we have tested.
FontForge for custom icon fonts. Each larger module ships a font with only the 15–40 glyphs it needs, instead of pulling all of Font Awesome.
ImageMagick on the command line whenever there are more than ten images to push through the same transform.
Blender for the product-cover 3D renders.

Total Adobe spend per year: zero.

Why this matters if you are buying a module from us

We test on what you run

Your shop runs Linux, Nginx or Apache, MySQL or MariaDB, PHP, Redis. 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 PS 1.7.6 with MySQL 5.7 and Redis cache", that is because we literally have that container running, not because we read the PrestaShop requirements page.

Lower overhead, no licensing surcharge

Zero spend on Adobe Creative Cloud, JetBrains seats, Windows licenses, Microsoft 365, VMware, or any of the other recurring software bills a typical dev shop carries. That is several thousand euros per year 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.

Full inventory

For anyone who wants the spec sheet. Every item below is open source or legally free to use.

Operating systems

TrueNAS Scale (Debian 12 Bookworm) — server OS, ZFS root
Arch Linux — dev workstation, CachyOS kernel
KDE Plasma — desktop environment

Server infrastructure

Docker — versioned PrestaShop dev containers and supporting services
Nginx Proxy Manager — reverse proxy + Let's Encrypt
AdGuard Home — internal DNS
Mailcow — SMTP, IMAP, webmail, DKIM/SPF/DMARC
Gitea — self-hosted Git
Redis — shared cache
MySQL 5.7, MySQL 8.0, MariaDB 10.11 — depending on PS version
Outline — internal wiki on Postgres
Vaultwarden — secrets management
Uptime Kuma — monitoring

Development

VS Code (Code - OSS) — editor
Claude Code, OpenAI Codex — AI coding harnesses
Git — version control
Composer — PHP dependencies
Node.js, npm, Yarn — JS toolchain
PHP 8.4, Xdebug 3.4, OPcache — runtime and debugging
Podman — rootless local containers
QEMU/KVM — full VMs

Design

GIMP 3.0, Inkscape, Photopea, FontForge, ImageMagick, Blender

Office and comms

LibreOffice, Thunderbird, Discord

Browsers

Chromium (primary testing), Brave (secondary)

Security and networking

WireGuard, OpenVPN, SSH, Let's Encrypt

Monitoring

Uptime Kuma, btop, nvtop, smartmontools, ZFS integrity scrubs

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 ZFS snapshots exist because we once lost most of a day to a botched 1.7-to-8 migration and decided once was enough. The Mailcow stack exists because Gmail started flagging our support replies as spam often enough that customers thought we were ignoring them. AdGuard Home replaced a hand-edited /etc/hosts file that broke every time someone added a new dev subdomain. Outline replaced a wiki of Markdown files in a Git 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.