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 ein Framework — WebforJ (WAR oder JAR), Spring Boot (JAR) oder Node.js. 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 .war oder .jar-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 oder JAR ist im Kern ein Zip.
Das Archiv wird sicher (geschützt gegen Zip-Slip-Pfadtricks) in ein temporäres Verzeichnis entpackt. Bei einer WAR prüft Shippers, ob ein WEB-INF/ -Verzeichnis existiert. Bei einer JAR prüft es auf ein BOOT-INF/classes/-Verzeichnis und einen Start-Class-Manifesteintrag — 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 einer Minute, während Tomcat oder die JVM hochfährt.
Was nach dem Upload passiert, hängt vom App-Typ ab — hier ist, was jede Engine tatsächlich macht.
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.
Die Spring-Boot-Jar validieren
Shippers prüft auf einen BOOT-INF/classes/-Eintrag und einen Start-Class-Manifest-Header — die Markierungen, die Maven's oder Gradle's Spring-Boot-Repackage-Schritt immer erzeugt.
Mit java -jar ausführen
Shippers wählt ein passendes JDK-Image für deine kompilierten Klassen und führt die Jar direkt aus — kein Anwendungsserver nötig.
Bestätigen, dass sie tatsächlich gestartet ist
Shippers wartet, bis der Port der App offen ist, und durchsucht die Startprotokolle nach einem fehlgeschlagenen Application Context, 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.