One of the arguments I hear most often in conversations about migrating from Akeneo CE is infrastructure. "We already have a server configured for Akeneo, so what - do we start from scratch?"
The answer is usually: yes, but that is good news. Because a server configured for Akeneo CE is almost certainly oversized for UnoPIM.
Let us start with a hard comparison
Before I get into what you need - a side-by-side of the requirements for both systems, to have a reference point:
Component | Akeneo CE | UnoPIM |
|---|---|---|
Framework | Symfony | Laravel |
Search engine | Elasticsearch / OpenSearch (required) | MySQL (built-in, no add-ons) |
Cache / Queue | Redis or RabbitMQ | Redis |
Database | MySQL 8.0+ | MySQL 8.0+ |
PHP | 8.1+ | 8.2+ |
RAM minimum (production) | 8-16 GB (ES eats RAM from startup) | 4-8 GB |
Configuration complexity | High (separate ES node) | Standard |
Approximate VPS cost | 75-150 EUR/month | 20-50 EUR/month |
Elasticsearch starts up and immediately reserves memory - even an empty ES node consumes 2-4 GB of RAM before handling its first query. That is why cheap VPS servers simply cannot handle Akeneo CE. UnoPIM does not have this problem.
What you specifically need on the server
The UnoPIM production stack is five components. Each does something specific and each is needed:
PHP 8.2+ with extensions: BCMath, Ctype, cURL, DOM, Fileinfo, GD or Imagick, JSON, Mbstring, OpenSSL, PCRE, PDO, Tokenizer, XML, Zip. Imagick is more important than GD if you plan high image volumes - it handles format conversion and thumbnail generation better.
MySQL 8.0+ - the database, nothing surprising. Make sure innodb_buffer_pool_size is set to at least 25-30% of available RAM. The default value in many distributions is 128MB, which means every query goes to disk instead of cache once you have a catalog of a few thousand SKUs.
Redis - handles application cache and the job queue. Acts as the intermediary between the application and queue workers. Without Redis, importing 10,000 SKUs would try to execute within an HTTP request and time out after 30-60 seconds.
Supervisor - and this is where many "deployments" fall apart on the first large import. Supervisor is a process manager that ensures the queue worker runs continuously. Without it: you restart the server, the worker does not come back up, the import stalls, nobody knows why. With Supervisor: the worker starts automatically, crashes - Supervisor restarts it, logs in one place. Configuration takes 15 minutes and saves hours of debugging.
nginx as a reverse proxy in front of PHP-FPM. Apache works too, but nginx handles large file uploads better and has lower memory usage under many concurrent connections.
Minimum vs production hardware requirements
Two configurations I recommend depending on scale:
Demo / first deployment (up to 2,000 SKUs, a few users): 2 vCPU, 4 GB RAM, 40 GB SSD. This is a VPS for 20-25 EUR per month at most providers. Enough to see the system working and run first integration tests.
Production (5,000-50,000 SKUs, 10-30 concurrent users): 4 vCPU, 8 GB RAM, 80-100 GB SSD. Around 40-50 EUR per month. With this setup, importing a few thousand products with media takes minutes, not hours.
SSD is not optional - it is a requirement. MySQL on an HDD with a catalog of a few thousand SKUs is a recipe for frustration. The difference in response time between HDD and SSD for database I/O operations is often an order of magnitude.
The architectural decision you cannot postpone: media storage
Before you hand off the installation you need to make one decision, because changing it after the fact is painful: where do you store media.
Local VPS disk is fine for small catalogs. With e-commerce catalogs containing thousands of high-resolution images it becomes a problem faster than you expect. Three reasons:
First, the disk fills up. A few thousand products with 5-8 images per SKU in print quality is easily 50-100 GB. Plus thumbnails generated by the system - each image is saved in several sizes. A VPS with 80 GB of disk fills up within months.
Second, backups grow to unmanageable sizes. A database backup is a few MB - fast, cheap, daily. A backup of 80 GB of media is a completely different conversation with your hosting provider.
Third, inodes. Linux filesystems have a limit on the number of files (inodes) that is independent of free disk space. With tens of thousands of thumbnail files you can hit the inode limit and be unable to save a new file even though the disk "has space".
UnoPIM supports S3-compatible storage natively - AWS S3, Backblaze B2, Hetzner Object Storage, Cloudflare R2. Storing 100 GB on Backblaze B2 costs a few dollars per month. For new deployments I always recommend S3 from day one.
Managed vs unmanaged VPS
The second decision to make before telling your devops person to "just set it up".
Unmanaged VPS - you get a clean operating system, the rest is up to you. 30-50% cheaper, full control, but security configuration, system updates and monitoring are your responsibility.
Managed VPS - the provider handles system updates, basic monitoring and often initial stack configuration. More expensive, less flexible, but sensible if you do not have a dedicated devops person.
For most SME deployments I recommend a managed VPS from a provider that knows PHP/Laravel (Forge-compatible, Ploi, RunCloud) and unmanaged S3 storage for media. This is a reasonable compromise between cost and operational safety.
The traps you only find in production
A few things that look fine in a test environment and cause problems after going live:
Queue worker that does not start after a reboot. Classic trap. Everything works in testing because the worker was started manually. The server reboots after a kernel update - the worker does not come back up - imports stall. Supervisor configured with autostart=true and autorestart=true fixes this permanently. Check this before you declare the deployment ready.
Missing OPcache. PHP without OPcache compiles every file on every request. With OPcache it compiles once and keeps it in memory. The difference in response time is 3-5x. OPcache is available in every PHP installation, you just need to uncomment it in php.ini. Surprisingly often overlooked.
Storage permissions. UnoPIM needs write access to the storage and bootstrap/cache directories. With wrong permission configuration the system runs but cannot write logs, cache or uploaded media. The error surfaces on the first image upload, not during installation.
Importing media via HTTP for large catalogs. When migrating from another system you can import images by providing a URL - UnoPIM fetches them itself. With thousands of images this means hundreds of HTTP requests to an external server. Slower than local import, dependent on source availability, can lead to timeouts during bulk operations. If you can copy the media locally before import - do it.
When a VPS stops being enough
A standard setup handles catalogs up to tens of thousands of SKUs and dozens of users. Signals that you need to think about scaling:
Importing a few hundred products takes more than 10-15 minutes despite the queue worker running
Panel response time grows above 2-3 seconds under normal use
MySQL regularly consumes more than 80% of available RAM
Bulk operations on the catalog (bulk edit, channel export) block the interface for other users
In those cases the next step is a separate database server, Redis Cluster and a load balancer in front of the application. But that is a problem that appears at scale, not at the start.
What you actually hand off to your devops person
If you already have a VPS and the architectural decisions made (S3 yes/no, managed yes/no), the task list is predictable: stack installation (PHP, MySQL, Redis, nginx), Supervisor configuration for queue workers, UnoPIM installation via Composer, .env configuration, database migrations, SSL configuration, storage setup (local or S3), basic hardening (firewall, fail2ban, unnecessary ports closed).
For a competent devops person who knows Laravel this is one day of work. Most of the time goes into configuration and testing, not the installation itself.
If you are planning a deployment and want me to handle this as part of the project - server configuration is included in the standard scope. You can also check the TCO calculator to see how infrastructure cost compares to licensing alternatives. Write if you have questions →
