PrestaShop Hosting: Anforderungen & Server-Setup

Das Hosting ist das Fundament, auf dem Ihr Shop steht

Wir haben PrestaShop auf so ziemlich jeder existierenden Hosting-Stufe betrieben: günstigen Shared-cPanel-Boxen, die wir von Kunden geerbt haben, VPS bei Hetzner und OVH, dedizierten Maschinen in Rechenzentren und dem TrueNAS im Büro, das mypresta.rocks selbst hostet. Nach über zehn Jahren ist unsere Haltung schlicht: Kein noch so gutes Caching, keine Bildoptimierung und kein Modul-Tuning rettet einen Shop, der auf unterdimensioniertem oder falsch konfiguriertem Hosting feststeckt. Bringen Sie zuerst das Fundament in Ordnung, dann wird alles darüber leichter.

Diese Seite ist bewusst meinungsstark. Sie ist das, wohin wir einen Kunden schicken würden, der fragt „Worauf sollte ich hosten?", bevor er irgendetwas unterschreibt.

Hosting-Arten, in der Reihenfolge, in der sie tatsächlich angemessen sind

Günstiges Shared-Hosting (etwa 3–15 $/Monat)

Ihr Shop teilt sich einen Server mit Hunderten anderen. Sie erhalten cPanel oder DirectAdmin, eine festgelegte PHP-Konfiguration und keinen Root-Zugriff. Die guten Anbieter (wir haben sie erlebt) lassen Sie ein aktuelles PHP wählen, OPcache aktivieren und überbuchen die Speicherkapazität nicht. Die schlechten tun durchweg das Gegenteil.

Was Sie bekommen: niedrige Monatsrechnung, E-Mail inklusive, jemand anderes patcht das Betriebssystem.
Die Nachteile: andere Nutzer, deren Ressourcenverbrauch die Antwortzeiten unvermittelt verlängert, kein SSH in den Einstiegstarifen, kein Redis, kein Varnish, PHP-Versionen, die Sie nicht selbst wählen, und eine geteilte IP, die durch das Verhalten eines anderen Mieters auf einer Blacklist landen kann.

In Ordnung für einen brandneuen Shop mit unter 500 Produkten, wenig Traffic und ohne Zeitdruck beim Optimieren. Nicht in Ordnung für alles, was Sie wachsen lassen wollen.

VPS (managed oder unmanaged, 5–60 $/Monat)

Dedizierter RAM, dedizierte CPU, dedizierte Festplatte, Root-Zugriff. Hier leben die meisten unserer Kunden-Shops, und hier würden wir auch Ihren ansiedeln.

Managed VPS: Der Anbieter patcht das Betriebssystem und kümmert sich um Sicherheitsupdates. Sie kümmern sich um PrestaShop. Ein Control-Panel oder ein Managed-Service schlägt meist mit 5–20 $/Monat zusätzlich zum reinen VPS-Preis zu Buche.
Unmanaged VPS: Eine leere Debian- oder Ubuntu-Box mit SSH. Günstiger, aber Sie verantworten jede Zeile der nginx-Konfiguration und jedes Kernel-Update.

Für 90 % der Shops, mit denen wir zu tun haben, übertrifft ein Managed VPS im Bereich von 15–30 $/Monat das Shared-Hosting in jeder Dimension, die zählt.

Dedizierter Server (80–300+ $/Monat)

Eine ganze physische Maschine, kein Hypervisor-Overhead. Überdimensioniert für einen Shop mit 2.000 Produkten. Die richtige Wahl, wenn Sie die Marke von 50.000 Produkten mit ernsthaftem Traffic überschreiten, an dem Punkt holen wir Kunden vom Cloud-VPS herunter und auf etwas wie einen dedizierten Hetzner-Server, weil das Preis-Leistungs-Verhältnis lächerlich zu Ihren Gunsten ausfällt.

Cloud-VPS

Stündliche Abrechnung, schnelle Bereitstellung, Snapshots, eine API. 2 GB / 2 vCPU bewegen sich bei den brauchbaren Anbietern im Bereich von 5–15 $/Monat, und EU-basierte Anbieter unterbieten die US-amerikanischen bei vergleichbaren Specs zuverlässig.

„Managed PrestaShop"-Hosting

Vorkonfigurierte Boxen mit PS-spezifischem Support. Das Angebot klingt verlockend, wenn Sie noch nie einen Server angefasst haben. Die Realität ist: Es handelt sich meist um weiterverkaufte Infrastruktur mit einem Aufschlag, und der Support kennt das Shop-Control-Panel, nicht Ihre spezifischen Module.

Managed-PS-Hosting verdient sein Geld, wenn Sie wirklich keinerlei Lust haben, einen Server zu lernen. Für alle anderen leistet ein Managed VPS mit einem vernünftigen LEMP-Stack mehr und kostet weniger.

Mindestanforderungen, nach PrestaShop-Version

PrestaShop 1.7

PHP: 7.1–7.4 • MySQL: 5.5+ (5.7 empfohlen) • RAM: 2 GB Untergrenze, 4 GB sinnvoll
Erweiterungen: curl, gd, intl, mbstring, zip, xml, json, openssl

PrestaShop 8.x

PHP: 7.2–8.1 (8.1 ist die Version, auf der wir deployen) • MySQL: 5.6+ • RAM: 4 GB Untergrenze
Erweiterungen: die 1.7-Liste plus fileinfo und iconv

PrestaShop 9.x

PHP: 8.1–8.4 (in Produktion betreiben wir 8.2) • MySQL: 8.0+ oder MariaDB 10.5+ • RAM: 4 GB Untergrenze, 8 GB, wenn Sie echten Traffic haben
Erweiterungen: die 8.x-Liste, wobei obendrein die Anforderungen von Symfony 6.4 gelten

Behandeln Sie diese Werte als „der Shop wird sich installieren"-Zahlen, nicht als „der Shop wird performen"-Zahlen. Die Starter-Zeile mit 2 GB unten gilt für kleine PrestaShop-1.7-Shops; verwenden Sie für PrestaShop 8 oder 9 mindestens 4 GB. Ein Katalog mit 5.000 Produkten, 50 Modulen und Live-Traffic will 4–8 GB RAM, unabhängig davon, welche Version auf dem Fundament läuft.

Informationsseite im PrestaShop-Administrationsbereich mit PHP-, MySQL- und Serverkonfiguration

Dimensionierungsleitfaden

Shop-Größe	Produkte	Tägliche Besucher	RAM	CPU	Festplatte
Starter	<500	<200	2 GB	1 Kern	20 GB SSD
Klein	500–2K	200–1K	4 GB	2 Kerne	40 GB SSD
Mittel	2K–10K	1K–5K	8 GB	4 Kerne	80 GB SSD
Groß	10K+	5K+	16 GB+	4–8 Kerne	160 GB+ SSD

Eine Erinnerung zum Thema Festplatte: 5.000 Produkte mit je 5 Bildern, regeneriert über 7 PrestaShop-Bildtypen, fressen 10–20 GB, bevor Sie überhaupt etwas anderes hinzugefügt haben. Planen Sie den Festplattenplatz entsprechend.

Was wirklich den Unterschied macht

Jeder Hoster wirbt mit Kernen, RAM und Bandbreite. Nach unserer Erfahrung sieht die Reihenfolge, in der die Dinge tatsächlich zählen, so aus.

1. PHP-Version und OPcache

PHP 8.1 ist bei gleichem Code rund 20–40 % schneller als 7.4, und OPcache stellt sich obendrein als der größere Gewinn heraus. Ohne OPcache kompiliert PrestaShop bei jeder Anfrage Hunderte von PHP-Dateien neu. Mit OPcache kommt der kompilierte Bytecode direkt aus dem Arbeitsspeicher.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Wenn ein Hoster Sie OPcache nicht aktivieren lässt oder 2026 noch PHP 7.x ausliefert, gehen Sie. Es gibt keinen Vorteil.

2. Disk-I/O, SSD oder NVMe, niemals rostende Magnetscheiben

PrestaShop liest pro Seite Hunderte von Dateien. HDD-Random-Read liegt bei etwa 5–15 ms, SSD bei 0,1 ms. Allein das macht einen Faktor von 3x bei der realen Seitenzeit aus. Wir deployen keinen Shop auf HDD. Das sollten Sie auch nicht.

3. MySQL-Konfiguration

Eine typische PS-Seite feuert 100–300 Abfragen ab. Die einzelne Einstellung, die am meisten zählt, ist innodb_buffer_pool_size. Sie steuert, wie viel Ihrer Daten im RAM liegt. 50–70 % des gesamten RAMs auf einem dedizierten Datenbankserver, 25–40 % auf einer kombinierten App+DB-Box. Bevor Sie um eine aufgeblähte Datenbank herum tunen, nutzen Sie Database Cleanup oder gleichwertige SQL-Audits, um verlassene Warenkörbe, Logs und veraltete Statistiken auszudünnen.

4. RAM

Jeder PHP-FPM-Worker belegt 30–80 MB residenten Speicher. Zehn Worker bedeuten 300–800 MB allein für PHP, dazu kommen MySQL, Redis, OPcache selbst und das Betriebssystem. 2 GB sind knapp, bevor Sie auch nur eine einzige Anfrage ausgeliefert haben.

5. HTTP/2

Multiplext alles über eine einzige Verbindung. 20–40 % schneller bei Seiten, die 60–80 Assets laden, was die meisten PrestaShop-Seiten sind. Benötigt HTTPS, das Sie ohnehin brauchten.

Shared-Hosting: die Wände, gegen die Sie laufen

Shared kann für die kleinsten Shops funktionieren, aber Sie stoßen ungefähr in dieser Reihenfolge an folgende Grenzen:

Kein SSH. Sie können kein CLI-Composer, keine Console-Befehle und keines der Cleanup-Skripte ausführen, auf die wir uns normalerweise stützen würden.
Cron-Beschränkungen. Viele Shared-Hoster begrenzen Cron auf alle 15 Minuten. Der Hausputz von PrestaShop will mehr.
Gedeckeltes memory_limit. 128–256 MB sind bei günstigen Tarifen normal. Große Importe scheitern stillschweigend, sobald sie daran stoßen.
Kein Redis. Sie hängen am Dateisystem-Caching fest, auf bereits ausgelastetem geteiltem Speicher.
Geteilte IP. Die Spam-Gewohnheit eines Nachbarn setzt Ihre IP auf eine Blacklist, und Bestellbestätigungs-E-Mails kommen nicht mehr an. Die Lösung behandeln wir in unserem Leitfaden zur E-Mail-Zustellbarkeit.

Wenn Sie ohnehin Shared kaufen, priorisieren Sie SSH-Zugriff, ein Control-Panel, das Sie die PHP-Version wählen lässt, OPcache-Unterstützung und ein Memory-Limit, das Sie anheben können. Und lesen Sie immer den Verlängerungspreis. Die Einstiegszahl ist Marketing.

2,99 $/Monat verlängert sich ein Jahr später auf 10,99 $. Jede Bewertungsseite für günstiges Shared überfliegt das. Wir nicht.

VPS: die richtige Wahl für die meisten Shops

Warum wir immer wieder hier landen

Root-Zugriff. Installieren Sie Redis, Varnish, den ganzen Stack.
Dedizierte CPU und dedizierter RAM. Kein Nachbar, dem man um 14 Uhr am Black Friday die Schuld geben kann.
Volle Kontrolle über PHP-FPM und OPcache.
Uneingeschränktes SSH und Cron.
nginx, nicht Apache, sofern Sie sich nicht anders entscheiden.
Snapshots vor riskanten Upgrades, drei Klicks zum Zurückrollen.

Was Sie tatsächlich prüfen sollten, bevor Sie sich anmelden

SSD- oder NVMe-Speicher. Wenn das Datenblatt es nicht angibt, gehen Sie von HDD aus und überspringen Sie es.
Faire Preise. 2 GB / 2 vCPU für 5–15 $/Monat ist normal. 30 $ ist überteuert.
Rechenzentrumsstandort. EU-Shops wollen EU-Rechenzentren. Latenz ist real, die DSGVO ist noch realer.
Günstige Snapshots. Das eine Feature, das sich beim ersten Mal selbst bezahlt macht, wenn ein Modul-Upgrade schiefläuft.
Dokumentation. Sie werden Zeit in ihrer Dokumentation verbringen. Wenn sie dünn ist, sagt Ihnen das etwas.

Wenn Sie noch nie einen Linux-Server verwaltet haben, zahlen Sie den Aufpreis für einen Managed-Service oder ein Control-Panel. Ein falsch konfigurierter VPS wird das Shared-Hosting in Benchmarks übertreffen und im echten Leben unterbieten, weil niemand den Kernel gepatcht hat.

LEMP-Stack-Basis

# Debian 12 / Ubuntu 22.04
apt install nginx php8.2-fpm php8.2-mysql php8.2-curl \\
    php8.2-gd php8.2-intl php8.2-mbstring php8.2-xml \\
    php8.2-zip php8.2-opcache mariadb-server redis-server -y
mysql_secure_installation

Noch nie einen Linux-Server betrieben? Beginnen Sie mit einem Managed VPS oder einem Panel. Ein kaputter DIY-VPS ist schlimmer als Shared-Hosting. Unser Leitfaden zur Sicherheitshärtung behandelt, was abzusichern ist, sobald Sie online sind.

Dedicated und Cloud: wenn der VPS nicht mehr ausreicht

Steigen Sie auf, wenn Sie 50K+ Produkte, dauerhaft 5K+ tägliche Besucher, einen Multistore mit fünf oder mehr Shops auf derselben Box oder eine echte Anforderung an 99,99 % Verfügbarkeit haben.

Eine dedizierte 64-GB-/NVMe-Box von einem europäischen Anbieter kann bei 40–60 EUR/Monat landen. Mehr Kapazität, als die meisten Shops je nutzen werden, aber gegen das Preis-Leistungs-Gefälle im Vergleich zu einem Cloud-VPS mit denselben Specs ist schwer zu argumentieren.

Die Skalierungsreihenfolge, wenn Sie tatsächlich skalieren müssen: ziehen Sie zuerst MySQL auf einen eigenen Server (der größte Einzelsprung), dann setzen Sie Redis auf eine eigene Instanz, dann denken Sie über einen Load-Balancer mit mehreren App-Servern nach, und an diesem Punkt brauchen Sie außerdem geteilten Speicher und Redis-Sessions, also springen Sie nicht voraus.

Server-Konfiguration für PrestaShop

nginx, nicht Apache

Apache ist der Standard, weil Shared-Hosting ihn verwendet, nicht weil er die bessere Wahl wäre. nginx verwendet ereignisgesteuertes I/O (10–30 MB pro Prozess gegenüber 300–800 MB bei Apache prefork), liefert statische Dateien aus, ohne über PHP zu gehen, und bringt einen FastCGI-Cache ab Werk mit.

Wenn Sie auf Apache festgelegt sind, betreiben Sie mpm_event mit PHP-FPM, niemals mpm_prefork mit mod_php. Letzteres ist das langsamste PrestaShop-Deployment, das wir je in freier Wildbahn gesehen haben.

PHP-FPM-Einstellungen

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500
php_admin_value[memory_limit] = 512M
php_admin_value[max_execution_time] = 300

Die Formel, die wir für pm.max_children verwenden: (RAM in MB − MySQL-Footprint − OS) / 50 MB pro Worker. Auf einer 4-GB-Box: (4000 − 1500 − 500) / 50 = 40. Wir setzen 20–30, um Reserve zu lassen, denn ein ausgelasteter FPM-Pool bedeutet 502er im Gesicht des Kunden.

MySQL-Tuning

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
tmp_table_size = 64M
max_heap_table_size = 64M
slow_query_log = 1
long_query_time = 1

Schalten Sie das Slow-Query-Log am ersten Tag ein. Eine einzelne schlechte Abfrage, die 200-mal pro Seite läuft, schlägt jede „langsamer Server"-Diagnose, die wir je gestellt haben, und das Log ist, wie Sie sie finden. Unser Performance-Leitfaden führt durch, was zu tun ist, sobald Sie die Übeltäter gefunden haben.

Redis für Sessions und Cache

PrestaShop legt Sessions und Cache standardmäßig auf der Festplatte ab. Verlagern Sie beides auf Redis, und die Admin-Seiten blockieren nicht mehr am Dateisystem-Session-Locking, das die mit Abstand häufigste Ursache für „der Administrationsbereich ist so langsam"-Tickets ist, die wir eröffnen. Redis kostet Sie 50–100 MB RAM und zahlt es sich sofort zurück.

SSL/TLS, nicht optional

Jeder Shop braucht HTTPS. Google stuft HTTP herab, Browser stellen es an den Pranger, und kein Zahlungsanbieter arbeitet ohne. Die Diskussion ist vorbei.

Let's Encrypt

Kostenlos, automatisch, 90-tägige Verlängerung. Certbot installiert es einmal, und Sie vergessen es:

apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourshop.com -d www.yourshop.com

Cloudflare SSL

Kostenlos über deren Proxy, mit einer Falle: verwenden Sie immer Full (Strict). Der Flexible-Modus sendet Klartext zwischen Cloudflare und Ihrem Origin, was den ganzen Sinn zunichtemacht. Setzen Sie X-Forwarded-Proto, damit PrestaShop weiß, dass es hinter HTTPS steht; mit Full (Strict) verwendet auch die Verbindung von Cloudflare zu Ihrem Origin HTTPS.

HTTPS erzwingen

Aktivieren Sie es unter Shop-Einstellungen → Allgemein, dann fügen Sie die Server-Weiterleitung hinzu:

# Nginx
server {
    listen 80;
    server_name yourshop.com;
    return 301 https://yourshop.com$request_uri;
}

# Apache (.htaccess)
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

CDN: wann und wie

Wenn Sie eine Region von einem lokalen Server aus bedienen, bringt Ihnen das CDN nicht viel Geschwindigkeit. Was es Ihnen bringt, ist das Caching statischer Assets und eine kostenlose DDoS-Schicht.

Cloudflares kostenlose Stufe deckt die meisten Shops ab: globales CDN, kostenloses SSL, einfacher DDoS-Schutz, HTTP/2, Brotli. Richten Sie es unter Erweiterte Einstellungen → Leistung → Media-Server ein.

Aggressiv cachen: Bilder, CSS, JS, Schriftarten.
Niemals cachen: Admin, Warenkorb, Kassenvorgang, Mein Konto, alles, was ein PrestaShop-Cookie berührt.

Aktivieren Sie niemals „Cache Everything" für die gesamte Domain. Wir haben es erlebt: Ein Kunde sieht den Warenkorb eines anderen Kunden, weil der Kassenvorgang am Edge gecacht wurde. Cachen Sie nur statische Assets und benannte URL-Muster.

Backups: die Snapshots des Hosters sind keine Strategie

Anbieter-Backups laufen meist wöchentlich, auf derselben Infrastruktur, und haben eine von null verschiedene Chance, nicht wiederherzustellen, wenn Sie sie brauchen. Das ist eine Beruhigungsdecke. Wenn der Anbieter eine schlechte Nacht hat, gehen die Backups mit dem Shop mit. Wenn Ransomware Ihre Dateien verschlüsselt, werden die verschlüsselten Versionen brav mitgesichert. Und Sie wollen wahrscheinlich eine Datenbank von vor zwei Stunden, nicht von letztem Dienstag.

Was Sie wollen, mindestens: tägliche automatisierte DB-Dumps plus Datei-Backups, gespeichert außerhalb des Produktionsservers, 30 Tage aufbewahrt, mit einer Test-Wiederherstellung jeden Monat. Planen Sie diese Jobs an einer sichtbaren Stelle; MPR Cron Manager ist die PrestaShop-seitige Option, wenn Sie Backup-Aufgaben nachverfolgt haben wollen, statt sie in anonymen crontab-Zeilen zu verstecken. Unser Backup-Leitfaden enthält das Runbook.

Umzug zwischen Hostern

Stellen Sie den neuen Server bereit mit derselben PHP-Version und denselben Erweiterungen.
Dumpen Sie die Datenbank: mysqldump -u root -p prestashop_db | gzip > backup.sql.gz
Synchronisieren Sie die Dateien: rsync -avz /var/www/html/prestashop/ newserver:/var/www/html/prestashop/
Importieren Sie die Datenbank auf dem neuen Server.
Aktualisieren Sie die Zugangsdaten in app/config/parameters.php.
Korrigieren Sie die Berechtigungen: chown -R www-data:www-data, Verzeichnisse 755, Dateien 644.
Leeren Sie den Cache: rm -rf var/cache/*
Testen Sie über /etc/hosts, richten Sie Ihren Laptop auf die neue IP und gehen Sie Kassenvorgang und Admin durch, bevor es jemand anderes tut.
Senken Sie den DNS-TTL 24 Stunden vor der Umschaltung auf 300 Sekunden.
Finale DB-Synchronisierung direkt vor dem Umlegen des DNS, damit die letzten Bestellungen nicht verloren gehen.

Wo Migrationen schiefgehen

Dateieigentümerschaft. Der Web-User muss Eigentümer der Dateien sein. Cache, img, upload, download müssen alle beschreibbar sein.
Fehlende .htaccess. Migrations-GUIs überspringen liebend gern Dotfiles. Apache braucht außerdem AllowOverride All, um sie zu beachten.
Basis-URL-Abweichung. Wenn sich die Domain geändert hat, aktualisieren Sie ps_shop_url, sonst brechen alle Links.
PHP-Versionssprung. Der Wechsel von 7.4 auf 8.1 bricht jedes Modul, das noch veraltete Funktionen aufruft.

Legen Sie das DNS niemals um, bevor Sie über /etc/hosts getestet haben. Wir haben zugesehen, wie zwei Migrationen den Kassenvorgang in der Produktion zerlegten, weil niemand auf dem neuen Server zuerst auf „Kaufen" geklickt hatte.

Warnsignale: gehen Sie weg, wenn Sie diese sehen

Technisch

Kein SSH. Sie können nicht deployen, nicht debuggen, keines der Tools ausführen, die Probleme tatsächlich beheben.
PHP 7.x im Jahr 2026. End of Life. Bekannte Schwachstellen, die nicht gepatcht werden.
Kein OPcache. 3–5x langsamer als derselbe Code mit eingeschaltetem OPcache. Kein Grund dafür.
HDD-Speicher. Wenn sie nicht schriftlich SSD oder NVMe sagen, gehen Sie von HDD aus.
Gesperrte php.ini. Sie können PrestaShop nicht ordentlich betreiben, ohne zumindest memory_limit anzuheben.

Geschäftlich

„Unlimitiert" irgendetwas. Nichts ist unlimitiert. Sie drosseln die lauten Mieter, statt es zu sagen.
Holding-Marken. Fünf „verschiedene" Hoster, die demselben Mutterkonzern gehören, alle auf demselben überverkauften Blech, mit unterschiedlichen Logos.
Kein Verfügbarkeits-SLA. Sie vertrauen ihrer eigenen Infrastruktur nicht genug, um eine Zahl daranzuschreiben.
Support antwortet in Tagen. Ein Ausfall um 2 Uhr nachts braucht Minuten, nicht „am nächsten Werktag".
Erzwungene Jahresabrechnung. Sie setzen darauf, dass Sie nicht gehen, wenn Sie merken, dass es ein Fehler war.

Das günstigste Hosting ist dasjenige, das während des Black Friday online bleibt. 5 $/Monat bei einem Hoster zu sparen, der Sie über ein Wochenende 5.000 $ an Conversions kostet, ist keine Ersparnis.

Checkliste vor dem Kauf

Jede Zeile hier zählt. Haken Sie sie ab, bevor Sie eine Karte hinterlegen.

Server

PHP-Version passt zu Ihrer PrestaShop-Version
Alle erforderlichen PHP-Erweiterungen verfügbar (mindestens intl, mbstring, gd)
php.ini ist konfigurierbar (memory_limit, OPcache-Einstellungen)
MySQL oder MariaDB in einer Version, die PrestaShop tatsächlich unterstützt
SSD oder NVMe schriftlich
SSH-Zugriff
Uneingeschränkte Cron-Frequenz

Leistung

OPcache aktiviert und konfigurierbar
4 GB+ RAM in dem Tarif, den Sie wählen, oder 2 GB für einen kleinen PrestaShop-1.7-Shop zum Einstieg
HTTP/2 aktiviert
Redis oder Memcached verfügbar

Zuverlässigkeit

Verfügbarkeits-SLA von 99,9 % oder besser
Automatisierte und manuelle Backup-Optionen
Kritische Support-Reaktionszeit in Stunden gemessen, nicht in Tagen
Rechenzentrum in der Nähe Ihrer Kunden

Preisgestaltung

Verlängerungspreis (nicht Einstiegspreis) geprüft
Monatliche Abrechnung verfügbar
Bandbreiten- oder Transferlimits verstanden
Keine Klausel, die Sie an einem Wegzug hindert

Worauf wir Sie setzen würden, nach Phase

Brandneuer Shop: Cloud-VPS mit mindestens 4 GB RAM für PrestaShop 8 oder 9 oder 2 GB für einen kleinen PrestaShop-1.7-Shop, dazu ein kostenloses CDN und Let's Encrypt. Schlägt die meisten 15-$/Monat-Shared-Angebote um Längen.
Wachsender Shop: Managed VPS für 15–30 $/Monat. Bezahlen Sie jemanden dafür, das Betriebssystem gepatcht zu halten, während Sie sich aufs Verkaufen konzentrieren.
Etabliert (1K+ Besucher pro Tag): VPS mit 8–16 GB RAM, getuntem MariaDB, eingeschaltetem Redis, nginx mit FastCGI-Cache. 15–40 $/Monat bringen Sie dorthin.
Großer Katalog oder hoher Traffic: Dedizierter Server (günstige EU-Dedicated-Server übertreffen Cloud-VPS auf dieser Skala) oder eine sauber getrennte Cloud-Architektur. 50–100+ $/Monat und jeden Cent wert.

Richten Sie das Uptime-Monitoring am ersten Tag ein. UptimeRobot ist für 50 Monitore kostenlos und gut genug. Sobald das Hosting geregelt ist, hat der Rest der Optimierungsarbeit einen soliden Boden zum Aufsetzen.

Weiterführende Lektüre

PrestaShop-Performance optimieren: Machen Sie Ihren Shop schneller. Was zu tunen ist, sobald das Hosting geklärt ist
PrestaShop-Sicherheit härten: die vollständige Checkliste, Absicherung auf Server-Ebene
PrestaShop-Fehlerbehebung: weiße Seiten und 500-Fehler beheben, wenn der Hoster das Problem ist und Sie es beweisen müssen
PrestaShop-Backups: echte Sicherungen statt Beruhigungsdecken, das Runbook, das wir selbst verwenden
Performance Revolution, eines unserer Module; passt gut zu einem richtig dimensionierten VPS