Drei Schritte an der Oberfläche. Darunter validiert, sandboxt und routet Shippers deine App, bevor sie überhaupt live geht.
Gib deiner App einen Namen und wähle einen Typ — ZIP für einen statischen React- oder Flutter-Web-Build, WAR für eine WebforJ-Java-App. Der Name wird Teil des Slugs deiner App und gegen eine Sperrliste geprüft, sodass du nie versehentlich etwas wie www oder admin beanspruchen kannst.
Zieh deine .zip oder .war-Datei hinein. Shippers streamt sie im Rahmen des Speicherkontingents deines Kontos auf die Festplatte, prüft, ob die Dateiendung dem angegebenen App-Typ entspricht, und verifiziert, dass die ersten Bytes eine echte Zip-Signatur sind — eine WAR ist im Kern ein Zip.
Das Archiv wird sicher (geschützt gegen Zip-Slip-Pfadtricks) in ein temporäres Verzeichnis entpackt. Bei einem ZIP prüft Shippers, ob eine index.html existiert. Bei einer WAR prüft es auf ein WEB-INF/-Verzeichnis und erkennt, welche JDK-Version deine kompilierten Klassen benötigen.
Dein Inhalt wird in einen gehärteten Container kopiert — entzogene Capabilities, kein Host-Netzwerkzugriff, feste CPU-/Speicher-/Prozesslimits — und erst danach stoppt Shippers, was zuvor für diese App lief, sodass ein fehlerhafter Upload nie ein funktionierendes Deployment außer Betrieb setzt, bevor das neue als startfähig bestätigt ist.
Traefik übernimmt automatisch die Routing-Labels des Containers und deine App ist erreichbar unter yourapp.shippers.cloud — meist innerhalb von Sekunden für ein ZIP oder unter einer Minute für eine WAR, während Tomcat hochfährt.
Was nach dem Upload passiert, hängt vom App-Typ ab — hier ist, was jede Engine tatsächlich macht.
Entpacken & validieren
Das Archiv wird entpackt und auf eine index.html im Wurzelverzeichnis geprüft.
Auslieferung über ein gemeinsames nginx-Image
Der Inhalt wird in ein schlankes, vorgefertigtes nginx-Image mit SPA-Fallback-Routing kopiert — kein Image-Build pro Deployment nötig.
Laufenden Container austauschen
Der vorherige Container für diese App wird erst gestoppt, nachdem der neue Inhalt validiert und bereit zur Auslieferung ist.
Benötigte JDK erkennen
Shippers liest die Versionen deiner kompilierten .class-Dateien, um ein Tomcat-Image mit einer kompatiblen JDK auszuwählen — kein Parsen von pom.xml nötig.
Start innerhalb von Tomcat
Deine WAR wird als Root-Kontext der App deployt, sodass sie unter der reinen Subdomain statt einem Unterpfad erreichbar ist.
Bestätigen, dass es wirklich gestartet ist
Shippers wartet, bis der Port von Tomcat öffnet, und durchsucht die Startlogs nach schwerwiegenden Fehlern, bevor das Deployment als erfolgreich gilt.
Shippers ist ein Hosting-Anbieter für Code von Fremden, daher ist Isolation kein Nachgedanke.
Jeder Container läuft mit festen Limits für CPU, Arbeitsspeicher und Prozesse, entzogenen Linux-Capabilities und ohne Host-Netzwerkzugriff — standardmäßig isoliert, nicht per Konfiguration.
Die Archivextraktion ist Zip-Slip-sicher, sodass ein manipulierter Pfad in einem Upload nie aus seinem eigenen Deployment-Verzeichnis ausbrechen kann.
Erstelle ein kostenloses Konto und erhalte in weniger als einer Minute eine Live-URL.