Deploy your first Apps Script web app

Updated June 21, 2026

A web app is a web page that you build inside Google Apps Script. Anyone with the URL opens it in a normal browser. Unlike traditional websites, there is no website to host, no domain to buy, no server to run. The page is hosted by Google and the code that builds the page lives bound to a Google Sheet, a Google Doc, or a standalone Apps Script project.

In this tutorial, I will show you how to deploy a web app. The example I will use is a slight variation of the traditional "Hello World" program: a page that reads a name from a cell in a sheet and shows Hello {name}!.

By the end of this tutorial you will have a live URL you can open from any browser, and you will know what web apps in Apps Script are and when to use them.

An arrow connects a spreadsheet cell labeled 'Reader' to a 'Hello Reader!' message.
Newsletter Subscriber Exclusive

Get the Hello Web App Demo

A ready-to-copy Google Sheet with the Apps Script project already configured. Subscribe to get the copy link so you can deploy your own copy and follow along.

By subscribing, you agree to our Privacy Policy and Terms of Service

Already a subscriber? Log in

What you should know first

You need a Google account and access to Google Sheets. That is it. You do not need to know JavaScript, you do not need to install anything, and you do not need to pay for hosting. If you have ever opened the script editor from Extensions > Apps Script and clicked Run on a function, you already have enough background to proceed.

What you are about to do

What an Apps Script web app is

A web app is a function in an Apps Script project named doGet. Apps Script calls that function every time someone opens the deployment URL. Whatever the function returns is what the browser shows. The return value can be a styled HTML page, a snippet of JSON, or plain text.

The function runs on Google's servers, signed in as you, with full access to every Google service you use. It can read from a sheet. It can write to a Doc. It can send an email. It can hit any external API.

This makes it easy for us to build powerful applications using very little code. I've built my own CRM, bookmark manager, time tracking app and many other personal tools that are all built using web apps.

What does `doGet` mean?

Apps Script looks for two specific function names when you deploy a web app: doGet and doPost. doGet runs when someone opens the URL in a browser (a GET request). doPost runs when something submits a form to the URL (a POST request). For most simple web apps, doGet is the only one you need.

What people use web apps for

Most web apps I see fall into one of three buckets:

  • Intake forms. A page with a few fields that writes the submission to a sheet. Useful when Google Forms does not support the question types or you want to customize the look and feel to match your company's brand guidelines.
  • Dashboards. A page that reads from a sheet and shows a snapshot. Useful when you want your colleagues to view reports without giving them access to the sheet.
  • Internal tools. A page that searches, filters, or kicks off an action. Useful to build simple internal tools, or interfaces to trigger automated workflows.

The Hello demo in this post is the simplest possible version of the third bucket. It reads one cell and shows a styled page. Once you understand the deploy step, scaling up to a real internal tool is the same handful of clicks.

Three web app examples: an intake form, a dashboard, and an internal tool.

How it works under the hood

Before you click Deploy, here is what happens every time someone opens the URL:

Flowchart showing a Google Apps Script reading a sheet and returning a web page.
  1. Visitor pastes the URL into a browser.
  2. Google Apps Script wakes up the script project and runs the doGet function.
  3. doGet reads the named cell from the spreadsheet.
  4. Apps Script wraps the result in an HTML page and sends it back to the browser.

Step 1 — Open the demo sheet

Click the subscriber link above to copy the demo sheet into your own Drive. The copy comes with the bound Apps Script project already attached, so you do not have to copy/paste anything. You should see a tab called Hello with a yellow cell labeled Name to greet, a row for the live web app URL, and a second tab called DISCLAIMER that you can ignore for this walkthrough.

A Google Sheets spreadsheet titled 'Hello Web App Demo' with instructions and input fields.

Step 2 — Open the script editor

From the menu bar, click Extensions, then Apps Script. A new tab opens with the bound script project. You should see two files in the left rail: Code.gs and Hello.html. You do not need to change anything to deploy.

Step 3 — Click Deploy and pick Web app

In the script editor, click the blue Deploy button in the top right, then New deployment. A dialog opens with a gear icon next to Select type. Click the gear and pick Web app. The dialog displays four web-app-specific fields.

3.1 Click the Deploy button

Google Apps Script header showing 'Hello Web App Demo Script' and a Deploy button.

3.2 Select New deployment

Google Apps Script editor interface with the Deploy dropdown menu open.

3.3 Select Web app as the deployment type

Click the gear icon to open the menu.

A dropdown menu showing deployment type options in a new deployment interface.

3.4 Configure the deployment and deploy the web app

A 'New deployment' configuration interface for deploying a web app.

Figure 5: The three settings on the New deployment dialog. Each one is explained below.

For the demo, set the fields like this:

  • Description. Type anything that helps your future self. I use the version, like v1.
  • Execute as. It should display your email indicating the web app will run under your account. Leave it as-is for this example project. The other option is to execute as the user accessing the app. I'll explain when to use this configuration later on.
  • Who has access. Pick Only myself for now. You can change this later.
  • Click Deploy.

Google will then ask you to authorize the script the first time. Click through the consent screens, choose your Google account, and grant the permissions. After that, Google shows you the live web app URL. Copy it.

Deployment confirmation screen with a red box highlighting the URL copy button.

Step 4 — Open the live URL

Paste the URL into a new browser tab. You should see a cream page with a card in the middle that reads Hello Reader!. That is the deployed web app, served from your own Google account, reading from the cell in your sheet.

Web app demo screen displaying the text 'Hello Reader!'.

Paste the same URL back into the Web app URL row of the demo sheet so you can find it later. The button on the sheet links straight to the page.

Step 5 — Change the name and refresh

Go back to the sheet. Click the yellow Name to greet cell. Type your own name, or a friend's name, or the name of your dog. Press Enter. Open the web app URL again or refresh the tab. The greeting updates.

Nothing about the deployment changed. The code did not get re-pushed. The URL is the same. The page just re-ran doGet, which read the sheet again, which had a different value this time.

Understanding the deployment settings

Now I want to walk through every setting on the deploy dialog.

Type

Apps Script supports several deployment types. Web app is the one for a URL someone can open in a browser. The other types (Add-on, Library, API executable) are for different surfaces, like a product you launch on the Google Workspace marketplace or a function another script can call. For anything that ends in a URL someone visits, pick Web app.

Description

This is a free-text note for you. Google does not show it to anyone who visits the page. It matters because every time you change the code and want the live URL to reflect the change, you make a new deployment, and the deployment shows up in your Manage deployments list with the description as its label. v1, v2, Adds a search box, Fixes the typo in the heading. Future-you will be grateful.

Execute as

This is the most important setting in the dialog. It controls whose Google account the script runs as when someone opens the URL. There are two choices.

Me means the script always runs as you. Every visitor, no matter who they are, triggers a run that uses your permissions. If the script reads from a sheet, it reads from your copy of the sheet using your access. Visitors do not need to be signed in to any account that has permission on the sheet. Pick this when the sheet is private to you and you want the page to be the only thing visitors see.

User accessing the web app means the script runs as whoever is signed in to the browser visiting the page. The first time each visitor opens the URL, they have to grant the script permission to read their own data, and they see a Google permission screen (the OAuth consent screen, a standard sign-in step where the visitor agrees to let the script read their data). Pick this when each visitor should only see their own data, for example a personal dashboard that reads data that only they should see. For example, a teacher might build a web app that shows students their grades but not that of other students.

For the Hello demo, I picked Me. The sheet is mine, the page just shows a greeting, and there is no reason for a visitor to authorize anything.

Who has access

This controls who is allowed to open the URL. The options available to you will depend on whether your Google account is a personal Gmail account or a Workspace account:

  • Only myself. Only your own Google account can open the URL. Useful while testing or for a tool that is just for you.
  • Anyone with a Google account. Any signed-in Google user can open the URL. They have to be logged in but they do not need to be on any list.
  • Anyone in (your organization). Workspace only. Anyone on your domain can open the URL. Useful for internal tools.
  • Anyone. Anyone with the link can open the URL, signed in or not. Useful for public-facing pages but be careful, because the URL is not a secret if you share it widely.

Configure this setting based on your specific use case. Pick the narrowest option possible. You can always widen access later if needed.

What happens when you update the code

This is the most common gotcha when working with web apps. Changing the code in the editor does not change what visitors see. The live URL points to a specific deployment, which is a frozen snapshot of the code at the moment you clicked Deploy. To make the URL reflect your latest changes, you either deploy a new version (which gives you a new URL) or update the existing deployment in place (which keeps the URL stable). For a live, shared URL, you almost always want the second option.

From the Deploy button, click Manage deployments. Find the deployment you want to update, click the pencil icon, change the Version dropdown to New version, add a description, and click Deploy. The URL stays the same, the code behind it is now the new version.

Key Takeaway

The live URL is tied to a deployment, not to your latest code. Edit the code as much as you want; the live page does not change until you push a new version of the deployment.

Test deployments versus live deployments

Next to New deployment there is a Test deployments option. A test deployment is a separate URL that always runs the latest code in the editor, no version pinning. It ends in /dev instead of /exec. Use it while you are iterating, because you do not need to make a new deployment for every change. Test deployments are private to you and require you to be signed in to your Google account in the same browser.

When the page looks right under /dev, push a real deployment under /exec. That is the URL you share with other people.

Conclusion

In this tutorial, I introduced you to web apps in Apps Script. A web app is the simplest way to turn a Google Sheet into something that looks and feels like an app. Copy the demo, deploy it, share the URL with one person, and you have shipped your first web app!

DISCLAIMER: This content is provided for educational purposes only. All code, templates, and information should be thoroughly reviewed and tested before use. Use at your own risk. Full Terms of Service apply.