Ga naar inhoud

Bestanden uploaden

Een statische website hoeft niet via een FTP-locatie binnen te komen, en een applicatie die op de server wordt gebouwd heeft geen GitHub-repository nodig. Uw assistent of uw script zet de bestanden rechtstreeks op de server.

  • De assistent schrijft bestanden eerst in een concept (tool write_site_files, API PUT /sites/{site}/draft/files). Daarvan is nog niets zichtbaar.
  • Met publiceren (publish_site_draft, POST /sites/{site}/draft/publish) gaat het concept in één keer live. Voor een kleine wijziging kan de assistent schrijven en publiceren in één stap (publish: true).
  • Voor elke publicatie wordt de huidige versie gearchiveerd. Met restore_site_version (of het tabblad Versions op de pagina van de site) zet u haar terug. Publicaties van een concept binnen tien minuten delen één archief, zodat een assistent die bestand voor bestand werkt de versie van vóór de sessie niet uit de lijst duwt.
  • In het portaal ziet u op de pagina van de site of er een concept klaarstaat, met knoppen om het te publiceren of te verwerpen.

Een site met een concept dat klaarstaat

upload_site_archive neemt een tar.gz of zip van maximaal 8 MB (base64). Grotere sites gaan via de REST API, zonder die grens:

Terminal window
tar -czf site.tar.gz -C ./dist .
curl -X PUT -H "Authorization: Bearer hdd_..." -H "Content-Type: application/gzip" \
--data-binary @site.tar.gz \
"https://<uw-server>.hddeploy3000.nl/api/v1/sites/mijnsite/content"

Opties: ?mode=replace (standaard, vervangt de hele inhoud zoals een synchronisatie) of ?mode=merge (bestanden die niet in het archief zitten blijven staan), en ?stripRoot=true om één bovenste map uit het archief weg te laten. Het archief mag application/gzip, application/zip of application/octet-stream zijn; in het laatste geval herkent de server het formaat zelf.

Een site die al via FTP wordt gesynchroniseerd kan ook uploads ontvangen. Let op: een synchronisatie vervangt de hele map, dus bij de volgende wijziging op de FTP-locatie verdwijnen geüploade bestanden. Wilt u alleen uploaden, kies dan bij de site voor upload only (of laat de assistent create_upload_site gebruiken; API PUT /sites/{site}). Zo’n site heeft geen bron en wordt nooit gecontroleerd.

list_site_files en get_site_file (API GET /sites/{site}/files en GET /sites/{site}/file?path=) lezen de live content, tot 2 MB per bestand. Tekst komt als tekst, binaire bestanden als base64.

Voor een stack die op de server wordt gebouwd (met een Dockerfile) vervangt upload_stack_source de broncode door een geüpload archief; daarna bouwt deploy_stack de nieuwe versie. Grotere projecten gaan via de API:

Terminal window
tar -czf app.tar.gz -C ./mijn-app .
curl -X PUT -H "Authorization: Bearer hdd_..." -H "Content-Type: application/gzip" \
--data-binary @app.tar.gz \
"https://<uw-server>.hddeploy3000.nl/api/v1/stacks/mijnapp/source/upload?deploy=true"
  • ?deploy=true zet de bouw direct in de wachtrij.
  • Een stack die nu nog uit een GitHub-repository bouwt, stapt hiermee over op uploads; de deploy key en de webhook van de repository worden dan verwijderd. Terug naar een repository kan altijd via het tabblad Source.
  • Het tabblad Source toont welke upload is uitgerold (de eerste 40 tekens van de controlesom staan op de plek van de commit), wanneer en door wie.

Het tabblad Source van een stack met geüploade broncode

Maximale grootte per upload of concept 1 GB voor sites, 512 MB voor broncode (uitgepakt); daarboven 413
Bestanden per concept-schrijfactie 200
Archief via een MCP-tool 8 MB (base64); groter via de API
Lezen van een bestand maximaal 2 MB
Inhoud van archieven alleen gewone bestanden en mappen; symbolische koppelingen, apparaten en paden met .. worden geweigerd (422)
Snelheidslimiet uploads tellen niet mee voor de 120 verzoeken per minuut

Een afgebroken upload laat niets achter: de server pakt eerst uit op een tijdelijke plek en vervangt de inhoud pas als alles goed is.