Forem: Michelle Mendoza

How to: Automate Your Next.js Docker App with Render and GitHub Actions

Michelle Mendoza — Mon, 03 Nov 2025 15:47:00 +0000

Serverless deployment like vercel are great for speed and ease of use but they come with limits, your functions can’t stay alive and do background work. If you want to create a simple function that will run every hour, it will be impossible without having to create a workaround which can be frustrating if you just want to implement it within your code.

The solution to these serverless limits is to deploy your application as a Docker image. Unlike serverless environments where your function will stop after execution, a Docker container runs as a persistent server, allowing you to run background functions or scheduled tasks without the risk of termination.

In my previous article, I wrote a tutorial on how to create a leaner, optimized Dockerized image in your Next.js app. While this gives you the leaner and optimized image, your next question is probably “Where do I use this now?”. There’s a lot of options to choose from like AWS which is widely known, but for someone who is just starting to learn how to connect these things, it can be overwhelming.

Which is why in this tutorial, I will introduce Render, a powerful and developer-friendly platform that's a cost-effective alternative to AWS. Its free tier is perfect for deploying and testing the exact production-level workflow that we'll build in this guide.

We will also setup our Github workflow to do these 3 things.

Automatically trigger a docker image build when a branch has been merged to main (or your branch of choice)
Push the docker image to docker registry when it finishes building.
Lastly, when pushing to registry is successful, we will trigger a webhook from render that would automatically deploy the docker image.

This would finally automate your deployment pipeline for your Next.js app.

🚨 Prerequisites

A Dockerized Next.js App: Your app must be Dockerized using the standalone output. (If you haven't done this, you can follow my guide here).
A Docker Hub Account with:
- A public repository created to host your image.
- A Personal Access Token (PAT).
A Manually Pushed Image: As a final setup step, you must manually build and push your first image to your new Docker Hub repository. This is required for Render to find and deploy your image in Step 1.

🛠️ Walkthrough

This guide is a two-part plan. First, we'll do it manually by deploying our existing Docker image to Render. This is a crucial step because Render requires a valid, existing image in order to create our new service. Second, once our service is live, we'll automate the entire process by building a complete CI/CD pipeline in GitHub Actions.

Step 1: Manually Deploying Your Image to Render

Head on to render to create your account. After registering and personalization questions, you can now add a new service.
Within the list, look for webservice.
After selecting webservice, you will see 3 options, but pick the existing image.
This will show you the field to enter your docker image reference that you want to deploy. Ensure that your image is set to public to complete this process without adding your credentials. Once you are done, click connect.
It will now allow you to set your own webservice name and pick a region and payment tier. For this tutorial, we will be using free tier.
Then below the Instance Type section is the environment variables. You can add your environment variables here if you have one. If you not, you can just skip and click deploy web service.
You will be redirected to the logs screen of your webservice where you will see the status of deployment. After the successful deployment, you should be able to visit your deployed app.
Now that the deployment part is done, navigate to the settings. Head to the deploy section and you will see the Deploy Hook. Copy your deploy hook and save it somewhere as we will be using this later when we configure your GitHub CI/CD.

Step 2: Automating your docker image build and deploying to render

After completing the setup on Render, head over to your github repository where your project is located. Go to settings/security/secrets and variables/actions. We need to add the secrets and variables so that our workflow file can use them.
a. Create your repository secrets
First, click on the secrets tab and select “New repository secret”. Then create the following:
- DOCKER_PASSWORD: Paste your Docker PAT (Personal Access Token) here.
- RENDER_WEBHOOK: Paste your Deploy Hook URL that you saved from Render.
b. Create your repository variables
Click the variables tab (right next to secrets) and create the following variables:
- DOCKER_USERNAME: Your Docker Hub username.
- DOCKER_REPO_NAME: The name of your Docker Hub repository (e.g., my-next-app).
Now that the secrets and variables are in place, go to your .yml file (Or if you don’t have one, create it under .github/workflows in your root folder) and apply the following code:
```
name: Build and Deploy Pipeline
run-name: Build & Deploy run triggered by ${{ github.actor }}
on:
pull_request:
types: [closed]
branches:
  - develop
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
  - name: Checkout repository code
    uses: actions/checkout@v5
  - name: Extract docker image metadata
    id: meta
    uses: docker/metadata-action@v5
    with:
      images: ${{vars.DOCKER_USERNAME}}/${{vars.DOCKER_REPO_NAME}}
  - name: Log in to Docker Hub
    uses: docker/login-action@v3
    with:
      username: ${{ vars.DOCKER_USERNAME }}
      password: ${{ secrets.DOCKER_PASSWORD }}
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v3
  - name: Build and push docker images
    uses: docker/build-push-action@v6
            with:
              tags: ${{ steps.meta.outputs.tags }}
              push: true
  - name: Notify webhook
    run: curl -f -X POST ${{ secrets.RENDER_WEBHOOK }}
```
Here are the key takeaway of this .yml file
- on: pull_request: In this .yml file, we have set up a condition that will only trigger once the condition is met. If the pull_request has been merged and closed in the develop branch, then the workflow will run. You are free to set up your own condition here depending on your needs.
- Checkout repository code: Here we clone your repository in the runner’s workspace to allow it to be accessed in the next step.
- Extract docker image metadata: In this step, we will use docker/metadata-action@v5 to generate smart image tags based on the GitHub event. For example, it will tag this build with the develop branch name, which is why our build-and-push step can just use ${{ steps.meta.outputs.tags }} without us hardcoding any tag names.
- Login in to Docker Hub: This step securely logs into Docker Hub using the DOCKER_USERNAME and DOCKER_PASSWORD secrets we created. This is a required step before our workflow is allowed to push the new image to the registry.
- Set up Docker Buildx / Build and push Docker images: In these steps, we configure the Docker Buildx builder and then use it to build the image and push it to the registry. The generated metadata earlier will be used here to define the image tag.
- Notify Webhook: This is the final step that will call the webhook from render. This will allow the automatic deployment of the new image that just got pushed to the registry. Do not forget the -f flag in this step, it will notify you if reaching the webhook fails which will help for debugging.
Now that everything is in place, you can test out the flow by creating a pull request and merging it to your develop. After doing that, head over to the actions tab in your GitHub repository and you should see the CI/CD steps get executed.
Head over to render to verify that a deployment has been triggered and now you just need to wait for it to be completed. Once the deployment is successful, refresh your live app’s URL to see your new changes in production!

And there you have it 🎉 You have successfully automated the build process that would normally take 3 or 4 manual steps to do it. By deploying your Next.js app on a proper server, you can now create functions that can run and operate on intervals without the worry that it will stop.

How did your deployment go? Did you get your pipeline up and running? If you hit any issues or have a pro-tip to share, drop it in the comments below!

How to: Use Next.js Standalone for Leaner Docker Images

Michelle Mendoza — Mon, 20 Oct 2025 12:00:00 +0000

Building a Docker image from a fresh Next.js app can easily bloat your output to over 890+ MB and that size comes at a cost. Bigger images mean slower CI/CD pipelines, thanks to the extra time needed to pull and push them.

But, this can be resolved with the introduction of the standalone feature of Next.js. What standalone does is it creates a .next/standalone folder that packages only the production-critical files and excludes dev dependencies and unnecessary files. In this walkthrough, I will show you how I was able to achieve a 75% reduction in my image’s size by leveraging the standalone feature of Next.js in a multi-stage docker build.

🚨 Prerequisites

An existing Next.js app (Minimum required version is Next.js v12.2.0) or if you don’t have one, you can quickly create with npx create-next-app@latest .
A Docker installed in your machine. (If you currently don’t have one, you can follow this official guide form Docker on how to install)

🛠️ Walkthrough

Step 1: Enable Standalone Output

First, open your next.config.ts file in the root directory of your project and add output: "standalone". This enables your Next.js app to build with only the essential files.

Your next.config.ts file should look like this:

 const nextConfig = {
   // Your other Next.js configurations can go here
   output: "standalone",
 };

 export default nextConfig;

Step 2: Create the Multi-Stage Dockerfile

I’ve prepared a Dockerfile for you to use. In this walkthrough, we’ll be using a multi-stage Docker build. Multi stage builds are a good practice because it creates a smaller and much secure docker image by separating the builder stage and runner stage. Here’s a quick explanation of what a multi-stage build does:

The builder stage: This is where we install all dependencies including dev dependencies and run the build process to generate next/standalone output. Essentially, this stage produces everything that is required for the production build.
The runner stage: This is the part where we create the final, production ready image. It contains only the minimal files needed to serve the app, resulting in a much smaller image. No dev dependencies, no full node modules, strictly only what is needed.

FROM node:20-alpine AS builder
WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .
RUN npm run build

# 2. Runner Stage
# Runner Stage
FROM node:20-alpine AS runner
WORKDIR /app

ENV NODE_ENV=production
ENV HOSTNAME=0.0.0.0
ENV PORT=10000

EXPOSE 10000

COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public

# no entrypoint needed
CMD ["node", "server.js"]

Here are the key takeaways of this Dockerfile:

Cache trick: Running npm install before copying the source code allows you to take advantage of Docker’s layer caching system. If anything changes in your code but not on the dependencies then this part will not run again, saving us some time.
Environment variables: We set environment variables to define the app’s runtime behavior. By adding NODE_ENV=production on your file, you are telling Next.js to run in the optimize production mode. Setting hostname to 0.0.0.0 is essential for a container as it allows it to listen to any outside connection.
The three essential COPY: These set of COPY commands is necessary in order to optimize our build. It is a common pitfall that the next/standalone folder contains everything. But by default, .next/standalone does not include your static and public folder. That is why we have to copy it in order to include it in the final build.

Step 3: Build and Run Your Image

Build your image using this command: docker build -t my-app .
Run your image using this command: docker run -p 3000:10000 my-app

You can now access your app at http://localhost:3000/

(Note: The -p 3000:10000 flag maps your local machine's port 3000 to the containers internal port 10000. This allows you to modify how you access the app without changing the internal configuration.)

📝 Conclusion

And there you have it! By combining a multi-stage build with the standalone feature, we've taken a standard 892mb Next.js image and reduced it to 229mb, a 75% reduction 🤯. While this number may vary depending on the size of your actual project, this proves that you can significantly optimize your image by using this setup, leading to a faster build and deployment times in your CI/CD pipelines.

Comparison:

Without standalone (multistage build)

With standalone (multistage build)

Do you have any tips or tricks to further optimize your docker image build 🤔? Comment down below and share it with the others!

GitHub Actions 101: Your First Step Into CI/CD

Michelle Mendoza — Mon, 06 Oct 2025 11:35:28 +0000

Have you ever noticed job postings that say “Knowledge of CI/CD or GitHub Actions required” or have you come across it and wonder “What does that actually mean?” If so, you’re in the right place.

Continuous Integration and Continuous Deployment (CI/CD) is the practice of automatically building, testing, and deploying code changes, which allows a faster and reliable software release. In real life, it’s like ordering a food from a high-tech food app. You first place your order (push code) then the automated kitchen builds your meal (cooks it), runs a quality check on the food (tests it) and a driver instantly brings your order to your doorstep (deploys it).

If you’re just starting to explore these topics, CI/CD can sound intimidating, but adding your first GitHub Action is easier than you think! In this walkthrough, I’ll show you how to set up a simple GitHub Action so that every time you push your code changes, it will automatically run without your intervention.

🚨 Prerequisites:

This guide assumes you already have a Next.js app in a GitHub repository. If not, you can quickly create with npx create-next-app@latest and push it to GitHub.
If you see a banner in your repository that asks you to add a billing, you will need to input a valid card payment in order to proceed.

🛠️ The Walkthrough

We'll tackle this in four steps: create the file, add the code, push to GitHub, and check the results.

Step 1: Create a folder in your root directory called .github. Once you have that, create a new folder inside it named workflows. This is where we will add our GitHub action file. In this walkthrough, I will name my GitHub action file github-action-demo.yml. You are free to name yours whatever fits your needs.

💡 This directory is where github scans for an available github actions. Any .yml file that you put in here will be detected as a github action.

Step 2: Inside the .yml file we created, we will define a basic github actions workflow configuration.

name: A Simple Hello World
on: [push]
jobs:
  say-hello-job:
    runs-on: ubuntu-latest
    steps:
      - name: Say Hello
        run: echo "Hello, World! I'm running my first GitHub Action!"
      - name: Say Goodbye
        run: echo "Done! This was easy."

Name: This defines the name of the workflow. It allows you to easily identify it in the Github Actions dashboard. You can also use name inside individual steps to describe the action that they are performing.
on: [push] = This defines the event that triggers the action. In this example, the workflow will run everytime you push a code to your repository.
- Github Actions supports many other triggers like (push, pull_request etc.) you can check out the other events in here: Github actions event
Jobs: This is where you will define what your workflow actually does. A github action can have multiple jobs. By default, job runs in parallel unless you specify a dependency, in which case one job will only run after another completes. In my example, we will only have 1 job.
- To avoid confusion:
  - A Job is a set of instructions. For example, "How to bake a cake".
  - Steps are the sequential things that you need to follow in order to have a perfect cake.
    1. "Preheat the oven to 350°F."
    2. "Mix flour, sugar, and eggs."
    3. "Pour batter into pan."
    4. "Bake for 30 minutes."

Step 3: Once you are done, push the file to your GitHub repository. If you have not set up your GitHub repository, refer to this official guide: GitHub Docs QuickStart for repositories

Step 4: Now go to GitHub → The repository of your app and navigate to actions. You should see an action running here (indicated by a spinner icon).

✅ = This means that your GitHub action has run successfully

❌ = This means that your action has failed. Click on it to check the logs for why it failed (this could be an error in your .yml file or an account issue, like the billing notice mentioned in the prerequisites)

And there you have it 🎉. You've just automated your first workflow. You now have a foundational skill that you can build on, such as expanding your configuration to include automated testing and many more.

As a next step, try modifying the .yml file so that it will run on a pull_request that has been closed instead of on push. Comment down below and share how you would achieve that.