DEV Community: Ozan

Preview Deployments with Firebase Hosting & GitHub Actions

Ozan — Thu, 26 Feb 2026 23:21:17 +0000

When I briefly worked with Peec AI, one of the first things I noticed that could greatly improve the developer experience was adding preview deployments to their toolbox. They already had code reviews, but the process felt incomplete without being able to click around a real, live version of the actual changes.

This becomes even more critical in the age of vibe coding.

Why Preview Deployments Matter

If you've used Vercel or Netlify, you know this experience is built-in. Every pull request gets deployed to a separate environment, ideally with its own subdomain, so the result of the code changes can be showcased easily.

For growing teams, the benefits compound quickly:

Visual verification — Catch UI bugs that diffs can never reveal
Faster feedback loops — Designers and PMs can review without setting up the project locally
AI agent workflows — When an agent like Cursor opens a PR, a human can visually verify the result before approving
Parallel development — Multiple PRs can be live simultaneously without stepping on each other
No staging bottleneck — Teams no longer wait for a single shared staging environment

Firebase Hosting doesn't give you this out of the box, but with GitHub Actions and Firebase's Preview Channels feature, you can build the exact same thing.

What We're Building

Here's the full lifecycle we'll automate:

PR lifecycle diagram: on PR open a preview channel is deployed and the URL is commented on the PR; on PR close the channel is deleted

A PR is opened or updated → a preview deployment is created (or updated)
A bot comments the preview URL directly on the PR
The PR is closed or merged → the preview deployment is automatically deleted

Every commit to the PR branch refreshes the preview. No manual steps, no "can you deploy this to staging?"

Prerequisites

A Firebase project with Hosting enabled
A GitHub repository
Firebase CLI installed (npm install -g firebase-tools)
A Firebase service account (we'll generate this)

Implementation

1. Setting Up Firebase Hosting

If you haven't enabled Firebase Hosting yet, run:

firebase init hosting

Follow the prompts to set your public directory and configure as a single-page app if needed. Commit the generated firebase.json and .firebaserc to your repository.

2. Generating a Service Account

GitHub Actions needs permission to deploy to Firebase on your behalf. Go to your Firebase Console → Project Settings → Service Accounts → Generate new private key.

Download the JSON file, then add its entire contents as a GitHub secret:

Settings → Secrets and variables → Actions → New repository secret

Name it FIREBASE_SERVICE_ACCOUNT.

Note: Paste the raw JSON content as-is into the secret value. Do not base64-encode it or wrap it in quotes — the action reads it as a plain string and handles parsing internally.

3. The Preview Deployment Workflow

Create .github/workflows/preview.yml in your repository:

name: Preview Deployment

on:
  pull_request:
    types: [opened, synchronize, reopened]

concurrency:
  group: firebase-preview-${{ github.event.pull_request.number }}
  cancel-in-progress: true

permissions:
  contents: read
  pull-requests: write

jobs:
  deploy_preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Compute preview channel ID
        id: channel
        run: |
          PR_NUM="${{ github.event.pull_request.number }}"
          BRANCH="${{ github.event.pull_request.head.ref }}"
          BRANCH_20="${BRANCH:0:20}"
          RAW_ID="pr${PR_NUM}-${BRANCH_20}"
          CHANNEL_ID=$(echo "$RAW_ID" | sed 's/[^a-zA-Z0-9_.-]/_/g')
          echo "channel_id=$CHANNEL_ID" >> $GITHUB_OUTPUT

      - name: Build
        run: npm run build

      - name: Deploy to Firebase Preview Channel
        id: deploy
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          channelId: ${{ steps.channel.outputs.channel_id }}
          expires: 7d
          disableComment: 'true'

      - name: Post or update PR comment with preview URL
        uses: actions/github-script@v7
        if: success() && github.event_name == 'pull_request'
        env:
          PREVIEW_URL: ${{ steps.deploy.outputs.details_url }}
        with:
          script: |
            const PREVIEW_MARKER = '<!-- firebase-hosting-preview -->';
            const previewUrl = process.env.PREVIEW_URL || '';
            const deployedAt = new Date().toISOString().replace('T', ' ').replace(/\.\d{3}Z$/, ' UTC');
            const body = `## Firebase Hosting Preview\n\n${PREVIEW_MARKER}\n\n**Preview:** [${previewUrl}](${previewUrl})\n\nLast deployed at **${deployedAt}**`;

            const { data: comments } = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
            });
            const botComment = comments.find(c => c.body && c.body.includes(PREVIEW_MARKER));
            if (botComment) {
              await github.rest.issues.updateComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                comment_id: botComment.id,
                body,
              });
            } else {
              await github.rest.issues.createComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: context.issue.number,
                body,
              });
            }

A few things to note:

The concurrency block cancels any in-progress deploy for the same PR when a new commit is pushed, preventing race conditions.
permissions: pull-requests: write is required for the comment step to work. Without it, you'll get a 403.
The channel ID is computed from both the PR number and branch name (e.g. pr42-fix-auth-bug), making channels readable in the Firebase console. Special characters in branch names are sanitized since Firebase rejects them.
disableComment: 'true' turns off the action's built-in comment so we can post a custom one via github-script . This gives full control over the comment format and uses a hidden HTML marker to find and edit the existing comment rather than posting a new one each time.
expires: 7d means the channel auto-expires after 7 days even if the cleanup workflow fails.

GitHub bot comment on a pull request showing the Firebase preview deployment URL

4. Cleanup on PR Close

When a PR is closed or merged, we want to remove the preview channel. Create .github/workflows/preview-cleanup.yml:

name: Preview Cleanup

on:
  pull_request:
    types: [closed]

jobs:
  cleanup_preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Compute preview channel ID
        id: channel
        run: |
          PR_NUM="${{ github.event.pull_request.number }}"
          BRANCH="${{ github.event.pull_request.head.ref }}"
          BRANCH_20="${BRANCH:0:20}"
          RAW_ID="pr${PR_NUM}-${BRANCH_20}"
          CHANNEL_ID=$(echo "$RAW_ID" | sed 's/[^a-zA-Z0-9_.-]/_/g')
          echo "channel_id=$CHANNEL_ID" >> $GITHUB_OUTPUT

      - name: Delete Firebase Preview Channel
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          channelId: ${{ steps.channel.outputs.channel_id }}
          expires: 1d

Setting expires: 1d is a belt-and-suspenders move, even if the action has any hiccups, the channel disappears within a day.

Firebase Hosting console showing multiple preview channels

Tips & Gotchas

Include the branch name in the channel ID. Channel names must be unique per project. Using pr{number}-{branch} (e.g. pr42-fix-auth-bug) keeps them human-readable in the Firebase console and idempotent, the same PR always maps to the same channel. Just make sure to sanitize the branch name since Firebase rejects characters like / and :.

Firebase Hosting has a channel limit. Free plans are capped at 7 preview channels per project. If your team runs many concurrent PRs, either upgrade to the Blaze plan or use a shorter expires window (e.g. 3d) to keep things from piling up. If you’re already on the paid plan,

Cache your build. The biggest time cost is usually the build step, not the Firebase deploy itself. Using cache: 'npm' on the setup-node action shaves meaningful time off every run.

Build environment variables. If your app needs environment variables at build time, expose them in the workflow's env: block. Preview deployments should point to a staging API, not production.

The bot comment stays clean. The custom github-script step uses a hidden HTML marker () to find and edit the existing comment on each push, rather than posting a new one every time. You get exactly one comment per PR with the always-current preview URL and timestamp.

Conclusion

Getting Firebase Hosting preview deployments working takes more legwork than Vercel or Netlify, but the end result is identical: every PR gets a live URL, every stakeholder can review without a local setup, and cleanup is automatic.

For Peec AI, this changed how we do code reviews. Engineers spend less time on "can you deploy this so I can check?" and more time on the actual review. And as we lean more on AI agents to open PRs, having a visual verification step before merging has become non-negotiable.

The two workflow files are concise enough to drop into any existing Firebase project in under 15 minutes. Give it a try or simply point your AI agent to this article and let it do the rest.

Explaining Docker in Front-End Terms

Ozan — Sun, 09 Aug 2020 23:19:21 +0000

We, front-end developers, are used to dealing with buzzwords and the ever-increasing number of technologies to learn. For years, we’ve been bombarded with library after library — and each of these is combined with numerous frameworks with their contradicting approaches.

If you’ve been in the industry for more than a couple of years, odds are your skin has already started getting thicker from all the fancy words the industry is throwing at us. We hear about Docker, Kubernetes, containerization, and all the others. They all sound like pretty complicated concepts but don’t feel intimated. In this article, I’m going to explain the one you hear the most.

This article is for front-end developers who want to learn what the fuss with Docker is all about and would like to see how they can utilize Docker to improve their daily work.

I don’t expect you to have more knowledge than any average front-end developer would. Mind you, this article is more of a theoretical explanation of Docker’s main features and use cases rather than a practical tutorial about how to implement them.

Terminology

Let’s start with a quick round of terminology before I start explaining everything in detail.

Container: A container is a standard unit of software that packages up code — and all its dependencies — so the application runs quickly and reliably from one computing environment to another.
Image: An image is an unchangeable, static file that includes executable code — and all its dependencies — except the operating system. When an image is executed, it creates containers that run the code inside the image using the files inside that image.
Containerization: The process of encapsulating executable code inside containers and running those containers in a virtual environment, such as the cloud.

Docker is a containerization solution, so we’ll need to start by explaining what containers are and how they work in detail.

So What Are Containers Anyway?

You can think of a container as a kind of a virtual machine or an iframe. Much like an iframe, a container’s purpose is to isolate the processes and code executions inside it from external interference.

In the front-end world, we use iframes** **when we want to isolate external resources from our website for many reasons. Sometimes this is to ensure that there isn’t any unwanted clash of CSS or JavaScript execution; other times it is to enforce a security layer between the host and the imported code.

For example, we place advertisement units inside iframes because they’re often built by separate teams or even separate companies, and deployed independently from the team that manages the host website. In such cases, it is nearly impossible to manage CSS and JS clashes between the two sides.

Another use case would be to enforce security. The PayPal button you see below is placed in an iframe to ensure that the host website cannot access any information you have on your PayPal account. It cannot even click that button for you. So even if the website you’re paying is hacked, your PayPal will be safe as long as PayPal itself is safe.

Docker’s initial use cases are the same. You get to isolate two apps from each other’s processes, files, memory, and more, even if they’re running on the same physical machine. For instance, if a database is running inside a Docker container, another app cannot access that database’s files unless the database container wants it to.

So a Docker container is a virtual machine?

Kind of — but not exactly.

Virtual machines run their own operating systems. This allows you to run macOS, Linux, and Windows all on the same computer, which is amazing but not very performant since the boundaries of these operating systems have to be very precisely defined to prevent possible conflict.

But for most intents and purposes, the containers don’t need completely separate operating systems. They just need isolation.

So what Docker does is use kernel-level isolation on Linux to isolate the resources of an app while giving it the functionalities of the underlying operating system. Containers share the operating system but keep their isolated resources.

That means much better resource management and smaller image sizes. Because once you leave the resource management to Docker, it ensures the containers do not use more RAM and CPU than they need, whereas if you used a virtual machine, you would need to dedicate a specific amount of resources to virtual machines, whether they always use them or not.

There we go: We now know the basics of what Docker is and what Docker containers are. But isolation is just the start. Once we get these performant and isolated containers and a powerful resource manager (Docker) to manage them, we’re able to take it the next step.

Reproducible Containers

Another thing Docker does very well is to give us a way to declaratively rebuild our containers.

All we need is a Dockerfile to define how Docker should build our containers, and we know that we’ll get the same container every time, regardless of the underlying hardware or the operating system. Think about how complicated it is to implement a responsive design across all the desktop and mobile devices. Wouldn’t you love it if it was possible to define what you need and get it everywhere without a headache? That’s what Docker is trying to accomplish.

Before we go into a real-life use case, let’s quickly go over Docker’s life cycle to understand what happens when.

A Docker container’s life cycle

It all starts with a Dockerfile that defines how we want Docker to build the images that the containers will be based on. Note the flow below:

Docker uses Dockerfile to build images. It fetches the files, executes the commands, does whatever is defined in the Dockerfile, and saves the result in a static file that we call an image. Docker then uses this image and creates a container to execute a predefined code, using the files inside that image. So a usual life cycle would go like below:

Let’s unwrap this with a real use case.

Running tests on continuous integration (CI)

A common use case for Docker in front-end development is running unit or end-to-end tests on continuous integration before deploying the new code to the production. Running them locally is great when writing the code, but it is always better to run them on an isolated environment to ensure that your code works everywhere regardless of the computer setup.

Also, we all have that one teammate who always skips the tests and just pushes the code. So a CI setup is also good to keep everyone in check. Below is a very basic container setup that will run your tests when you run the container:

Let’s go over the commands there to understand what is happening.

FROM is used for defining a base image to build on. There are a lot of images already available in the public Docker registry. FROM node:12 goes to the public registry, grabs an image with Node.js installed, and brings it to us.

COPY is used for copying files from the host machine to the container. Remember that the container has an isolated file system. By default, it doesn’t have access to any files on our computer. We run COPY . /app to copy the files from the current directory to the /app directory inside the container. You can choose any target directory. This /app here is just an example.

WORKDIR is basically the cd command we know from UNIX-based systems. It sets the current working directory.

RUN is quite straight forward. It runs the following command inside the container we’re building.

CMD is kind of similar to RUN. It runs the following command inside the container as well. But instead of running it on build time, it runs the command in run time. Whatever command you provide to CMD will be the command that’s going be run after the container is started.

This is all it takes for our Dockerfile to build the template of a container that will set up a Node.js environment and run npm test.

Of course, this use case is just one of the many use cases containers have. In a modern software-architecture setup, most server-side services either already run inside containers or the engineers have plans to migrate to that architecture. Now we’re going to talk about perhaps the most important problem these images help us solve.

Scalability

This is something we front-end developers often overlook. That’s because even though the back-end code runs on only a few servers for all the users, the code we write runs in a separate machine for every user we have. They even buy those machines (personal computers, smartphones, etc.) that they run our code on. This is an amazing luxury that we front-end developers have that the back-end developers do not.

On the server-side of things, scalability is a real issue that requires a lot of planning over the infrastructure architecture and the budget. Cloud technologies made creating new machine instances a lot easier, but it’s still the developer’s job to make their code work on a completely new machine.

That’s where our consistently reproducible containers come in handy. Thanks to the image Docker has built for us, we can deploy as many containers as we want (or we can afford to pay for). No more creating a new virtual machine, installing all the dependencies, transferring the code, setting the network permissions, and many more steps we used to take just to get a server running. We already have all of that done inside an image.

Conclusion

Docker has certainly revolutionized the way we develop and deploy software in the last few years. I hope I’ve been able to shed a light upon the reasons for its popularity.

Containerization and the mindset it brought with it will, without a question, continue to impact how we build software in the upcoming years.

The Right Way to Create Function Components in React With TypeScript

Ozan — Fri, 07 Aug 2020 23:49:11 +0000

Recently, I had this pull request that triggered a short discussion with my teammates. Someone noticed that I used a different method to write types for the function components I wrote whereas there were other methods used in the codebase.

In this bite-sized React article, I'll show you the right way to do it.

Function components from a type-oriented perspective

Functions, in general, are programmatic tools that take some input, process it, and return some output. Function components essentially work the same way. They take properties and convert them into UI elements. You can see below a super basic function component example from reactjs.org using plain JavaScript.

By rewriting this component with TypeScript we aim to make sure that we

use the correct properties with their correct types
get a value of the correct type returned from the function

Common (and wrong) way to type function components

A method I see often that is used by developers is to define only the type for the component's props and ignore the return value. It looks like this:

This is all good and well, considering TypeScript is smart enough to implicitly recognize the return type. But it can fail you if your function component returns different values based on some conditions. Not to mention that it causes friction between various function components.

The right way

The right way to define types for function components would be using React's own type definition React.FunctionComponent or React.FC. In that case, we would refactor the above code to the one below:

This version uses React's own type definition which includes the definition for the return type and also props.children attribute.

Conclusion

Consistency in a codebase is very important. It keeps code changes clean and makes onboarding easier. Try to be consistent in your code conventions and use the standard methods when possible.

If you're interested in more React tips like this, consider subscribing to my weekly newsletter. I promise to make it worth your while.

DEV Community: Ozan

Preview Deployments with Firebase Hosting & GitHub Actions

Why Preview Deployments Matter

What We're Building

Prerequisites

Implementation

1. Setting Up Firebase Hosting

2. Generating a Service Account

3. The Preview Deployment Workflow

4. Cleanup on PR Close

Tips & Gotchas

Conclusion

Explaining Docker in Front-End Terms

Terminology

So What Are Containers Anyway?

So a Docker container is a virtual machine?

Reproducible Containers

A Docker container’s life cycle

Running tests on continuous integration (CI)

Scalability

Conclusion

Further Reading

The Right Way to Create Function Components in React With TypeScript

Function components from a type-oriented perspective

Common (and wrong) way to type function components

The right way

Conclusion