
Alexander is a writer, traveler, and serial digital entrepreneur. He’s the founder of the Tushi, the Gen X personal growth newsletter Further, and offers small business advice at Unemployable.

Twitter

Linkedin

Facebook

Director and Chief Evangelist

Alexander Hipp


Anil is a content-obsessed marketer who loves driving organic traffic for outstanding companies. He is also the creator of Hack the Content, co-host of The Runner, and owner of several digital commerce sites.

Managing Partner

Anil Vugels


Monika is a writer, musician, and content strategist with a passion for language. When she isn’t helping clients, you can find her writing songs, hiking in a northern forest, or furiously journaling.

Director of Operations

Ann Monika

Programmer / Founder / Student

Tim Schupp


n8n is a flexible, open-source workflow automation tool that runs well on a small self-hosted cluster. Below is a lean, production-minded setup using a maintained Helm chart. This mirrors my usual pattern: keep it simple, make it reproducible, and put it behind ingress with TLS.

### Helm chart

Maintained chart: [`8gears/n8n-helm-chart`](https://github.com/8gears/n8n-helm-chart) — solid defaults, clear values, and active maintenance by the 8gears team. Kudos to the authors and maintainers for keeping queue mode, probes, lifecycle hooks, and ingress settings tidy and well-documented.

> If you’re new to Kubernetes on a VPS, see my Microk8s setup first: [/blog/microk8s-on-vps](/blog/microk8s-on-vps)

### Example values

Sanitize hosts and secrets for your environment. This example uses `ClusterIP` with `nginx` and `cert-manager`.

```yaml
persistence:
  enabled: true

image:
  repository: n8nio/n8n
  pullPolicy: IfNotPresent
ingress:
  enabled: true
  className: "nginx"
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  hosts:
    - host: n8n.t1m.me
      paths:
        - "/"
  tls:
    - hosts:
        - n8n.t1m.me
      secretName: n8n-example-com-tls
main:
  replicaCount: 1
  deploymentStrategy:
    type: Recreate
  persistence:
    enabled: true
    type: "dynamic"
    mountPath: "/home/node/.n8n"
    storageClass: "<your-default-storage-class>"
    size: 8Gi
    accessModes:
      - ReadWriteOnce
    annotations:
      helm.sh/resource-policy: keep
  nodes:
    builtin:
      enabled: true
      modules:
        - ws
      reinstallMissingPackages: true
  service:
    type: ClusterIP
    port: 5678
  config:
    n8n:
      host: "n8s.<your-domain>"
      protocol: "https"
      port: 5678
      editor_base_url: "https://n8s.<your-domain>"
      webhook_url: "https://n8s.<your-domain>"
      secure_cookie: "true"
      proxy_hops: 1
      log_level: "info"
      diagnostics_enabled: "false"
    db:
      type: "sqlite"
  secret:
    n8n:
      encryption_key: "CENSORED"
scaling:
  enabled: false
  worker:
    replicaCount: 0
  webhook:
    enabled: false
    replicaCount: 0
```

Notes:
- For quick single-node or hobby deployments, `sqlite` is fine. For multi-node or longevity, pick Postgres.
- Set `encryption_key` to a long, random value. Rotating it will invalidate existing encrypted credentials.
- If you want queue mode, enable `scaling.enabled` and configure Redis (internal `valkey` or external Redis) as per the chart docs.
- The `persistence` block ensures your workflows and credentials survive pod restarts.
- `helm.sh/resource-policy: keep` prevents accidental data loss during Helm uninstalls.

### Install/upgrade commands

Run with your `kubeconfig.yaml` and a dedicated namespace:

```bash
KUBECONFIG=./kubeconfig.yaml kubectl create ns n8n
KUBECONFIG=./kubeconfig.yaml helm uninstall n8n -n n8n
KUBECONFIG=./kubeconfig.yaml helm upgrade --install n8n oci://8gears.container-registry.com/library/n8n --namespace n8n -f n8n-values.yaml
```

After the release becomes `READY`, n8n should be reachable at `https://n8n.t1m.me` (or your configured host).

### Verify persistence before going live

**Critical**: Before creating workflows or adding credentials, verify that the persistent volume is working correctly. A failed volume mount means data loss on pod restarts.

Check the pod status and volume mount:

```bash
KUBECONFIG=./kubeconfig.yaml kubectl get pods -n n8n
KUBECONFIG=./kubeconfig.yaml kubectl describe pod -n n8n -l app.kubernetes.io/name=n8n
```

Look for:
- Pod status: `Running`
- Volume mount: `/home/node/.n8n` should be mounted from your PVC
- No volume-related errors in events

Test persistence by creating a simple workflow, restarting the pod, and verifying it still exists:

```bash
# Restart the pod to test persistence
KUBECONFIG=./kubeconfig.yaml kubectl delete pod -n n8n -l app.kubernetes.io/name=n8n
```

If your workflows disappear after the restart, the volume mount failed. Check your storage class and PVC status:

```bash
KUBECONFIG=./kubeconfig.yaml kubectl get pvc -n n8n
KUBECONFIG=./kubeconfig.yaml kubectl describe pvc -n n8n
```

### Credential management via CLI

n8n includes a CLI for bulk credential operations. Access the container and use these commands:

```bash
# Get into the running pod
KUBECONFIG=./kubeconfig.yaml kubectl exec -it -n n8n deployment/n8n -- /bin/sh

# Export all credentials (decrypted)
n8n export:credentials --all --decrypted --output=credentials.json

# Import credentials from file
n8n import:credentials --input=credentials.json
```

This is useful for:
- Backing up credentials before major updates
- Migrating between n8n instances
- Disaster recovery scenarios

**Security note**: The `--decrypted` flag exports credentials in plain text. Handle these files with extreme care and delete them immediately after use.

### Bulk restore / import n8n json workflows

For migrating workflows from another n8n instance or restoring from backups, you can bulk import JSON workflow files directly into your Kubernetes deployment.

Download and run the restoration script:

```bash
curl -fsSL https://raw.githubusercontent.com/tbscode/tims-blog-posts/refs/heads/main/assets/restore_workflow_json_files.sh -o restore_workflow_json_files.sh
chmod +x restore_workflow_json_files.sh
export KUBECONFIG=<your-kubeconfig>
SRC_DIR=<local-dir-containing-workflows>
./restore_workflow_json_files.sh $SRC_DIR
```

The script will:
- Find your running n8n pod automatically
- Upload all `.json` files from the specified directory
- Import each workflow using the n8n CLI
- Provide a summary of successful/failed imports
- Clean up temporary files

This makes it trivial to migrate workflows between n8n instances or restore from backups. The script handles all the Kubernetes complexity, so you just point it at a folder of JSON files.

### Hardening checklist

- Switch to Postgres for production and enable persistent volumes.
- Keep `secure_cookie: true` and TLS on end-to-end; n8n stores credentials for integrations.
- Limit ingress access (e.g., IP allowlists) if you only need the editor from trusted networks.
- Set `N8N_USER_MANAGEMENT_DISABLED=false` and create dedicated users; enable 2FA on your IdP if applicable.
- Regularly backup your persistent volume and test restore procedures.
- Monitor PVC usage to avoid running out of storage space.

### About the chart authors

The chart is maintained by the 8gears team and contributors. The repository is here: [`8gears/n8n-helm-chart`](https://github.com/8gears/n8n-helm-chart). They’ve done a great job exposing n8n’s core options (readiness/liveness probes, deployment strategies, webhook and worker modes, and Redis/Valkey integration) in a clean values structure.

That’s it—small, clean, and easy to back up. Perfect fit for a self-hosted automation hub.


Minimal, repeatable setup to run n8n with TLS behind nginx ingress using the 8gears Helm chart.

Self-Hosted n8n on Kubernetes (Helm chart)


Uptime-Kuma is a lightweight status and monitoring dashboard suited for homelabs or lean production clusters. Below is a minimal, repeatable setup to run it behind an ingress with TLS.

### Helm Chart

A maintained chart is available: [dirsigler/uptime-kuma-helm](https://github.com/dirsigler/uptime-kuma-helm), from [`@dirsigler`](https://github.com/dirsigler/uptime-kuma-helm).

```bash
helm repo add uptime-kuma https://helm.irsigler.cloud
helm repo update
helm upgrade my-uptime-kuma uptime-kuma/uptime-kuma \
  --install \
  --namespace monitoring \
  --create-namespace \
  -f values.uptime-kuma.yaml
```

### Preview

The following screenshot shows how Uptime-Kuma presents monitoring data for this blog (`blog.t1m.me`).

![Uptime-Kuma dashboard for blog.t1m.me](/static/assets/uptime-kuma-dashboard.png)

### Example values

Sanitize hosts/secrets for the target environment. This example runs as a `ClusterIP` behind `nginx` and cert-manager.

```yaml
ingress:
  enabled: true
  ingressClassName: public
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: public
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "https://<your-domain>"
    nginx.ingress.kubernetes.io/cors-allow-methods: "GET, OPTIONS"
    nginx.ingress.kubernetes.io/cors-allow-headers: "Content-Type"
    nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
    nginx.ingress.kubernetes.io/server-snippets: |
      proxy_buffering off;
      proxy_cache off;
  hosts:
    - host: status.<your-domain>
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: uptime-kuma-tls
      hosts:
        - status.<your-domain>

persistence:
  enabled: true
  size: 5Gi

service:
  type: ClusterIP
  port: 3001

env:
  TZ: Europe/Berlin
```

A helper script is available for quick install and values generation:

- Download: [`setup_uptime_kuma.sh`](https://github.com/tbscode/tims-blog-posts/blob/main/assets/setup_uptime_kuma.sh)
- Make executable and run with env vars:

```bash
curl -fsSL https://raw.githubusercontent.com/tbscode/tims-blog-posts/refs/heads/main/assets/setup_uptime_kuma.sh -o setup_uptime_kuma.sh
chmod +x setup_uptime_kuma.sh
KUBECONFIG=./kubeconfig.yaml HOST="status.<your-domain>" ./setup_uptime_kuma.sh
```

Notes:

- Keep persistence on; monitors would otherwise need reconfiguration after pod restarts.
- On Microk8s, ensure `ingress` and `cert-manager` are enabled and a `ClusterIssuer` named `letsencrypt-prod` exists.
- The app becomes reachable at `https://status.<your-domain>` after DNS is set.

That’s it—small, stable, and easy to back up. Perfect for keeping a quiet eye on your stack.


### Alerts and hardening

- Enable certificate expiration notifications. Even with cert-manager in place (see the Kubernetes setup post), missed renewals often indicate underlying cluster health issues.
- Configure Twilio SMS alerts to receive notifications when an endpoint goes down and when it recovers. The following screenshot shows a brief incident where a page returned 503 and then back to 200 (minimal downtime during a controlled server migration):

![Incident timeline 503→200](/static/assets/kuma-uptime-incident-503-200.png)

- Enable 2FA for the admin account.

![Uptime-Kuma 2FA](/static/assets/2fa-uptime-kuma.png)

- Set up automated backups. Creating a daily full copy of `/app/data` and keeping a sensible retention schedule is recommended.




Tiny guide to deploy Uptime-Kuma on a self-hosted Kubernetes cluster using a maintained Helm chart.

Self-Hosted Uptime Monitoring on Kubernetes with Uptime-Kuma


A quick, repeatable way to run WordPress on Kubernetes using the maintained TrueCharts chart. Small footprint, TLS via cert-manager, and a clean ingress.

### Chart

The TrueCharts WordPress chart ships via OCI and builds on the TrueCharts common library for consistent values and sane defaults.

- Chart page: [truecharts.org/charts/stable/wordpress](https://truecharts.org/charts/stable/wordpress/)

```bash
helm install wp oci://oci.trueforge.org/truecharts/wordpress \
  --namespace blogging \
  --create-namespace \
  -f values.wordpress.yaml
```

### Example values

Sanitize domains, credentials, and secret names for the target setup.

```yaml
ingress:
  main:
    enabled: true
    ingressClassName: public
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-prod
      nginx.ingress.kubernetes.io/proxy-body-size: "0"
    hosts:
      - host: wp.<your-domain>
        paths:
          - path: /
            pathType: Prefix
    tls:
      - hosts: [wp.<your-domain>]
        secretName: wp-<your-domain>-tls

wordpress:
  user: "<admin-username>"
  pass: "<strong-password>"

workload:
  main:
    replicas: 1
    podSpec:
      containers:
        main:
          env:
            WORDPRESS_EXTRA_WP_CONFIG_CONTENT: |
              define('WP_HOME','https://wp.<your-domain>');
              define('WP_SITEURL','https://wp.<your-domain>');

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "4"
    memory: "8Gi"
```

Notes:

- Ensure `ingress` and `cert-manager` are installed and a `ClusterIssuer` named `letsencrypt-prod` exists.
- Set DNS for `wp.<your-domain>` to the ingress IP. After install, visit `https://wp.<your-domain>`.
- TrueCharts maintains a broad catalog and a shared common chart, providing consistent configuration across apps; the WordPress chart is kept up-to-date and is straightforward to automate.




Set up WordPress on a self-hosted Kubernetes cluster using the TrueCharts Helm chart.

WordPress on Kubernetes with TrueCharts (short guide)



In light of Twilio Video Calls reaching its end of life, the quest for a new video call service provider - for our startup [Little World](https://little-world.com) - is essential for seamless communication experiences. This comparison focuses on technical capabilities, overlooking aspects such as server hosting locations and GDPR compliance which are beyond the scope of this review.

I've experimented & compiled the following table, to compare various services based on criteria essential for React-based web and native applications. These criteria include unique authentication for rooms, server-side token generation, webhooks, device detection and permissions, compatibility across platforms, mobile redirection capabilities, pricing, React SDK availability, self-hosting possibilities, and practical implementation tests.

| Feature / Service | [LiveKit](https://docs.livekit.io/realtime/) | [Dyte.io](https://dyte.io/) | [Jitsi Meet Self Hosted](https://jitsi.org/) | [Jitsi 8x8 Conferencing](https://8x8.vc/) | [Zoom](https://zoom.us/) |
|-------------------|:--------------------------------------------:|:-------------------------:|:-------------------------------------------:|:-----------------------------------------:|:-----------------------:|
| Unique Authentication Required Rooms | Yes | Yes | Yes | Yes | Yes |
| Server-side Token Generation | Yes | Yes | Yes | Yes | Yes |
| Webhooks (Join/Leave) | Yes | Yes | [No #1](#1) | Yes | Yes |
| Built-in Device Detection & Permissions | Yes | Yes | Yes | Yes | Yes |
| Cross-Platform Compatibility | [Yes (React Native) #2](#2) | [Partially (No WebView) #3](#3) | [Yes #5](#5) | [Yes #5](#5) | [Partially #5](#4) |
| Mobile Redirect for App Calls | No | [Uncertain #5](#5) | Yes | Yes | Yes |
| Affordable & Scalable Pricing | Yes | Yes | Not really (Consider Maintenance) | [No #6](#6) | [Yes #7](#7) |
| React SDK Availability | Yes | Yes | Yes | Yes | [No #8](#8) |
| Self-Hosting Capability | Yes | No | Yes | No | No |
| Practical Implementation Test | Not yet | No | Yes but no sockets! | Yes | Yes |

###### Notes:

- <a id="1"></a>**#1 Jitsi Meet Self Hosted**: Webhooks would require custom implementation.
- <a id="2"></a>**#2 LiveKit**: Exclusive React Native integrations for Android and iOS.
- <a id="3"></a>**#3 Dyte.io**: Limited to native apps, lacks in-browser video call support.
- <a id="4"></a>**#4 Zoom**: Compatibility issues noted with WebView; [native or react-native Zoom clients necessary](https://developers.zoom.us/docs/video-sdk/react-native/)
- <a id="5"></a>**#5 Jitsi**: Even has mobile webview / capacitor support ( no need for native / react native )
- <a id="6"></a>**#6 Jitsi 8x8 Conferencing**: Expensive for broader usage.
- <a id="7"></a>**#7 Zoom**: Pricing model based on usage; but specificly low entry pricing / many free minutes per month
- <a id="8"></a>**#8 Zoom**: The SDK constrains customization options, offering default Zoom UI.

For developers seeking to replace Twilio Video Calls, this comparison sheds light on several viable alternatives. Each service offers a unique blend of features and constraints, making it crucial to align the choice with the specific needs of your application and user base. 

Further exploration and prototypes are valuable steps toward identifying the most suitable video call service. Additionally, reviewing discussions and feedback, such as those found in [community forums](https://www.reddit.com/r/node/comments/18bain4/list_of_top_twilio_video_alternatives/), can provide insights and considerations from a broader development community.

#### Conclusion

To me, it seems that LiveKit is the most promising solution. It allows full UI customization, has the required socket integrations, React Native SDKs, and can even be self-hosted. I was surprised to see how difficult and annoying it is to use the Zoom SDK with a custom video call UI; other than that, it's probably the best in terms of pricing. Jitsi is also quite good in this regard, but the missing WebSocket integrations (offered by 8x8 Conferencing) make it hard to use for web applications.

Dyte also looks fairly strong, but I haven't investigated it as much. In my opinion, it loses to LiveKit for not being open-source or self-hostable.

This comparison is not exhaustive in any regard, please contact me for comments or improvements!


#### Additional Options To Consider:

- https://docs.videosdk.live/
- https://www.daily.co/


A comprehensive comparison of leading video call service providers focusing on cross-platform compatibility for React-based web and native applications.

Comparison of Video Call Services for Cross-Platform React Web/Native Apps


### Full Setup Lenovo Yoga 9 Pro Regolith Linux (Ubuntu 23.10 + i3)

This is my setup guide for Linux on my new laptop. I'm using the newest 23.10 Ubuntu because I want to.
This blog intends to report how I got things set up & the open issues I still have.

> Don't hesitate to contact me if you have possible solutions or questions regarding my setup, cheers :)

This is the labtop in question: https://geizhals.de/lenovo-yoga-pro-7-14aph8-storm-grey-82y80020ge-a3000891.html?hloc=at&hloc=de

- 14.5", 2560x1600 (WQXGA), 16:10, 208ppi, 90Hz, non-glare (matt), IPS, 350cd/​m², Blaulichtfilter, Dolby Vision, 1.500:1, 100% sRGB 
- AMD Ryzen 7 7840HS, 8C/16T, 3.80-5.10GHz, 16MB+8MB Cache, 35W TDP, 54W cTDP, Codename "Phoenix" (Zen 4, TSMC 4nm) 
- AMD Radeon 780M (iGPU), 12CU/768SP, 2.70GHz, Architektur "RDNA 3" (Phoenix) ( no additional GPU )
- 32GB LPDDR5X-6400 (32GB verlötet, nicht erweiterbar) 


## Open Issues:

1. Keyboard backlight levels not working correctly
It goes from bright to medium to bright to out. But medium is also very bright.
2. Master sound level not working (generally sound seems off)
I've also played with a lot of different output options in `pavucontrol`,
some seem to be completely broken and sound super metallic, while others sound pretty good at full volume but then start sounding weird when leveling down the audio.
This is significantly annoying but ok since it can be worked around by leveling the specific output sound level instead of using the volume buttons.

## Initial setup

The laptop comes with Windows originally. So I:

- create a boot USB with Ubuntu 23.10.
- disable BitLocker in PowerShell
- disable hibernation in PowerShell
- in Windows prepare an unformatted partition of the hard drive
- in BIOS disable secure boot
- boot & install Ubuntu 23.10
- install regolith-desktop using package: https://regolith-desktop.com/

## Configuring Regolith

Basic Regolith / i3 looks can be configured in `~/.config/regolith3/Xresources`.
E.g.: I like to adjust gap and border sizes & colors:

```
wm.gaps.inner.size: 1
wm.window.border.size: 3
wm.client.focused.color.child_border: #AAD3E9
```

## Resolution

- Falsely detected out of the box required xrandr adjustments.
- issues with fractional scaling if not on Ubuntu desktop (so i3)

I found that the i3 window header and bar sizes seem to depend on the dpi set in `~/.Xresources`.
`Xft.dpi: 100`. Weirdly, a higher value causes bigger i3 bar and UI and a lower one smaller.

> I found the cursor size set here to have no effect `Xcursor.size: 5`

To view the current resolution config `xdpyinfo | grep -B 2 resolution`:

```
screen #0:
  dimensions:    2560x1600 pixels (677x423 millimeters)
  resolution:    96x96 dots per inch
```

## External Monitors (& USB monitors)

At first, I thought the external monitors were not working but I soon realized that they were detected but not set to `active`, simply going into `arandr`, setting them to active, and then applying the configuration made all external monitors work as expected.

### Persisting xrandr settings using autorandr

`sudo apt install autorandr` just set the correct settings using `xrandr` or a UI like `arandr`,
then save the profile as default `autorandr --save default`

### Gnome Scaling Factor

I wasn't yet able to get fractional scaling working on Ubuntu yet.
But I found that the overall scale can be set from the command line using:

```bash
gsettings set org.gnome.settings-daemon.plugins.xsettings overrides  "[{'Gdk/WindowScalingFactor', <1>}]"
gsettings set org.gnome.desktop.interface scaling-factor 1
```

It accepts scaling factors `1`, `2`, `3`

## Setting up Keepmenu as password manager

I love using Keepmenu to easily manage a local password database.

- https://github.com/firecat53/keepmenu

I use it with `rofi`; this is my config: `~/.config/keepmenu/config.ini`:

```ini
[dmenu]
dmenu_command = rofi -show drun -dpi 1

[dmenu_passphrase]
nf = #222222
nb = #222222
rofi_obscure = True

[database]
database_1 = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
keyfile_1 = 
pw_cache_period_min = 30
autotype_default = {USERNAME}{TAB}{PASSWORD}{ENTER}
```

### Setting up the keybinding

The easiest way is to just use the GNOME system keybindings like described in: https://regolith-desktop.com/docs/using-regolith/configuration/

Just open the GNOME settings `Super+c` & open the keybindings editor in the 'Keyboard' settings.

You could also set it up using an i3 config e.g.:

```bash
bindsym $mod+Shift+K exec "DO SOMETHING"
```

## Setup screenshot command

`sudo apt install gnome-screenshot`

I like to map it to `Super+Shift+U`

Then setup a keyboard shortcut like this: `gnome-screenshot -acf /tmp/test && cat /tmp/test | xclip -i -selection clipboard -target image/png`
[as per this stack overflow answer](https://askubuntu.com/questions/1196914/gnome-screenshot-cant-copy-to-clipboard-in-ubuntu-18-04).

I saw only this stategy working, copying directly with `-acf` wan't working for me.


A comprehensive setup guide for setting up a Lenovo Yoga 9 Pro with Ubuntu 23.10 and Regolith i3, including resolution and external monitors configuration, and workarounds for common issues.

Full Setup Guide: Lenovo Yoga 9 Pro with Regolith Linux (Ubuntu 23.10 + i3)


- [the python script](https://github.com/tbscode/tims-blog-posts/blob/main/assets/send_slack_message.py)

Need to notify your team about deployment status on Slack? Automate the process using the slack_sdk Python package with GitHub Actions. Here's how to set it up step by step:

### Creating Your Slack App for Notifications

1. **Create a Slack App**: Go to the [Slack API](https://api.slack.com/apps) section, select 'Create New App', input a name, and choose your workspace.

2. **Set Permissions**: In the Slack app settings, navigate to 'Features' > 'OAuth & Permissions'. Under 'Scopes', add `chat:write` for your bot to send messages. Once you save changes, click 'Install to Workspace'.

3. **Retrieve Your Slack Bot Token**: After installing the app to your workspace, grab your 'Bot User OAuth Token' from the 'OAuth & Permissions' page. Securely store this token as it will be used to authenticate your GitHub Actions script.

### Setting Up GitHub Actions to Send Slack Notifications

First, include your Slack API token as a secret in your GitHub repository:

1. In your GitHub repo, go to 'Settings', then 'Secrets'.
2. Select 'New Repository Secret', and add your Slack API token under `SLACK_API_TOKEN`.

Now, integrate the `send_slack_message.py` script with your deployment process:

```python
# send_slack_message.py
import os
from slack_sdk import WebClient

client = WebClient(token=os.environ["SLACK_API_TOKEN"])

response = client.chat_postMessage(
    channel=os.environ["CHANNEL_ID"],
    mrkdwn=True,
    text=os.environ["MESSAGE"],
)

print(response["message"]["text"])
```

Add a GitHub Actions step in your workflow to execute the notification script:

```yaml
jobs:
  deployment:
    runs-on: ubuntu-latest
    steps:
      # ... previous steps for deployment ...
      
      - name: Notify Slack Channel
        env:
          SLACK_API_TOKEN: ${{ secrets.SLACK_API_TOKEN }}
          CHANNEL_ID: 'your-channel-id'
          MESSAGE: "*Deployment Update*\nImage: ${{ steps.build.outputs.IMAGE_URL }}\nURL: ${{ steps.deploy.outputs.WEBSITE_URL }}"
        run: |
          pip install slack_sdk
          wget -qO- https://raw.githubusercontent.com/tbscode/tims-blog-posts/main/assets/send_slack_message.py | python3 -
```

Replace `your-channel-id` with the actual Slack channel ID where you wish to send notifications. 

> Replace the script url with a self hosted fork of [send_slack_message.py](https://github.com/tbscode/tims-blog-posts/blob/main/assets/send_slack_message.py)

Remember to update the `MESSAGE` variable with relevant details for your deployment, such as image URL or site URL.

Executing the GitHub Action with these configurations will automatically send your predefined message to the designated Slack channel, informing your team about the latest deployment status.

Your GitHub Actions workflow now works seamlessly with Slack for real-time notifications!

Set up Slack notifications for deployments using GitHub Actions and the Python slack_sdk package, keeping your team updated automatically.

Latest Posts

Self-Hosted n8n on Kubernetes (Helm chart)

Self-Hosted Uptime Monitoring on Kubernetes with Uptime-Kuma

WordPress on Kubernetes with TrueCharts (short guide)

Comparison of Video Call Services for Cross-Platform React Web/Native Apps

Full Setup Guide: Lenovo Yoga 9 Pro with Regolith Linux (Ubuntu 23.10 + i3)

Send Slack Notifications on Deployments with GitHub Actions