
## Introduction

[Docker Compose](https://docs.docker.com/compose/) is a popular tool for defining and managing multi-container applications. It can be used to coordinate shared resources and interfaces between different discrete components so that they can be deployed, updated, and supervised as a unit.

In this guide, we'll walk through how to deploy a Docker Compose application on Koyeb. We'll deploy a GitHub repository that contains a Docker Compose configuration file by building an image with a special Dockerfile based on a [Docker Compose image](https://github.com/koyeb/koyeb-docker-compose). The build process will copy the repository contents to an image with Docker Compose installed and then initialize the applications defined within using the conventional Docker Compose mechanisms.

You can deploy and preview the example application from this guide by clicking the [Deploy to Koyeb button](/docs/build-and-deploy/deploy-to-koyeb-button) below:

[![Deploy to Koyeb](/static/images/deploy/button.svg)](https://app.koyeb.com/deploy?name=docker-compose-on-koyeb&privileged=true&type=git&repository=github.com/koyeb/example-docker-compose&branch=main&builder=dockerfile&dockerfile=Dockerfile.koyeb)

You can consult the [repository on GitHub](https://github.com/koyeb/example-docker-compose) to find out more about the example application that this guide uses.

## Requirements

To successfully follow and complete this guide, you need:

- A [GitHub account](https://github.com/) to host your Docker Composed-based application.
- A [Koyeb account](https://app.koyeb.com) to deploy and run the preview environments for each pull request.

## Steps

To complete this guide and deploy a Docker Compose application, you'll need to follow these steps:

1. [Fork the example Docker Compose repository](#fork-the-example-docker-compose-repository)
2. [Deploy the Docker Compose example application](#deploy-the-docker-compose-example-application)

## Fork the example Docker Compose repository

To demonstrate how to deploy projects that use Docker Compose on Koyeb, we will work with an example repository containing a simple [Flask](https://flask.palletsprojects.com/en/3.0.x/) application. The project defines a Dockerfile to build the main application and includes a `docker-compose.yaml` file that defines how to run the application alongside a [Redis](https://redis.io/) instance to cache results.

To get started, log into GitHub and [fork the example Docker Compose repository](https://github.com/koyeb/example-docker-compose) into your own account. If you'd like to deploy the application without any changes, you can skip this step and deploy from Koyeb's public repository in the next step instead.

The main application code is found in the `app.py` file, but for our purposes, the Docker-related files are more interesting. These three files define how to build and run the necessary images and containers: `Dockerfile`, `docker-compose.yaml`, and `Dockerfile.koyeb`.

The `Dockerfile` is very standard and doesn't require any special design for Koyeb:

```dockerfile
FROM python:3.7-alpine

WORKDIR /code
ENV FLASK_APP=app.py
ENV FLASK_RUN_HOST=0.0.0.0
RUN apk add --no-cache gcc musl-dev linux-headers
COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt

EXPOSE 5000
COPY . .
CMD ["flask", "run"]
```

It packages up the application code into a container image and configures it to run on port 5000.

Likewise, the `docker-compose.yaml` file doesn't require any special consideration:

```yaml
services:
  web:
    build: .
    ports:
      - '${PORT}:5000'
  redis:
    image: 'redis:alpine'
```

The compose file automatically builds the above Dockerfile as needed. It defines a two container application setup using the image from the build above and as well as a Redis container. It runs the application container on the port defined by the `PORT` environment variable, using port 5000 as a fallback.

The only file required to bridge the gap between a standard Docker Compose configuration and a Koyeb deployment is the `Dockerfile.koyeb` file:

```dockerfile
FROM koyeb/docker-compose

COPY . /app
```

This file will be the primary director of the Koyeb build process. It creates a new image based on the [Koyeb Docker Compose image](https://hub.docker.com/r/koyeb/docker-compose) (check out the [repository for the image](https://github.com/koyeb/koyeb-docker-compose) for additional details). The only other instruction in this Dockerfile is to copy the entire repository to the `/app` directory within the image.

This works because the Koyeb Docker Compose image runs a Docker daemon that can be used to spawn containers. The image uses Docker Compose to read and apply the `docker-compose.yaml` file, which will build the main application image and then run a container from it in coordination with the Redis container, as outlined above.

## Deploy the Docker Compose example application

Now that you understand how the Docker Compose example works, you can deploy it to Koyeb to validate that the process works as expected.

To get started, open the [Koyeb control panel](https://app.koyeb.com/) and complete the following steps:

1. On the **Overview** tab, click **Create Web Service**.
2. Select **GitHub** as the deployment method.
3. In the GitHub repository list, either select your fork of the Docker Compose repository from your account's repository list or enter the public example repository in the **Public GitHub repository** field: `https://github.com/koyeb/example-docker-compose`.
4. In the **Builder** section, select **Dockerfile**. Click the **Override** toggle to enable the **Dockerfile location** field. In the field, type `Dockerfile.koyeb`.
5. Enable the **Privileged** toggle.
6. Choose a name for your App and Service, for example `koyeb-docker-compose`, and click **Deploy**.

Koyeb will clone the GitHub repository and use the `Dockerfile.koyeb` file to build a new container image for the project. Once the build is complete, a container will be started from the image to run Docker Compose. The Docker Compose process works with a Docker daemon to build or pull the necessary images and start the associated containers.

Once the deployment is healthy, visit your Koyeb Service's subdomain (you can find this on your Service's detail page) to connect. It will have the following format:

```
https://<YOUR_APP_NAME>-<KOYEB_ORG_NAME>.koyeb.app
```

You should see the example application's response:

```
Hello World! I have been seen 1 times.
```

The number in the counter will increment as you refresh or visit the page from other devices. The persistence is provided by the Redis container, indicating that both components defined in the `docker-compose.yaml` file are operating as expected.

## Conclusion

In this tutorial, we demonstrated how to use the [Koyeb's Docker Compose image](https://hub.docker.com/r/koyeb/docker-compose) to bootstrap projects that rely on Docker Compose to orchestrate containers. With a two line `Dockerfile.koyeb` file, the Koyeb build process can build a container that runs Docker Compose for your applications, building the images and spawning the containers defined by your configuration.

This method of running Docker Compose-oriented workloads makes it straightforward to get existing projects up-and-running quickly without much modification to your existing repositories. You can use your existing orchestration tool to get started and then migrate to running independent containers on the platform when you want additional control and performance.


Deploy your Docker Compose applications on high-performance infrastructure across global locations in seconds. No credit card required.

Global and Serverless Docker Compose Apps

In this tutorial, we demonstrate how to deploy a Docker Compose project to Koyeb from a GitHub repository.

Deploy Apps Using Docker Compose on Koyeb


## Introduction

Preview environments are dynamic, temporary environments deployed from specific branches of your application in response to repository events. They are a simple way to test and collaborate on versions of your applications before deploying to production.

In this tutorial, we will explain how to automatically deploy your application using [GitHub Actions](https://github.com/features/actions) each time a pull request is made for your GitHub repository.

By the end of this guide, you will have:

- A workflow that automatically deploys the branches from your pull requests.
- A workflow that automatically deletes the preview environment when the pull request is merged or closed.

## Requirements

To successfully follow and complete this guide, you need:

- A [GitHub account](https://github.com/) to host your repositories and configure the pull request preview integration.
- A [Koyeb account](https://app.koyeb.com) to deploy and run the preview environments for each pull request.

## Steps

To complete this guide and configure preview environments to your project, you need to follow these steps:

1. [Fork the example application](#fork-the-example-application)
   - [Understanding the preview environment deployment workflow](#understanding-the-preview-environment-deployment-workflow)
   - [Understanding the preview environment cleanup workflow](#understanding-the-preview-environment-cleanup-workflow)
2. [Create a Koyeb personal access token](#create-a-koyeb-personal-access-token)
3. [Add the Koyeb personal access token as a repository secret](#add-the-koyeb-personal-access-token-as-a-repository-secret)
4. [Test the preview environment deployment](#test-the-preview-environment-deployment)
5. [Test the preview environment cleanup](#test-the-preview-environment-cleanup)

## Fork the example application

To demonstrate how to set up preview environments for a GitHub repository, we'll work with an example repository containing a basic Node.js web app built with [Express](https://expressjs.com/). The application responds to requests with a simple "hello world" message.

To get started, visit the [preview environments example repository](https://github.com/koyeb/example-preview-environments) and fork it into your account.

The main application code is found in the `app.py` file, but for our purposes, the GitHub Actions workflow files are more relevant. In the `.github/workflows` directory are two files: `deploy-preview.yaml` and `cleanup-preview.yaml`.

### Understanding the preview environment deployment workflow

The `deploy-preview.yaml` file contains the following contents:

```yaml
name: Deploy preview environment on Koyeb

on:
  pull_request:
    branches:
      - main

jobs:
  deploy_preview:
    runs-on: ubuntu-latest
    concurrency:
      group: '${{ github.head_ref }}'
      cancel-in-progress: true
    steps:
      - name: Install and configure the Koyeb CLI
        uses: koyeb-community/koyeb-actions@v2
        with:
          api_token: '${{ secrets.KOYEB_API_TOKEN }}'

      - name: Build and deploy the application to Koyeb
        uses: koyeb/action-git-deploy@v1
        with:
          git-branch: ${{ github.head_ref }}
          app-name: 'expressjs-pr-${{ github.head_ref }}'
          service-name: ${{ github.head_ref }}
          service-ports: '3000:http'
          service-routes: '/:3000'
```

Let's take a look at what this configuration describes.

After naming the workflow, the `on.pull_requests.branches` structure dictates that this workflow should only automatically trigger for pull requests events against the repositories "main" branch. If your project had a different primary branch or if you wanted to act on pull requests targeting additional branches, you could modify this value.

Next, in the `jobs` array, there's a single job called `deploy_preview` that runs the deployment. Inside it specifies that the job should be run by a Ubuntu container and it sets up a concurrency group to make sure that only one workflow is run at a time.

The actual workflow steps are fairly simple. First, it installs the [Koyeb CLI](/docs/build-and-deploy/cli/installation) using the [`koyeb-community/koyeb-actions` action](https://github.com/koyeb-community/koyeb-actions). You may notice that this step references a secret called `KOYEB_API_TOKEN`. You will have to configure this for your fork later on.

The second step builds and deploys the pull request branch on Koyeb using the [`koyeb/action-git-deploy` action](https://github.com/koyeb/action-git-deploy). The pull request branch name can be found in the `github.head_ref` context object. We use this to specify the branch to deploy and to name the Koyeb App and Service. The remaining lines configure the port and routing that the application expects.

To summarize, this workflow will automatically run whenever a pull request is created, re-opened, or updated. When triggered, it will deploy a new preview environment with the pull request branch.

### Understanding the preview environment cleanup workflow

The `cleanup-preview.yaml` file contains the following contents:

```yaml
name: Cleanup preview environments on Koyeb

on:
  pull_request:
    types:
      - closed

jobs:
  cleanup_preview:
    runs-on: ubuntu-latest
    steps:
      - name: Install and configure the Koyeb CLI
        uses: koyeb-community/koyeb-actions@v2
        with:
          api_token: '${{ secrets.KOYEB_API_TOKEN }}'

      - name: Cleanup Koyeb application
        uses: koyeb/action-git-deploy/cleanup@v1
        with:
          app-name: 'expressjs-pr-${{ github.head_ref }}'
```

This workflow is fairly similar to the last one. After naming the workflow, it targets pull requests events, but unlike last time, this workflow only triggers when a pull request is closed.

The `cleanup_preview` job installs the Koyeb CLI as before and again uses the `KOYEB_API_TOKEN` to authenticate. Afterwards, it uses the [`koyeb/action-git-deploy/cleanup` action](https://github.com/koyeb/action-git-deploy#cleaning-up-services) to delete the Koyeb app. We pass it the same App name construction used in the deployment file so that it can target the correct App.

In summary, this workflow will automatically run whenever a pull request is merged in or closed. When triggered, it will delete the preview environment based on the branch name.

## Create a Koyeb personal access token

In order to deploy and manage resources on Koyeb, your GitHub repository needs a token that authorizes it to do so.

To get started, in the [Koyeb control panel](https://app.koyeb.com/), click your user icon in the top right corner and click [**Account settings**](https://app.koyeb.com/user/settings). Click the [**Personal Access Tokens**](https://app.koyeb.com/user/settings/api) item in the left-hand menu.

Give your new token a recognizable name and a useful description and the click **Create API Access Token**. Copy the token value and store it in a safe location so that we can use it in the next step. This value cannot be retrieved later, so the token will need to be recreated if you lose it.

## Add the Koyeb personal access token as a repository secret

In your fork of the example application on GitHub, click the **Settings** tab and select **Secrets and variables** and then **Actions**. Click **New repository secret** to add a new secret.

Fill in the secret creation form with the following:

- **Name:** `KOYEB_API_TOKEN` (must match the secret value from the workflow files)
- **Value:** The Koyeb personal access token you generated as the secret value.

Click **Add secret** when you are finished.

Next, click the **Actions** tab for the forked repository. You'll see a disclaimer since about how GitHub Actions have been disabled for the fork until you evaluate the workflow files:

![Enable GitHub Actions](/static/images/tutorials/koyeb-preview-environments/enable-github-actions.png)

If you're comfortable running the workflow files defined in the repository, click **I understand my workflows, go ahead and enable them**. GitHub Actions can now run on your fork.

## Test the preview environment deployment

With the workflow files present and the Koyeb API token configured, your forked repository now has everything it needs to deploy and manage preview environments for pull requests.

To test the preview environment workflow, clone your fork from GitHub onto your local computer:

```bash
git clone git@github.com:<YOUR_GITHUB_ORG>/example-preview-environments.git
```

Move into the repository directory and switch to a new branch for your changes:

```bash
cd example-preview-environments
git switch -c change_message
```

Open the main `app.js` application file and modify the message to something different:

```js
const express = require('express')
const app = express()
const port = process.env.PORT || 3000

app.get('/', (req, res) => {
  res.send('<h1>Hello, world!</h1>') // [!code --]
  res.send('<h1>Hello, from a different branch!</h1>') // [!code ++]
})

app.listen(port, () => {
  console.log(`App listening on port ${port}`)
})
```

Save and close the file when you're finished. Next, add and commit your changes and push them up to your fork:

```bash
git add :/
git commit -m 'Change greeting message'
git push origin change_message
```

In your fork on GitHub, open a new pull request based on the new branch:

**Note:** In this scenario, remember to make the pull request against your own `main` branch instead of the `koyeb` repository you forked from.

![Open pull request on GitHub](/static/images/tutorials/koyeb-preview-environments/open-pr.png)

After a moment, you should see the GitHub Action beginning to work in the checks at the bottom of the pull request:

![Pull request checks](/static/images/tutorials/koyeb-preview-environments/pull-request-checks.png)

If you click the **Details** link associated with the check or view the **Actions** tab at the top of the repository, you can track the deployment through the GitHub Actions interface.

![GitHub deploy action](/static/images/tutorials/koyeb-preview-environments/github-deploy-action.png)

If you visit the [Koyeb control panel](https://app.koyeb.com/), you should see a new Koyeb App and Service being deployed for the pull request branch:

![Koyeb new PR deployment](/static/images/tutorials/koyeb-preview-environments/koyeb-new-pr-deployment.png)

You can follow along through the build and deployment processes to see the progress. When the deployment is live, click the **Public URL** for the service:

![Koyeb public URL](/static/images/tutorials/koyeb-preview-environments/koyeb-public-url.png)

You should see the updated message text from the pull request branch:

![Updated application message](/static/images/tutorials/koyeb-preview-environments/updated-application-message.png)

The preview environment successfully built and deployed the pull request branch.

## Test the preview environment cleanup

Next, you can test the preview environment cleanup workflow.

In your GitHub fork, close or merge the pull request (either will trigger the workflow). If you click the **Actions** tab of the repository, you should see the cleanup workflow being processed:

![Cleanup workflow processing](/static/images/tutorials/koyeb-preview-environments/cleanup-workflow-processing.png)

If you visit the [Koyeb control panel](https://app.koyeb.com/), you should see the Koyeb App and Service for your pull request branch being deleted automatically:

![Koyeb app deletion](/static/images/tutorials/koyeb-preview-environments/koyeb-app-deletion.png)

This confirms that the cleanup workflow is able to spin down our preview environments correctly.

## Conclusion

In this tutorial, we showed how you can combine GitHub Actions and Koyeb to automatically deploy and manage preview environments based on your project's pull requests. We covered how to design workflow files that target pull request events on GitHub, how to pass the correct information to Koyeb to deploy the appropriate branches, and how to delete the resources once the pull request is closed.

By using and expanding on these workflows, you can easily integrate preview environments for your pull requests into your CI/CD pipelines. This helps you test all changes in a realistic environment prior to merging them into your main production branch. You can use this as a basis for building more sophisticated implementations that comment on the pull request thread with the preview environment details, notify slack channels, and more.


Run your staging and production environments on top-notch infrastructure in your choice of global locations. No credit card required.

Best-in-class infrastructure for your staging and prod envs

This guide explains how to automate deployments on Koyeb when you create a new pull request on GitHub repository using GitHub Actions.

Deploy Preview Environments on Koyeb for GitHub Pull Requests


## Introduction

GitHub Actions are a great way to automate parts of your development and release workflows by running jobs in response to repository events. While native runners are available to execute these jobs on GitHub, often self-hosting your runners can provide a better price-performance ratio.

In our [guide on running GitHub runners on Koyeb](/tutorials/deploying-github-actions-self-hosted-runners-on-koyeb), we demonstrated how to configure Koyeb GitHub runners to execute GitHub Actions for an example application. This configuration lets us choose the appropriate performance profile for our tasks while saving money compared to the higher-tier native GitHub runners. One problem, however is that you don't necessarily need the runners operating at all times. When no jobs are being run, this needlessly increases costs without providing any value.

In this guide, we'll show you how to improve the Koyeb GitHub runner configuration by taking advantage of a companion project, [`koyeb-github-runner-scheduler`](https://github.com/koyeb/koyeb-github-runner-scheduler). Instead of deploying a continuously-running, high-performance GitHub runner on Koyeb directly, you can deploy a smaller scheduler app that dynamically spins up GitHub runners as necessary to complete jobs. The Koyeb Scheduler can be used to dispatch jobs for either an entire organization or for a specific repository. We'll be configuring our Scheduler to run for a specific repository in this demonstration.

## How the scheduler works

The scheduler is a small application that you can deploy on Koyeb to manage GitHub Actions job requests. It listens for jobs from GitHub and dispatches them to an appropriate runner on Koyeb. If a runner is not available, the scheduler provisions a new one and hands the job over once it is running. It automatically spins down the GitHub runners that have been idle for a configurable period of time.

This system allows you to run a small, always-on application and dynamically provision high-performance resources to execute your jobs when needed. You can configure the scheduler to receive requests from an entire organization or a single repository.

The basic order of operations that occurs when a GitHub Action, like a unit test, is triggered is as follows:

1. Your GitHub repository sends a webhook to the Koyeb Scheduler.
2. The Koyeb Scheduler checks if an appropriate runner is available to run the job. If one is not found, it initiates a new runner instance on Koyeb, tailored to your pre-defined size and geographic location requirements.
3. The Koyeb Scheduler dispatches the job to the matching GitHub runner.

After a pre-configured timeout, the Koyeb Scheduler shuts down the runner if no new jobs are initiated. This timeout is adjustable, offering you further control over cost and performance.

## Requirements

To follow along with this guide, you'll need:

- A [Koyeb account](https://app.koyeb.com/auth/signup) to deploy and run the Koyeb Scheduler.
- A [GitHub account](https://github.com/) to store your repositories and configure the GitHub Actions behavior.

## Steps

In this guide, we'll deploy the Koyeb Scheduler on Koyeb and configure GitHub to pass GitHub Actions jobs to it through the following steps:

1. [Clone the Koyeb GitHub runner scheduler demo application](#clone-the-koyeb-git-hub-runner-scheduler-demo-application)
2. [Create a GitHub personal access token](#create-a-git-hub-personal-access-token)
3. [Create a Koyeb personal access token](#create-a-koyeb-personal-access-token)
4. [Deploy the Koyeb GitHub Scheduler on Koyeb](#deploy-the-koyeb-git-hub-scheduler-on-koyeb)
5. [Configure a webhook for the GitHub repository](#configure-a-webhook-for-the-git-hub-repository)
6. [Test the Scheduler](#test-the-scheduler)

## Clone the Koyeb GitHub runner scheduler demo application

To get started, visit the [Koyeb GitHub runner scheduler demo application repository](https://github.com/koyeb/koyeb-github-runner-scheduler-demo) and clone it to your account.

The repository contains the same code from the [Koyeb GitHub runner demo application](https://github.com/koyeb/koyeb-github-runner-demo), but with a different GitHub Actions definition:

```yaml
name: Run unittests

on:
  push:
    branches:
      - '*'

jobs:
  run-tests-in-frankfurt:
    runs-on: koyeb-fra-small
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Run tests
        run: |
          echo "Hello from a Small Koyeb Instance in Frankfurt!"
          python -m unittest
```

Rather than targeting a runner based on the `koyeb-runner` label, this action uses the format expected by the Scheduler:

```
koyeb-<REGION>-<INSTANCE_TYPE>
```

You can find the available values for [regions](/docs/reference/regions#core-regions) and [instance types](/docs/reference/instances#instance-types) in the Koyeb documentation. This allows the Scheduler to spin up different runners of various sizes in different locations depending on what the job requires.

## Create a GitHub personal access token

Before we can deploy the Koyeb Scheduler on Koyeb, we need to generate a new personal access token in GitHub.

On GitHub, click your user icon in the top right corner and go to [**Settings**](https://github.com/settings/profile). From there, go to [**Developer settings**](https://github.com/settings/apps) at the bottom of the left hand navigation menu and select [**Fine-grained tokens**](https://github.com/settings/tokens?type=beta) under the **Personal access tokens** section. Click [**Generate new token**](https://github.com/settings/personal-access-tokens/new) to access the token creation form.

Give the token a name and set the expiration date as you'd like. In the **Repository access** section, choose **Only select repositories** and then choose the project repository. In this tutorial, we focus on configuring the token for a single repository, but you can check the [`koyeb-github-runner-scheduler` repository](https://github.com/koyeb/koyeb-github-runner-scheduler#repository-or-organization-runner) for instructions on configuring for an entire organization.

In the **Permissions** section, expand the **Repository permissions** category. In the drop down menu for the **Administration** permission, select **Read and write**.

When you are finished, click **Generate token**. Copy the token value and store it in a safe location so we can use it later. This value cannot be retrieved later, so the token will have to be recreated if you lose it.

## Create a Koyeb personal access token

In order to spin up resources on your Koyeb, the Koyeb Scheduler needs a token that authorizes it to do so.

To get started, in the [Koyeb control panel](https://app.koyeb.com/), click your user icon in the top right corner and click [**Account settings**](https://app.koyeb.com/user/settings). Click the [**Personal Access Tokens**](https://app.koyeb.com/user/settings/api) item in the left-hand menu.

Give your new token a recognizable name and a useful description and then click **Create API Access Token**. Copy the token value and store it in a safe location so that we can use it in the next step. This value cannot be retrieved later, so the token will need to be recreated if you lose it.

## Deploy the Koyeb GitHub Scheduler on Koyeb

Now that we have the GitHub and Koyeb tokens, we can deploy the [Koyeb GitHub Scheduler](https://hub.docker.com/r/koyeb/github-runner-scheduler) to our account.

Click the "Deploy to Koyeb" button to configure the deployment. Be sure to alter the `GITHUB_TOKEN`, `KOYEB_TOKEN`, and `API_SECRET` environment variables to reflect your own values:

[![Deploy to Koyeb](/static/images/deploy/button.svg)](https://app.koyeb.com/deploy?name=github-runner-scheduler&type=docker&image=docker.io/koyeb/github-runner-scheduler&env[GITHUB_TOKEN]=CHANGE_ME&env[KOYEB_TOKEN]=CHANGE_ME&env[API_SECRET]=CHANGE_ME&env[MODE]=repository&env[DISABLE_DOCKER_DAEMON]=true&ports=8000;http;/)

If you'd like to deploy manually, on the **Overview** tab of the [Koyeb control panel](https://app.koyeb.com/), click **Create Web Service** to get started:

1. Select **Docker** as the deployment method.
2. Enter `github.io/koyeb/github-runner-scheduler` as the **Docker image**.
3. In the **Environment variables** section, create the following variables:
   - `GITHUB_TOKEN`: The personal access token you generated on GitHub.
   - `KOYEB_TOKEN`: The personal access token you generated on Koyeb.
   - `API_SECRET`: A random secret used to authenticate requests from GitHub webhooks. You will need to provide the same value when configuring the webhook on GitHub afterwards. A good way to generate this secret is by using the output of this command: `openssl rand -base64 30`.
   - `MODE`: Set this to `repository` since we're configuring the Scheduler for a single repository (if we were [configuring for an organization](https://github.com/koyeb/koyeb-github-runner-scheduler#repository-or-organization-runner), this would instead be set to `organization`).
     Additionally, you may also want to set the following optional variables depending on your needs:
   - `DISABLE_DOCKER_DAEMON`: Set this to `true` if you do not need to start a Docker daemon to run your jobs. Disabling this will reduce both the startup time and memory usage for your runners. If you're using the Python application from the previous guide, you can safely set this to `true`.
   - `RUNNERS_TTL`: You can optionally set this to the number of minutes after the most recent job that you want to wait before spinning down the GitHub runners. The default behavior is to wait 120 minutes (2 hours).
4. When you are ready, click **Deploy** to start up the Koyeb GitHub Scheduler on your account.

On the Service page, copy the **Public URL** for your Scheduler. You'll need it when configuring the webhook in the next step.

## Configure a webhook for the GitHub repository

Now that the Scheduler is up and running, you can finish the integration by configuring a webhook for the repository.

On your GitHub repository page, click the **Settings** tab and select **Webhooks**. Click **Add webhook** to begin the configuration.

Paste the public URL you copied from your Koyeb Scheduler into the **Payload URL** field. For the **Content type**, select `application/json`. In the **Secret** field, paste the same secret you used as the value for the `API_SECRET` environment variable when deploying the Scheduler.

In answer to the question **Which events would you like to trigger this webhook?**, choose **Let me select individual events.** In the list that follows:

- **De-select** the **Pushes** item
- **Select** the **Workflow jobs** item

Click **Add webhook** when you are finished.

## Test the Scheduler

Once you push your new changes to GitHub, the workflows should begin to execute using the new Scheduler system.

If you visit the runtime logs of the Koyeb GitHub Scheduler app in the Koyeb control panel, there should be messages indicating that a new job has been received from GitHub. They'll look for GitHub runners with the appropriate label and, finding none, will provision the new instance:

![Koyeb Scheduler event logs](/static/images/tutorials/koyeb-github-scheduler/koyeb-scheduler-logs.png)

If you go back to the main [Koyeb Apps list](https://app.koyeb.com/), a new GitHub runner Service should be in the process of deploying in Frankfurt:

![Koyeb new GitHub runner services](/static/images/tutorials/koyeb-github-scheduler/koyeb-new-runner-services.png)

Next, visit the **Actions** tab in your GitHub repository. You should see the test run history. If you click through the jobs, you'll a new job defined by your workflow:

![GitHub Actions test run results](/static/images/tutorials/koyeb-github-scheduler/github-actions-results.png)

The GitHub Actions were successfully executed by runners that the Scheduler dynamically provisioned. After the idle timeout is reached, the Scheduler will delete the runner, saving you money when it is not being used.

## Conclusion

In this guide, we improved a self-hosted GitHub runners set up by replacing our always-on GitHub runners with Koyeb Scheduler, a small application that can dynamically provision runners as needed. We configured the GitHub repository to send webhook messages to the Scheduler when GitHub Actions jobs occur and modified the workflow file to use the Scheduler label syntax.

By replacing the GitHub runner with the Scheduler, we are able to more easily control costs by only running instances when required by our GitHub jobs. By adjusting the time-to-live value for runners, we can confidently use higher performance instances without having to worry about paying for unnecessary usage.

To learn more about using the Koyeb Scheduler for your projects, check out the [Koyeb Scheduler repository on GitHub](https://github.com/koyeb/koyeb-github-runner-scheduler) and the [Scheduler image on Docker Hub](https://hub.docker.com/r/koyeb/github-runner-scheduler).


In this tutorial, we'll demonstrate how to configure the Koyeb GitHub Scheduler to dynamically provision GitHub Action runners on Koyeb.

Dynamically Start GitHub Action Runners on Koyeb


## Introduction

[Grafana](https://grafana.com/) is a data monitoring and observability platform that allows you to collect and understand data from tools used throughout your organization. Grafana makes it easy to query data from many different sources, build graphs and dashboards to track changes in metrics, import and analyze logs, and send alerts when customizable thresholds are passed. With a large ecosystem of plugins and complementary systems, Grafana can be extended to work with whatever data is most important to you.

In this guide, we will go over how to set up a Grafana instance on [Koyeb](/) to monitor infrastructure health and essential production resources. We will deploy Grafana using the project's official [Docker image](https://hub.docker.com/r/grafana/grafana), backed by a PostgreSQL database.

You can deploy and preview Grafana as configured in this guide using the [Deploy to Koyeb](/docs/build-and-deploy/deploy-to-koyeb-button) button below:

[![Deploy to Koyeb](/static/images/deploy/button.svg)](https://app.koyeb.com/deploy?name=grafana&type=docker&image=docker.io/grafana/grafana&env[GF_SERVER_HTTP_PORT]=8000&env[GF_DATABASE_TYPE]=postgres&env[GF_DATABASE_URL]=REPLACE_ME&env[GF_DATABASE_SSL_MODE]=require&env[GF_INSTALL_PLUGINS]=grafana-github-datasource&ports=8000;http;/)

**Note:** Remember to replace the value of the `GF_DATABASE_URL` environment variables with the connection URL for your own database.

## Requirements

To follow along with this guide, you will need to create accounts with the following services. Each of these services offers a free tier that you can use to get started:

- **[Koyeb](https://app.koyeb.com/):** We will use Koyeb to deploy, run, and scale the Ghost process.
- **[Aiven](/docs/integrations/databases/aiven):** We will use Aiven to provision a PostgreSQL database to store and manage Grafana's configuration information.
- **[GitHub](https://github.com/):** We will use a GitHub account as a data source to demonstrate querying and visualizations in Grafana.

## Steps

This guide will cover how to deploy a Grafana instance to Koyeb through the following steps:

1. [Create a PostgreSQL database with Aiven](#create-a-postgre-sql-database-with-aiven)
2. [Deploy Grafana to Koyeb](#deploy-grafana-to-koyeb)
3. [Start using Grafana](#start-using-grafana)
   - [Setting up the admin account](#setting-up-the-admin-account)
   - [Creating a GitHub personal access token](#creating-a-git-hub-personal-access-token)
   - [Connecting Grafana with GitHub](#connecting-grafana-with-git-hub)
   - [Testing querying and visualizations with the GitHub data source](#testing-querying-and-visualizations-with-the-git-hub-data-source)

## Create a PostgreSQL database with Aiven

Before we deploy Grafana, we need to provision a database where it can store its data.

Grafana can use a number of different types of relational databases, including an embedded SQLite database by default. In this guide, we will use an external PostgreSQL database to decouple our data from the running service instance, allowing it to scale and redeploy without problems. We will use Aiven as our PostgreSQL provider since they have a free tier that is more than enough for our purposes.

To create a new PostgreSQL database, log into your [Aiven account](https://console.aiven.io/login). In the Aiven console, follow these steps to create a new PostgreSQL database:

1. Click the **Create service** button.
2. On the next screen, select **PostgreSQL**.
3. Select **Free plan** to get started using a free database.
4. Select the region to deploy your database. In this guide, we will select `aws-eu-west-3` to demonstrate deploying resources in Europe, but you should choose the region closest to your users.
5. Ensure that the `Free-1-5gb` plan is selected.
6. Choose a name for your PostgreSQL database. We will use `grafana-postgresql` for this guide.
7. Click the **Create free service** button to begin provisioning your new database.

The following screen will show the connection details for your new database. Click on the copy icon associated with the **Service URI** to copy the connection string and save it to a safe place for later reference. We will use this value when we configure Grafana so that it can connect to and authenticate with the database.

## Deploy Grafana to Koyeb

Now that you have the database connection string, you have everything you need to configure and deploy Grafana to Koyeb.

Begin by logging into your [Koyeb account](https://app.koyeb.com/auth/signin). Follow these steps to deploy the default [Grafana container image](https://hub.docker.com/r/grafana/grafana) to the platform:

1. On the **Overview** tab of the [Koyeb console](https://app.koyeb.com/), click **Create Web Service**.
2. Select **Docker** as your deployment method.
3. Set the **Docker image** to `docker.io/grafana/grafana`. Optionally append an [image tag](https://hub.docker.com/r/grafana/grafana/tags) if you'd like to choose a specific image variant.
4. In the **Environment variables** section, click **Add variable** to create the following variables:
   - `GF_SERVER_HTTP_PORT`: Set to 8000. This is the variable Grafana uses to specify the port to listen on.
   - `GF_DATABASE_TYPE`: Set to `postgres`.
   - `GF_DATABASE_URL`: Set to the connection URI you copied from Aiven.
   - `GF_DATABASE_SSL_MODE`: Set to `require` to force Grafana to connect to the database with encryption.
   - `GF_INSTALL_PLUGINS`: Set to `grafana-github-datasource` to install the GitHub data source.
5. Choose a name for your App and Service and click **Deploy**.

Koyeb will pull the Grafana container image from Docker Hub and use it to provision a new container. The Grafana process will start up, connect to and initialize the database, and begin listening on the port specified in the configuration.

## Start using Grafana

Once Grafana is up and running, you can visit your Koyeb Service's subdomain (you can find this on your Service's page) to connect. It will have the following format:

```
https://<YOUR_APP_NAME>-<KOYEB_ORG_NAME>.koyeb.app
```

### Setting up the admin account

You will be redirected to the Grafana login page:

![Grafana login page](/static/images/tutorials/grafana/grafana_login_page.png)

Enter `admin` for both the username and password to continue.

Next, you'll be asked to choose and confirm a new password for the admin account:

![Grafana change admin password](/static/images/tutorials/grafana/grafana_change_password.png)

Once you've provided a new password, you will be redirected to the default Grafana landing page:

![Grafana landing page](/static/images/tutorials/grafana/grafana_landing_page.png)

From here, you can modify settings and begin configuring your instance.

### Creating a GitHub personal access token

To test that Grafana can connect to and visualize data from a data source, we will connect our instance with a GitHub account.

To do this, you'll first need to create a GitHub personal access token to authenticate to your account.

On GitHub, visit the **Settings** and click the **Developer settings** tab on the left-hand sidebar. Next, open the **Personal access tokens** menu and click **Tokens (classic)**.

To create a new token, click the **Generate new token** button and select **Generate new token (classic)** from the drop down menu. Add a name for the new token and adjust the expiration date to your preference.

In the scopes selection, select the following items:

- `repo`
- `read:packages`
- `read:user`
- `user:email`

Click the **Generate token** button when you're done. Copy the generated token and save it to use for the next step.

### Connecting Grafana with GitHub

Now that we have a GitHub personal access token, we can configure the GitHub data source plugin for Grafana to visualize our data.

In your Grafana dashboard, open the side menu and select **Connections**. In the connections menu, view the **Data sources** page and then click the **Add data source** button:

![Grafana add data source](/static/images/tutorials/grafana/grafana_add_data_source.png)

On the next page, use the filter to search for "GitHub" and then select the plugin to continue:

![Grafana select GitHub source](/static/images/tutorials/grafana/grafana_select_github.png)

On the page that follows, name the connection so that you can identify this connection accurately. In the **Service Account Access** section, paste your GitHub personal access token into the **Access Token** field.

Click the **Save & test** button to validate the connection and save your configuration:

![Grafana save and test plugin](/static/images/tutorials/grafana/grafana_save_and_test.png)

If everything goes well, you should see a message that the data source is working.

### Testing querying and visualizations with the GitHub data source

Now that Grafana is connected to your GitHub account, you can query the data that the GitHub API exposes to visualize changes in repositories, organizations, and more. You can query information about your own repositories as well as any public repositories.

To get started, select **Dashboards** from the side menu, click the **New** button, and select **New Dashboard**:

![Grafana new dashboard](/static/images/tutorials/grafana/grafana_new_dashboard.png)

On the next page click the **Add visualization** button:

![Grafana add visualization](/static/images/tutorials/grafana/grafana_add_visualization.png)

Select your configured GitHub source as the data source:

![Grafana select data source](/static/images/tutorials/grafana/grafana_select_data_source.png)

Towards the bottom of the page, you can configure your query. For this example, we'll use the following values:

- Query Type: Pull Requests
- Owner: `koyeb`
- Repository: `koyeb-cli`
- Query: (blank)
- Time Field: `MergedAt`

Next, above the graph area, adjust the time frame from "Last 6 hours" to "This year so far":

![Grafana adjust time frame](/static/images/tutorials/grafana/grafana_adjust_time.png)

You should see the query run and the visualization populate.

Next, in the side bar, name the visualization "Koyeb CLI PRs" and click the **Apply** button:

![Grafana finalize visualization](/static/images/tutorials/grafana/grafana_finalize_visualization.png)

You should now see the new visualization on the dashboard:

![Grafana dashboard with visual](/static/images/tutorials/grafana/grafana_dashboard_with_visual.png)

Click the save icon in the top row to name your new dashboard. Click the **Save** button when you're finished:

![Grafana save dashboard](/static/images/tutorials/grafana/grafana_save_dashboard.png)

You've now connected your first data source and created a dashboard with some of the data it exposes. You can continue to visualize other data from the same repository, create dashboards for other GitHub data, and connect additional data sources.

**Note:** As you configure additional data sources, be sure to update the `GF_INSTALL_PLUGINS` environment variable to ensure that the plugins are automatically loaded on each deploy.

## Conclusion

In this guide, we installed and configured the Grafana observability platform on Koyeb. We used an Aiven PostgreSQL database to store our data and deploy using Grafana's Docker images to allow for easy updating and scaling.

Grafana is a powerful tool that can help you track the data from many areas of your organization. Just as importantly, it exposes the data in an approachable way so that users can create their own dashboards and gain insight about the information that's most important to them. As your data management gains complexity, Grafana's architecture and Koyeb's high availability features make it simple to scale out by deploying to new regions or adding additional instances.


This tutorial shows you how to deploy a Grafana instance on Koyeb and use it to visualize data from your GitHub repositories.

Deploy Grafana on Koyeb and Build a Dashboard to Visualize GitHub Data

This guide showcases how to add authentication to a Rails application by using Devise and deploy it into production on Koyeb Serverless Platform.

How to Deploy a Rails Application and Add Authentication using Devise


## Introduction

Docusaurus is a framework for easily building, deploying, and maintaining documentation websites.
[Docusaurus](https://docusaurus.io/) provides out-of-the-box documentation features including blog support, internationalization, search, and versioning.

In this guide, we will explain how to deploy your Docusaurus sites to production with continuous deployment on Koyeb.

By deploying your Docusaurus sites on Koyeb using the git-driven deployment method, each time you push new changes to your GitHub repository, a new deployment will occur and be promoted once the build and health checks are completed.
Once deployed, your Docusaurus sites will benefit from automatic HTTPS (SSL), auto-healing, and global load-balancing across our edge network with zero configuration.

## Requirements

To successfully follow and complete this guide, you need:

- A local development environment with Node.js installed
- A [Koyeb account](https://app.koyeb.com) to deploy and run the Docusaurus site
- A [GitHub account](//github.com/)

## Steps

To deploy a Docusaurus site to Production on Koyeb, you need to follow these steps:

1. [**Create a new Docusaurus project**](#create-a-new-docusaurus-project)
2. [**Initialize a git repository and push your application**](#initialize-a-git-repository-and-push-your-application)
3. [**Deploy the Docusaurus project on Koyeb**](#deploy-the-docusaurus-project-on-koyeb)

## Create a new Docusaurus project

Get started by creating a new Docusaurus project by running the following in your terminal:

```bash
$ npx create-docusaurus@latest
❯ npx create-docusaurus@latest
✔ What should we name this site? … docusaurus-on-koyeb
✔ Select a template below... › classic (recommended)
✔ This template is available in TypeScript. Do you want to use the TS variant? … yes
```

You are asked to provide some information about your project:

- The name of the Docusaurus project site. This information will also be used to create a directory to store your project
- The template to use
- And depending on if the template supports it, whether you want to use the TypeScript template version or not

Once the project initialization completed, a skeleton Docusaurus site is created in the folder you specified containing the following files:

```bash
docusaurus-on-koyeb
├── README.md
├── babel.config.js
├── blog
│   ├── 2019-05-28-first-blog-post.md
│   ├── 2019-05-29-long-blog-post.md
│   ├── 2021-08-01-mdx-blog-post.mdx
│   ├── 2021-08-26-welcome
│   │   ├── docusaurus-plushie-banner.jpeg
│   │   └── index.md
│   └── authors.yml
├── docs
│   ├── intro.md
│   ├── tutorial-basics
│   │   ├── _category_.json
│   │   ├── congratulations.md
│   │   ├── create-a-blog-post.md
│   │   ├── create-a-document.md
│   │   ├── create-a-page.md
│   │   ├── deploy-your-site.md
│   │   └── markdown-features.mdx
│   └── tutorial-extras
│       ├── _category_.json
│       ├── manage-docs-versions.md
│       └── translate-your-site.md
├── docusaurus.config.js
├── package.json
├── sidebars.js
├── src
│   ├── components
│   │   ├── HomepageFeatures.module.css
│   │   └── HomepageFeatures.tsx
│   ├── css
│   │   └── custom.css
│   └── pages
│       ├── index.module.css
│       ├── index.tsx
│       └── markdown-page.md
├── static
│   └── img
│       ├── docusaurus.png
│       ├── favicon.ico
│       ├── logo.svg
│       ├── tutorial
│       │   ├── docsVersionDropdown.png
│       │   └── localeDropdown.png
│       ├── undraw_docusaurus_mountain.svg
│       ├── undraw_docusaurus_react.svg
│       └── undraw_docusaurus_tree.svg
├── tsconfig.json
└── yarn.lock

12 directories, 38 files
```

You can ensure that the Docusaurus project is working as expected by launching the site using the following command in your project folder:

```bash
cd docusaurus-on-koyeb
yarn start
```

Your browser should automatically open a new tab pointing to your Docusaurus site located at `http://localhost:3000`.

### Initialize a git repository and push to GitHub

Create a new GitHub repository from the [GitHub web interface](https://github.com) or using the GitHub CLI by running:

```
gh repo create <YOUR_GITHUB_REPOSITORY> --private
```

Initialize a new git repository on your machine running:

```bash
git init
```

Add a new remote pointing to your GitHub repository:

```bash
git remote add origin git@github.com:<YOUR_GITHUB_USERNAME>/<YOUR_GITHUB_REPOSITORY>.git
```

Add your Docusaurus files to your repository and commit & push the changes:

```bash
git add .
git commit -m "Initial commit"
git push -u origin main
```

## Deploy the Docusaurus project on Koyeb

We are now ready to deploy the Docusaurus site on Koyeb.

Go to the [Koyeb control panel](https://app.koyeb.com). On the **Overview** tab, click the **Create Web Service** button to begin:

1. Select **GitHub** as the deployment method.
2. In the repositories list, select the repository containing your Docusaurus site.
3. In the **Builder** section, click the **Override** toggle associated with the **Run command** and enter `npm run serve -- -h 0.0.0.0 -p 8080` in the field.
4. Choose a name for your App and Service, for example `docusaurus-on-koyeb`, and click **Deploy**.

You land on the deployment page where you can follow the progress of your Docusaurus site's deployment. Once the build and deployment are completed, you can access your application by clicking the App URL ending with `koyeb.app` in the Koyeb control panel.

If you want to learn about how Koyeb automatically builds your Docusaurus site from git, make sure to read our [**how we build from git**](/docs/apps/build-from-git) documentation.

## Conclusion

In this guide, we explained how to deploy a Docusaurus site on Koyeb using git-driven deployment. Now each change you push to your repository will automatically trigger a new build and deployment on the Koyeb Serverless Platform.
Your changes then go live as soon as the deployment passes all necessary health checks. In case of a failure during one of your deployments, we ensure to keep the latest working deployment active so your application is always up and running.

Questions or suggestions to improve this guide? Join us on the **[community platform](https://community.koyeb.com/)** to chat!


This guide explains how to deploy Docusaurus sites using git-driven deployment on Koyeb Serverless Platform.

Deploy Docusaurus on Koyeb


**Koyeb provides developers the fastest way to deploy full stack applications and APIs globally. Want do deploy your Node.js application globally in minutes? [Sign up](https://app.koyeb.com/) today and deploy 2 services for free forever!**

## Introduction

In this guide, we will explain how to deploy a Node.js Express application to production. We will write a simple Node.js API using the Express framework, see how to Dockerize the application,
version it on GitHub, and create a GitHub Actions workflow to perform the CI/CD and deploy the application on Koyeb each time you push changes on a specific branch.

By deploying the Node app on Koyeb, you benefit from native autoscaling, automatic HTTPS (SSL), auto-healing, and global load-balancing across our edge network with zero configuration.

## Requirements

To successfully follow and complete this guide, you need:

- [Docker](https://docs.docker.com/get-docker/) installed on your machine
- A [Koyeb account](https://app.koyeb.com) to deploy and run the Node.js Express application
- The [Koyeb CLI](https://github.com/koyeb/koyeb-cli) installed to interact with Koyeb from the command line
- Have [configured Docker for use with the GitHub container registry](https://docs.github.com/en/packages/guides/configuring-docker-for-use-with-github-packages)
- A [GitHub account](https://www.github.com) with an empty repository we will use to version the application and perform the CI/CD with GitHub Actions

## Steps

To deploy a Node Express Application to Production, you need to follow these steps:

1. [**Create a simple Node.js API using the Express app or use an existing one**](#create-a-simple-node-js-api-using-the-express-framework-application-or-use-an-existing-one)
2. [**Write the Dockerfile and build the Docker image**](#write-the-dockerfile-and-build-the-docker-image)
3. [**Push the Docker image to the GitHub container registry**](#automate-deployment-with-git-hub-actions)
4. [**Deploy the Dockerized Node.js app on Koyeb**](#deploy-the-dockerized-node-js-app-on-koyeb)
5. [**Automate deployment with GitHub Actions**](#automate-deployment-with-git-hub-actions)

## Create a simple Node.js API using the Express framework application or use an existing one

If you already have an existing Node.js application you want to dockerize, you can jump to the next step.

Create a new directory to store our Node.js application:

```bash
mkdir node-express
cd node-express
```

The next step is to create and initialize the package.json file. The package.json contains various metadata and gives npm information to identify the project, handles the project's dependencies, etc.

In your terminal run the following command and complete as below:

```bash
$npm init

This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help init` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (node-express)
version: (1.0.0)
description: A simple Node.js with Express framework application
entry point: (index.js) app.js
test command:
git repository:
keywords:
author:
license: (ISC)
About to write to /Users/koyeb/demo/node-express/package.json:

{
  "name": "node-express",
  "version": "1.0.0",
  "description": "",
  "main": "app.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}


Is this OK? (yes)
```

As our application uses the Express framework, we need to add it as a dependency of our project. In your terminal, run:

```
npm install express --save
```

The project environment ready, we can now start writing our application. In this guide, we create a basic application that will return the port and git commit id the application is using on requests received to the root URL `/`. All other routes will respond with a 404 error.

Create and open a file named `app.js` and copy the content below:

```js
const express = require('express')
const app = express()
const port = process.env.PORT || 3000

app.get('/', (req, res) => {
  res.json({
    commit_id: process.env.COMMIT_ID || 'unknown',
    port,
  })
})

app.listen(port, () => {
  console.log(`App listening at http://localhost:${port}`)
})
```

Launch the app running `node app.js` and request the `/` endpoint running:

```bash
curl http://localhost:3000/
{"commit_id":"unknown","port":3000}
```

The Node app responds with the port the application is listening to "3000" and commit_id set at "unknown" for the moment.

## Write the Dockerfile and build the Docker image

To Dockerize our Node.js app, you need to create a `Dockerfile` in your project folder containing the content below.

```dockerfile
FROM node:lts as runner
WORKDIR /node-express
ENV NODE_ENV production
ARG COMMIT_ID
ENV COMMIT_ID=${COMMIT_ID}
COPY . .
RUN npm ci --only=production
EXPOSE 3000
CMD ["node", "app.js"]
```

To build and properly tag the Docker image execute the following command:

```bash
docker build . -t ghcr.io/<YOUR_GITHUB_USERNAME>/node-express:prod
```

Once the build is over, you can run a container using the image locally to validate everything is working as expected running:

```bash
docker run -p 3000:3000 ghcr.io/<YOUR_GITHUB_USERNAME>/node-express:prod
```

As in the previous step, you can perform a curl request to ensure the app is running as expected:

```bash
$curl http://localhost:3000/
{"commit_id":"unknown","port":3000}
```

## Push the Docker image to the GitHub container registry

With our image built, we can now push it to the GitHub container registry. We will then use this image to deploy the application on Koyeb.

```bash
docker push ghcr.io/<YOUR_GITHUB_USERNAME>/node-express:prod
```

Within a few minutes, you will see your Docker image available on the GitHub container registry: `https://github.com/<YOUR_GITHUB_USERNAME>?tab=packages`.

## Deploy the Dockerized Node.js app on Koyeb

To deploy our dockerized Node.js application on Koyeb, start by creating a Koyeb Secret to store your Github container registry configuration.
Replace `<REPLACE_ME_WITH_GH_USERNAME>` with your GitHub username and `<REPLACE_ME_WITH_GH_TOKEN>` with a valid GitHub token having registry read/write permissions and execute the command below.

```bash
echo \
'{
  "auths": {
    "ghcr.io": {
      "username": "<REPLACE_ME_WITH_GH_USERNAME>",
      "password": "<REPLACE_ME_WITH_GH_TOKEN>"
    }
  }
}' | koyeb secrets create gh-registry-credentials
```

We can now deploy the Node.js application on Koyeb Serverless Platform running:

```bash
koyeb app init node-express --docker "ghcr.io/<REPLACE_ME_WITH_GH_USERNAME>/node-express:prod" --ports 3000:http --routes /:3000 --docker-private-registry-secret gh-registry-credentials
```

Within a few minutes, your application will be live and accessible at `https://node-express-<REPLACE_ME_WITH_GH_USERNAME>.koyeb.app`.

## Automate deployment with GitHub Actions

In the previous steps, we discovered how to dockerize and deploy a Node.js application on Koyeb.

In this section, we will see how to automate the deployment of ou application each time a change is pushed to the branch `main` of your repository using GitHub Actions.

In your git repository, create a folder to store our GitHub Actions workflow:

```
mkdir -p .github/workflows
cd .github/workflows
```

Create a new file named `workflow.yaml` inside the directory we created in the previous step and paste the snippet below:

```yaml
name: CI

on:
  push:
    branches:
      - main

env:
  GHCR_TOKEN: ${{ secrets.GHCR_TOKEN }}

jobs:
  build-push:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Seed env
        run: |
          echo $GITHUB_SHA | awk '{ printf "SHORT_SHA1=%.7s\n", $1 }' >> $GITHUB_ENV
          basename $GITHUB_REF | awk '{ printf "BRANCH_NAME=%s\n", $1 }' >> $GITHUB_ENV
      - name: Docker build
        run: docker build --rm=false --build-arg COMMIT_ID=$GITHUB_SHA -t ghcr.io/<YOUR_GITHUB_USERNAME>/node-express:prod . # REPLACE <YOUR_GITHUB_USERNAME> with your GitHub username.
      - name: Docker login
        run: echo $GHCR_TOKEN | docker login ghcr.io -u <YOUR_GITHUB_USERNAME> --password-stdin # REPLACE <YOUR_GITHUB_USERNAME> with your GitHub username.
      - name: Docker push
        run: docker push ghcr.io/<YOUR_GITHUB_USERNAME>/node-express:prod # REPLACE <YOUR_GITHUB_USERNAME> with your GitHub username.
      - name: Deploy on Koyeb
        uses: koyeb-community/koyeb-actions@v2
        with:
          api_token: '${{ secrets.KOYEB_TOKEN }}'
      - run: koyeb services redeploy --app=node-express node-express
```

In your GitHub repository settings, click **Secrets** in the left-side menu and create new secrets:

- `GHCR_TOKEN` containing a valid GitHub token having registry read/write permissions to push the image to the registry.
- `KOYEB_TOKEN` containing a valid Koyeb token to redeploy the application.

Commit and push your GitHub actions workflow, your GitHub Actions workflow is being executed. Each time a change is pushed on the `main` branch, a Docker image is built and push to the GitHub registry with the tag `prod`. Once the image pushed,
a new deployment is triggered and deployed on the Koyeb Serverless platform.

## Conclusion

In this guide, we explained how to containerize a Node.js application and deploy it on Koyeb. We created a GitHub Actions workflow to build and deploy the application each time a change occurs.
By deploying on Koyeb, your application is secured with native TLS encryption and benefits from all the Koyeb Serverless features including autoscaling, auto-healing, and a high-performance edge network.

If you would like to read more Koyeb tutorials, checkout out our [tutorials collection](/tutorials). Have an idea for a tutorial you'd like us to cover? Let us know by joining the conversation over on the **[Koyeb community platform](https://community.koyeb.com/)**!


Enjoy fast deployments for your Node Express applications. No credit card required.

Express Deployments

This guide explains how to deploy a Node.js Express application using Docker to containerize our app, GitHub actions to perform the CI and CD, and Koyeb Serverless Platform to run the application.