The Docker configuration for Cal is an effort powered by people within the community. Cal.com, Inc. does not provide official support for Docker, but we will accept fixes and documentation. Use at your own risk.

Requirements

1. Have a VPS: check this page https://docs.dokploy.com/en/docs/core/get-started/installation. If it’s your first time using Dokploy, go with Hostinger as they will install Dokploy for you on your VPS.

2. Have a domain: we are going to deploy under cal.yourdomain.com

Disclaimer

We are not using the template provided by Dokploy to self-host Cal.com because it is outdated.

Add a project to your Dokploy instance

It's simple: go to the project section and click on Create Project.

Then, add a name and a description, click "Create," and enter the project by clicking on it.

Create and configure a service

Inside your project, you can create a service by clicking "Create Service" in the top right corner.

Docker-compose

In the General tab, under Provider, click on Raw and then paste the code inside.

services:
  database:
    image: postgres:16
    networks:
      - dokploy-network
    volumes:
      - calcom-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}
      - DATABASE_URL=${DATABASE_URL}

  calcom:
    image: calcom/cal.com:latest
    depends_on:
      - database
    environment:
      - LICENSE=agree
      - NEXTAUTH_SECRET=${NEXTAUTH_SECRET}
      - CALENDSO_ENCRYPTION_KEY=${CALENDSO_ENCRYPTION_KEY}
      - DATABASE_URL=${DATABASE_URL}
      - DATABASE_DIRECT_URL=${DATABASE_URL}
      - NEXT_PUBLIC_WEBAPP_URL=${NEXT_PUBLIC_WEBAPP_URL}
      - NEXT_PUBLIC_API_V2_URL=${NEXT_PUBLIC_API_V2_URL}
      #- GOOGLE_LOGIN_ENABLED=${GOOGLE_LOGIN_ENABLED}
      - GOOGLE_API_CREDENTIALS=${GOOGLE_API_CREDENTIALS}
      - EMAIL_FROM=${EMAIL_FROM}
      - NODE_ENV=production

volumes:
  calcom-data:

Your service interface should look like this. 🔽

Environment

Go to the Environment tab in your service and edit the environment variables to add this:

NEXTAUTH_SECRET=gRUQErxuNskUjVhR8TTerrzgnmm4VPx78e6PBaLCFQM= #generate it
CALENDSO_ENCRYPTION_KEY=acu16cfdadc1996h9c6df109ddc1e67c #generate it by running 'dd if=/dev/urandom bs=1K count=1 | md5sum' 

CALCOM_HOST=cal.yourdomain.com
NEXT_PUBLIC_WEBAPP_URL=https://${CALCOM_HOST}

POSTGRES_USER=user #change it
POSTGRES_PASSWORD=password #change it
POSTGRES_DB=calendso #change it
DATABASE_HOST=database:5432
DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${DATABASE_HOST}/${POSTGRES_DB}

GOOGLE_API_CREDENTIALS={}
GOOGLE_LOGIN_ENABLED=false

EMAIL_FROM=notifications@yourdomain.com
EMAIL_FROM_NAME=yourname

EMAIL_SERVER_HOST=smtp-relay.gmail.com #change it
EMAIL_SERVER_PORT=587

Hit save, and you're all set for this section. It should look like this.🔽

The CALENDSO_ENCRYPTION_KEY needs to be this size to enable 2FA for administrator access in the Cal app. You will see an orange banner at the top when connecting for the first time.

GOOGLE_API_CREDENTIALS and GOOGLE_LOGIN_ENABLED are variables used if you want to connect your Google Calendar to your Cal app. Just follow this tutorial to do it: https://cal.com/docs/self-hosting/apps/install-apps/google

Domain

Go to the Domains tab and add your domain that matches the CALCOM_HOST in the environment.

The configuration is:

• Service Name : calcom

• Host : cal.yourdomain.com

• Path : /

• Container Port : 3000

• HTTPS : ✅

• Certificate : Letsencrypt

Then delete the default Traefik domain, as it's not needed.

Now, go to the DNS settings of your domain and add a record for your subdomain:
A — cal — <IP_of_your_VPS>

Deploy

Just go back to the General section inside your service and click Deploy. It might take some time for the first deployment because it downloads the Cal.com Docker image, which is 4GB in size. So, please be patient. Once it's deployed, go to cal.yourdomain.com and complete the setup.

Cheers ❤️

Create a composable for your event bus

How to create a composable to serve as a Global Event Bus in your Vue.js application ? Handling events efficiently becomes essential as your Vue.js project evolves. With this composable, you'll establish a centralized event management system that simplifies event handling, enhances code organization, and boosts maintainability.

// project/useEventBus.ts
import mitt, { EventType, Handler } from 'mitt';

export interface GlobalEvents extends Record<EventType, unknown> {}

const emitter = mitt<GlobalEvents>();

export function useEventBus() {
    return emitter
}

Choose a name for your event

Don't use simple strings. For consistency and usefulness, wrap them inside a constant. Whatever the shape, just wrap it!

// project/ResourceEvent.ts

export const EVENT_Resource = 'resource:post';
// OR
export const EVENT_Resource = {
    Post: 'resource:post',
    Patch: 'resource:patch',
} as const;

declare module './useEventBus' {
    interface GlobalEvents {
        [EVENT_Resource.Post]: YourAwesomeType;
        [EVENT_Resource.Patch]: YourAwesomeType;
        //...
    }
}

In order to use that event, you have to import it wherever you need it, like so:

import { EVENT_Resource } from 'project/ResourceEvent';
import { useEventBus } from 'project/useEventBus';

const { on, emit, off } = useEventBus();

on(EVENT_Resource.Post, () => { ... })
emit(EVENT_Resource.Post, { ... })
off(EVENT_Resource.Post, () => { ... })

Create the composable you need for your business logic

// project/useResourceHandler
import { EVENT_Resource } from 'project/ResourceEvent';
import { useEventBus } from 'project/useEventBus';
import { ref } from 'vue';

export function useResourceHandler() {
    const whatever = ref<YourAwesomeType>();

    const { on, emit } = useEventBus();

    on(EVENT_Resource.Post, (payload) => {
        whatever.value = payload;
    });

    function triggerEvent(obj: YourAwesomeType) {
        emit(EVENT_Resource.Post, obj);
    }

    return {
        whatever,
    }
}

Now you have your business logic wrapped into a composable, so you can use it inside a component:

// project/MyAwesomeComponent.vue

<template>
 <button @click="triggerEvent({name: 'fake'})">Fake button</button>
</template>

<script setup lang="ts">
import { useResourceHandler } from 'project/useResourceHandler'

const { triggerEvent, whatever } = useResourceHandler();
</script>

This is only for example purposes, but you can do way more and organize your code in another way that fits your needs.

So now you have everything set up, but if you leave it like that, you are going to have multiple handlers registered in the event bus for this event as the user goes back and forth in your interface. Each time you use your composable, you are asking to register the handler. So let's see what we need to do next.

Don't forget to unsubscribe

In Vue.js, you have the context of a Vue.js app, and the composition API makes things mount and unmount (component or composable). As mentioned in this section of the documentation (https://vuejs.org/guide/reusability/composables#side-effects): WE NEED TO CLEAN UP SIDE EFFECTS. In our case, subscribing to an event is a “side effect” of our logic, and so we need to clean it up.

Change your composable as below:

// project/useResourceHandler
import { EVENT_Resource } from 'project/ResourceEvent';
import { useEventBus } from 'project/useEventBus';
import { ref } from 'vue';

export function useResourceHandler() {
    const whatever = ref<YourAwesomeType>();

    const { on, emit, off } = useEventBus();

    on(EVENT_Resource.Post, (payload) => {
        whatever.value = payload;
    });

    function triggerEvent(obj: YourAwesomeType) {
        emit(EVENT_Resource.Post, obj);
    }

    onBeforeUnmount(() => {
        off(EVENT_Resource.post);
    });

    return {
        whatever,
    }
}

Now you realize it's kind of boring and repetitive to unsubscribe every time you subscribe to an event somewhere in your app. So to improve that, check the next extra step.

Generalize everything and DO NOT REPEAT YOURSELF

As your app grows, you are going to have hundreds of events to manage and use, and therefore, hundreds of lines of code to subscribe and then unsubscribe. It's kind of a pain to do that everywhere. So let's refactor our code a bit.

// project/useEventBus.ts
import mitt, { EventType, Handler } from 'mitt';
import { onBeforeUnmount } from 'vue';

const emitter = mitt<>();

export interface GlobalEvents extends Record<EventType, unknown> {}

export function useEventBus() {
    function extendedOn<Key extends keyof GlobalEvents>(
        type: Key,
        handler: Handler<GlobalEvents[Key]>,
    ): void {
        emitter.on(type, handler);
        onBeforeUnmount(async () => {
            emitter.off(type, handler);
        });
    }

    return { ...emitter, extendedOn };
}

You can improve that function by passing an options parameter to that function in order to be able to deactivate this extra behaviour if needed.

So now, to use it, the good thing is that we don't need to touch our components. Just go to your composable and change the function used to subscribe to an event.

// project/useResourceHandler
import { EVENT_Resource } from 'project/ResourceEvent';
import { useEventBus } from 'project/useEventBus';
import { ref } from 'vue';

export function useResourceHandler() {
    const whatever = ref<YourAwesomeType>();

    const { extendedOn, emit, off } = useEventBus();

    extendedOn(EVENT_Resource.Post, (payload) => {
        whatever.value = payload;
    });

    function triggerEvent(obj: YourAwesomeType) {
        emit(EVENT_Resource.Post, obj);
    }

    /* REMOVE THAT
    onBeforeUnmount(() => {
        off(EVENT_Resource.post);
    });*/

    return {
        whatever,
    }
}

And voilà! You're all set up to build an app with an amazing global Event Bus that allows you to reuse logic everywhere!

• Full understanding of Moonrepo tasks system (and a Moon project) (moonrepo.dev)
• Full understanding of GitHub Actions (And a repository, with the Moon project inside; obvious? Just saying 😘)
• Full understanding of Docker (and Docker installed; did you guess it?)
• Basic knowledge of bash/sh scripting

What is the goal?

The goal is to be able to launch a GitHub Runner as a container from any development computer (running Docker). Additionally, integrate it inside a Moonrepo monorepo repository (🤕) and have a task to launch it (or them) locally.

And because it's fun to start playing with monorepos and see how helpful those tools are when running in CI.

At Alpsify, we work with a monorepo powered by Moonrepo. We launch self-hosted GitHub Runners on local machines because we can't afford big Kubernetes clusters to auto-scale a fleet of runners. So, we have a fleet of approximately 5 runners across our computers. It's like free CPU time, as our computers never hit the limit and are always on during working time. It's just our way of doing it to save costs.

Note: This approach is not a perfect fit for everyone. We're just sharing something that works for us and may work for others.

GitHub Runner as a Container

Create a folder inside your Moonrepo repository (😮‍💨) and name it as you wish. I'll refer to it as <project-name> afterwards.

Register it in your .moon/workspace.yml if needed (depends on your config).

This part is inspired by a discussion on GitHub (https://github.com/actions/runner/issues/367#issuecomment-1507331413)

Create a Dockerfile inside <project-name>

# <project-name>/Dockerfile
FROM ghcr.io/actions/actions-runner:latest
RUN sudo apt update -y && sudo apt install build-essential git curl -y #(whatever you need)

COPY ./runner.sh .
RUN sudo chmod +x runner.sh

CMD ["./runner.sh"]

Create the runner.sh file inside

# <project-name>/runner.sh
#!/bin/sh

./config.sh --url https://github.com/<repo-name> --token $TOKEN --name $NAME --unattended
./run.sh

At this step, you can actually run your first GitHub Runner:

Inside your <project-name> folder, run docker build --no-cache -t docker/github-runner . to build your image. Then run docker run docker/github-runner.

Don't forget to replace $TOKEN or $NAME with the actual values. You can find your $TOKEN at this link: https://github.com//settings/actions/runners/new. Don't replace it inside the runner.sh as it's going to be versioned. And believe me, you don't want your private secret $TOKEN to be versioned.

Moonrepo Task Configuration

Create a moon.yml file inside <project-name> folder

# <project-name>/moon.yml
...

project:
    name: 'GitHub Runner in Docker'
    description: 'GitHub Runner (as container) launcher'
    ...

tasks:
    build:
        command: 'docker build --no-cache -t docker/github-runner .'
        platform: 'system'
        local: true

  run:
    #-- -n -t
    deps:
        - 'build'
    command: 'bash ./launch-container.sh'
    platform: 'system'
    local: true

Create the launch-container.sh file

# <project-name>/launch-container.sh
#!/bin/bash
while getopts n:t: flag
do
    case "${flag}" in
        n) name=${OPTARG};;
        t) token=${OPTARG};;
    esac
done

docker run -d -e NAME=$name -e TOKEN=$token --name $name docker/github-runner

The --name $name is to quickly identify which container it is (compared to GitHub Runner registration name). Sometimes you get errors, and you need to go deep into the details, so auto-generated names are not that useful in this kind of situation. 🥹

Enjoy

Run the command moon <project-name>:run -- -t $TOKEN -n my-awesome-runner-1 (still need $TOKEN to be replaced)

Run it again with another name -n my-lovely-runner-1 ! Voilà! You got another one up and running, ready to take care of your CI jobs.

Don't forget to add runs-on: 'self-hosted' in your .github/workflows/<whatever>.yml file for your CI to use it.

Look at the page https://github.com/<your-repo-name>/settings/actions/runners and enjoy your new GitHub Runners! 🥳