Hoe het werkt

Van buildmap naar live URL

Drie stappen aan de oppervlakte. Daaronder valideert, sandboxt en routeert Shippers je app voordat deze ooit live gaat.

1

Maak een app aan

Geef je app een naam en kies een type — ZIP voor een statische React- of Flutter-webbuild, WAR voor een WebforJ Java-app. De naam wordt onderdeel van de slug van je app, gecontroleerd tegen een gereserveerde lijst zodat je nooit per ongeluk iets als www of admin kunt claimen.

2

Upload je build

Sleep je .zip of .war-bestand naar binnen. Shippers streamt het naar schijf binnen het opslagquotum van je account, controleert of de bestandsextensie overeenkomt met het opgegeven apptype, en verifieert dat de eerste bytes een echte zip-signature zijn — een WAR is onder de motorkap een zip.

3

Shippers valideert en bouwt

Het archief wordt veilig uitgepakt (beschermd tegen zip-slip padtrucs) in een tijdelijke map. Bij een ZIP controleert Shippers of er een index.html bestaat. Bij een WAR controleert het op een WEB-INF/ map en detecteert het welke JDK-versie je gecompileerde classes nodig hebben.

4

Een gesandboxte container start

Je content wordt gekopieerd naar een afgeschermde container — ingetrokken capabilities, geen host-netwerktoegang, harde limieten voor CPU/geheugen/processen — en pas daarna stopt Shippers wat er voorheen voor deze app draaide, zodat een slechte upload nooit een werkende deployment platlegt voordat de nieuwe bevestigd werkbaar is.

5

Krijg een live URL

Traefik pakt automatisch de routeringslabels van de container op en je app is bereikbaar op yourapp.shippers.cloud — meestal binnen enkele seconden voor een ZIP, of binnen een minuut voor een WAR terwijl Tomcat opstart.

Twee deployengines, één workflow

Wat er na de upload gebeurt verschilt per apptype — dit is wat elke engine daadwerkelijk doet.

ZIP

Statische builds (React, Flutter web)

  1. 1

    Uitpakken & valideren

    Het archief wordt uitgepakt en gecontroleerd op een index.html in de root.

  2. 2

    Serveren vanaf een gedeelde nginx-image

    Content wordt gekopieerd naar een lichtgewicht, vooraf gebouwde nginx-image met SPA-fallback-routering — geen image-build per deployment nodig.

  3. 3

    De draaiende container wisselen

    De vorige container voor deze app wordt pas gestopt nadat de nieuwe content gevalideerd en klaar is om te serveren.

WAR

Java-webapps (WebforJ)

  1. 1

    Vereiste JDK detecteren

    Shippers leest de versies van je gecompileerde .class-bestanden om een Tomcat-image met een compatibele JDK te kiezen — geen pom.xml-parsing nodig.

  2. 2

    Opstarten binnen Tomcat

    Je WAR wordt gedeployed als de rootcontext van de app, zodat deze bereikbaar is op het kale subdomein in plaats van een subpad.

  3. 3

    Bevestigen dat het echt is gestart

    Shippers wacht tot de poort van Tomcat opent en scant opstartlogs op ernstige fouten voordat de deployment als geslaagd wordt gemarkeerd.

Gebouwd voor niet-vertrouwde uploads

Shippers is een hostingprovider voor code van vreemden, dus isolatie is geen bijzaak.

Elke container draait met harde limieten voor CPU, geheugen en processen, ingetrokken Linux-capabilities en geen host-netwerktoegang — standaard geïsoleerd, niet via configuratie.

Archiefextractie is zip-slip-veilig, zodat een gemanipuleerd pad in een upload nooit buiten zijn eigen deploymentmap kan komen.

Probeer het met je eigen build

Maak een gratis account en krijg in minder dan een minuut een live URL.