Hosting
Shop Hosting: die Maschine darf den Warenkorb nicht ausbremsen
Ein Shop stirbt nicht an der Farbe des Buttons, sondern an Timeouts, vollen Warenkörben und einem Cache, der Preise von gestern ausliefert. Shop Hosting bei uns ist Webhosting, das für Bestellungen gebaut ist.
Wir richten die PHP-Grenzen, den Opcode-Cache und die Datenbank so ein, dass WooCommerce, Shopware oder ein Plenty-Frontend nicht nach der dritten gleichzeitigen Bestellung in die Knie gehen. Redis oder Object-Cache legen wir dazu, wenn der Shop das hergibt. Zahlungs- und Versand-Plugins testen wir nach dem Einzug, nicht erst wenn der Kunde in der Kasse hängt.
Was drinsteckt
- Höhere PHP-Speicher- und Ausführungsgrenzen als im normalen Webhosting
- Getrennte Datenbank, kein Teilen mit zehn fremden Shops auf derselben Instanz ohne Absprache
- Vorbereitung für Cronjobs (Bestände, Zahlungen, Feeds)
- SSL, HTTP/2, optionale eigene IPv4
- Abstimmung mit unserer Shopware- und Plenty-Betreuung, wenn der Shop von uns kommt
Was wir nicht versprechen
Kein „unbegrenzt“ und keine Million Besucher auf einem Shared-Paket. Wenn der Shop wächst, sagen wir das und bieten den Sprung auf Managed Server oder Cloud. Lieber einmal umziehen als drei Tage Ausfall in der Kampagne.
Was wir vor dem Einzug prüfen
Kataloggröße, Zahl der Varianten, ob eine Live-Suche mitläuft, welche Cronjobs Bestände und Zahlungen anstoßen, und ob der Checkout Gäste zulässt oder Konten erzwingt. Daraus folgt die PHP-Grenze und ob ein Object-Cache Pflicht ist oder Kür.
Zahlungs-Plugins mit eigenem Iframe (PayPal, Stripe, Klarna) testen wir gegen die echte, aber nicht produktive Kasse. Ein „sieht im Backend gut aus“ reicht nicht; der Testkauf muss eine Bestellnummer erzeugen.
Betrieb
Updates von Shop-Kern und Zahlungsplugins gehören in ein Wartungsfenster, nicht in den laufenden Sale. Wer selbst aktualisiert, macht das auf eigener Verantwortung; wir spielen zurück, wenn eine Sicherung vom Vortag existiert und Sie uns das Fenster geben.