Apps Script deployen als webapp of add-on is de stap waarmee je script van een persoonlijk hulpmiddel naar een gedeelde toepassing gaat. Een webapp geeft een URL die mensen of systemen aanroepen; een add-on breidt Sheets, Docs of Gmail uit voor je hele organisatie. In dit artikel leer je het verschil, de instellingen en hoe je veilig versies beheert.
Twee soorten deployments
Er zijn twee hoofdvormen. Een webapp publiceert je script op een URL: bezoekers krijgen een HTML-pagina (via doGet) of systemen sturen data (via doPost). Een add-on (editor-add-on of Workspace-add-on) integreert je script in de interface van een Google-app, zodat collega's het via een zijpaneel of menu gebruiken. Daarnaast kun je een script publiceren als API-executable of als bibliotheek.
Vier implementatietypes
In het menu Implementeren kies je het type: Webapp, Add-on, API-executable of Bibliotheek. Elk type heeft eigen instellingen en een eigen manifest in appsscript.json. De volledige uitleg staat op developers.google.com/apps-script/concepts/deployments.
Een webapp deployen
Een webapp heeft een doGet of doPost nodig. Daarna implementeer je hem met de juiste toegangsinstellingen:
function doGet() {
return HtmlService.createHtmlOutput('<h1>Hallo vanuit mijn webapp</h1>');
}
Een webapp implementeren
- Schrijf een
doGetdie HTML teruggeeft, of eendoPostvoor data. - Klik op Implementeren, dan Nieuwe implementatie en kies het type Webapp.
- Stel Uitvoeren als in: jezelf of de gebruiker die de app opent.
- Stel Wie heeft toegang in: alleen jij, je organisatie, iedereen met een Google-account, of iedereen.
- Klik op Implementeren en deel of gebruik de webapp-URL.
Uitvoeren als: jij of de gebruiker
Een cruciale keuze is wie het script uitvoert. Bij Uitvoeren als mijzelf draait het script altijd met jouw rechten, ook als iemand anders het opent. Dat is handig als je wilt dat iedereen bij jouw spreadsheet kan, maar het betekent ook dat acties op jouw naam gebeuren. Bij Uitvoeren als de gebruiker draait het met de rechten van de bezoeker, die dan zelf toegang tot de data moet hebben.
Iedereen plus jouw rechten is gevaarlijk
Zet je een webapp op Uitvoeren als mijzelf en Toegang voor iedereen, dan kan elke bezoeker acties uitvoeren met jouw rechten en bij jouw data. Dat is een serieus beveiligingsrisico. Beperk de toegang waar mogelijk tot je organisatie, en valideer in code altijd wie de aanroep doet voordat je gevoelige acties uitvoert.
Versies beheren
Een implementatie wijst naar een specifieke versie van je code. Wijzig je je script, dan verandert de gedeployde webapp niet vanzelf: je moet de implementatie bijwerken naar een nieuwe versie. Zo blijft productie stabiel terwijl je doorontwikkelt. Let op: pas je een bestaande implementatie aan via Implementaties beheren, dan houd je dezelfde URL. Maak je telkens een nieuwe implementatie, dan krijg je elke keer een nieuwe URL en blijft de oude actief.
Splits test en productie
Gebruik een vaste implementatie voor productie en een aparte testimplementatie voor ontwikkeling. De testimplementatie wijst naar Head (je laatste code), de productie-implementatie naar een specifieke, geteste versie. Zo test je nieuwe code zonder je gebruikers te raken, en promoot je pas naar productie als het werkt.
Welk type kies je?
| Type | Wat het is | Kies dit als |
|---|---|---|
| Webapp | Draait op een URL, ideaal voor formulieren, dashboards, webhooks en kleine interne tools | Je een eigen pagina of een endpoint nodig hebt |
| Add-on | Integreert in Sheets, Docs, Slides, Forms of Gmail via een zijpaneel | Je functionaliteit binnen een bestaande Google-app aan een team wilt aanbieden |
| Bibliotheek | Herbruikbare code die je deelt met andere scripts | Meerdere projecten dezelfde functies nodig hebben |
Een add-on uitrollen in je organisatie
Een add-on publiceer je via de Google Workspace Marketplace SDK. Voor een interne tool kies je bij het publiceren voor privé (domeinspecifiek): de listing is dan alleen vindbaar en installeerbaar voor mensen binnen jouw Workspace-organisatie, en Google reviewt de app niet vooraf. Een beheerder kan de add-on vervolgens domeinbreed uitrollen.
Zichtbaarheid ligt vast na publicatie
De keuze tussen privé en openbaar leg je vast tijdens publicatie en kun je daarna niet meer wijzigen. Bepaal dus vooraf welke zichtbaarheid je add-on nodig heeft voordat je begint.
Waarom zie ik mijn codewijziging niet in de webapp?
Omdat de implementatie naar een eerdere versie wijst. Werk de implementatie bij naar een nieuwe versie via Implementaties beheren. Een testimplementatie die naar Head wijst toont je laatste code wel direct.
Wat betekent Uitvoeren als mijzelf?
Het script draait met jouw rechten, ongeacht wie het opent. Dat is handig voor gedeelde data, maar wees voorzichtig met de toegangsinstelling: combineer dit niet met toegang voor iedereen zonder eigen validatie in je code.
Hoe publiceer ik een add-on voor mijn hele organisatie?
Via de Google Workspace Marketplace SDK publiceer je de add-on privé voor je domein. De beheerder kan die daarna uitrollen naar gebruikers in de organisatie.
Kan ik een implementatie weer intrekken?
Ja. Via Implementaties beheren archiveer of verwijder je een implementatie, waarna de bijbehorende URL niet meer werkt.
Wat is het verschil tussen Head en een versie?
Head is altijd je laatste, niet-vastgezette code en is bedoeld voor testen. Een versie is een vastgelegde momentopname; daar wijs je je productie-implementatie naar, zodat die niet meebeweegt met elke wijziging.
Volgende stap
Met deployments deel je je werk breed. Voor webhooks specifiek lees je webhooks ontvangen en verwerken, en voor een professionele ontwikkelworkflow clasp gebruiken.