Forem: Sibelius Seraphini

Creating a Certificate X.509 expiration Dashboard using Grafana

Sibelius Seraphini — Mon, 05 Jan 2026 12:49:08 +0000

At Woovi, we need to manage many X.509 certificates that are not only related to site domains. We have certificates that enable mTLS connections, allow us to sign ISO 20022 XML messages, and provide some A1 and A3 certificates to emit electronic invoices (notas fiscais) and access certain Central Bank and government systems.

Current state of certificate expiration tools

Most certificate expiration tools are focused on renewing site domain certificates. My problem is just to check the expiration of X.509 without auto-renew, as the renewal process requires a real person verification.

x509-certificate-exporter + Grafana Dashboard

x509-certificate-exporter is a Prometheus exporter that can read X.509 certificates from many sources, like files, Kubernetes configs, and secrets.

Here is a basic deployment to watch files

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: x509-certificate-exporter
  name: x509-certificate-exporter
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
  selector:
    matchLabels:
      app: x509-certificate-exporter
  template:
    metadata:
      labels:
        app: x509-certificate-exporter
    spec:
      containers:
        - name: x509-certificate-exporter
          image: enix/x509-certificate-exporter:latest
          ports:
            - containerPort: 9793
          volumeMounts:
            - name: certs
              mountPath: /etc/certs
              readOnly: true
          args:
            - --debug
            - --watch-dir=/etc/certs
      volumes:
        - name: certs
          configMap:
            name: x509-certificates

We are going to use Kustomization to generate the configmaps from X.509 files.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: x509-certificate-exporter

resources:
- deployment.yaml

configMapGenerator:
  - name: x509-certificates
    files:
      - ./certs/cert-a.crt
      - ./certs/cert-b.crt

Apply this kustomization like this kubectl apply -k /deployments/x509-certificate-exporter

Add this Grafana dashboard Certificates Expiration (X509 Certificate Exporter) and you are all set.

In Conclusion

Kubernetes, Prometheus, and Grafana are versatile tools that enable you to build a custom dashboard to solve common problems in many companies.
Set this up in your company and avoid having certificate expiration issues forever.
The next step would be to set up alerts to renew certificates before the expiration date.

What monitoring solutions are you using in your company?

Woovi
Woovi is a fintech platform revolutionizing how businesses and developers handle payments in Brazil. Built with a developer-first mindset, Woovi simplifies integration with instant payment methods like Pix, enabling companies to receive payments seamlessly and automate financial workflows.

If you want to work with us, we are hiring!

Saving Terraform State in S3

Sibelius Seraphini — Thu, 04 Dec 2025 12:55:08 +0000

Terraform is a solution to provision infrastructure using code (IaC).
Terraform stores the infrastructure generated in a state.
This state maps the real world and metadata to Terraform.
This ensures that you won't duplicate or recreate existing resources.

Storing Terraform State in an S3 bucket

You can use S3 as the backend of the state like this

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0"
    }
  }
  required_version = ">= 1.0"

  backend "s3" {
    bucket                  = "terraform-state-dev"
    key                     = "my-key"
    region                  = "us-east-1"
    shared_credentials_file = "~/.aws/credentials"
  }
}

You can have a single key to store all your Terraform state, or you can have one key for each Terraform state.

You can start your Terraform using terraform init

After any terraform apply or terraform apply the state in your S3 will be updated.

At Woovi, we decided to have one key per Terraform provision.

How to migrate existing local state?

You can use this command to migrate existing local or another backend state to your S3 bucket

terraform init -migrate-state

In Resume

If you lose your Terraform state, this can cause significant trouble.
Keeping them in an S3 bucket can make it shareable across your team.

If you want to work with us, we are hiring!

Creating a S3 bucket using Terraform

Sibelius Seraphini — Wed, 03 Dec 2025 10:17:55 +0000

S3 is the de facto and most well-known solution for object storage.
Object storage allows you to store files in a specific bucket and key.

When your application is small, you just need to manage a few S3 buckets, and you can manage them using the AWS UI.

The problem is how to reproduce the same S3 bucket configuration over and over again, and from staging to production.
Each S3 bucket has specific needs.

It is also hard to see how all the S3 buckets are configured or how to change some configurations.

S3 using Terraform

Terraform enables you to declare your infrastructure as code.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0"
    }
  }
  required_version = ">= 1.0"
}

provider "aws" {
  region = "us-east-1"
}

# Create S3 bucket for Terraform state
resource "aws_s3_bucket" "mybucket" {
  bucket = "mybucket"

  force_destroy = false

  tags = {
    Name        = "mybucket"
    Environment = "dev"
    ManagedBy   = "terraform"
  }
}

# Enable versioning (so you can roll back state if needed)
resource "aws_s3_bucket_versioning" "versioning" {
  bucket = aws_s3_bucket.mybucket.id

  versioning_configuration {
    status = "Enabled"
  }
}

# Enable server-side encryption by default
resource "aws_s3_bucket_server_side_encryption_configuration" "sse" {
  bucket = aws_s3_bucket.mybucket.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# Block public access
resource "aws_s3_bucket_public_access_block" "block" {
  bucket = aws_s3_bucket.mybucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

You just need to type

terraform init
terraform apply

And your S3 bucket is created.

If you modify your Terraform file and run terraform apply , it will show what changed and only apply the modifications.

In Conclusion

Using Terraform to provision your infrastructure can help you go from simple S3 buckets to very complex applications.

If you want to work with us, we are hiring!

Copy and Paste on Proxmox VM

Sibelius Seraphini — Tue, 02 Dec 2025 10:52:48 +0000

Copy and paste does not work well on Proxmox KVM on the UI.
You can try to connect using a serial port to enable copy and paste over the UI.

Using a Script

We created a script to simulate keyboard typing and paste data over KVM when using the UI.

Open your Chrome Dev Tools, and paste this.

function simulateKeyEvent(el, eventType, key, options = {}) {
  const evt = new KeyboardEvent(eventType, { key, ...options });
  el.dispatchEvent(evt);
}

const sendKey = (char) => {
  let capsLockOn = false;
  const SHIFT_NEEDED = /[A-Z!@#$%^&*()_+{}:"<>?~|]/;

  const canvas = document.querySelector("canvas");

  canvas.focus();

  if (char === '\n') {
    simulateKeyEvent(canvas, "keydown", "Enter");
    simulateKeyEvent(canvas, "keyup", "Enter");
  } else {
    const needsShift = SHIFT_NEEDED.test(char);
    const isUpperCase = char >= 'A' && char <= 'Z';

    if (needsShift) {
      simulateKeyEvent(canvas, "keydown", "Shift", { keyCode: 16 });
    }

    if (isUpperCase && capsLockOn) {
      simulateKeyEvent(canvas, "keydown", char.toLowerCase());
      simulateKeyEvent(canvas, "keyup", char.toLowerCase());
    } else {
      simulateKeyEvent(canvas, "keydown", char);
      simulateKeyEvent(canvas, "keyup", char);
    }

    if (needsShift) {
      simulateKeyEvent(canvas, "keyup", "Shift", { keyCode: 16 });
    }

    if (char === "CapsLock") {
      capsLockOn = !capsLockOn;
      console.log("Caps Lock state changed:", capsLockOn);
    }
  }
};

function cp(text) {
  let index = 0;

  function typeChar() {
    if (index < text.length) {
      sendKey(text[index]);
      index++;
      setTimeout(typeChar, 100); // Adjust delay as needed
    }
  }

  typeChar();
}

To paste something, you first need to focus on the UI, and then type cp('mydata')

You can use this when you don't have access to the VM over SSH.

In Summary

If you are creative enough, you can solve these limitations.

If you want to work with us, we are hiring!

Using Terraform to create LXC in Proxmox

Sibelius Seraphini — Mon, 01 Dec 2025 11:40:44 +0000

Terraform is a well-known solution for defining, provisioning, and managing Infrastructure as Code (IaC).
Most of the content out there focuses on major clouds as AWS, GCP, and Azure.
I'd like to focus on Proxmox, an open source hypervisor used in a lot of home labs and also in production for companies that follow the baremetal approach, like Woovi.

Proxmox Infrastructure

Proxmox is a virtualization platform. You can create VMs and LXC (Linux Containers) using the UI, but when your team grows, and you want to be able to reproduce the same staging environment at production, you need to use IaC.
IaC is also great to make sure something is reproducible.

VMs vs LXC

You can think of LXC as simpler and lighter VMs.
LXC provides less isolation, and some software can't run on top of it easily, like microk8s nodes.
We are going to focus on LXC to make this article simpler.

Provisioning using Terraform

You can have the whole definition in the same file or split it into many files in the same folder.

First, define the provider Proxmox from Telmate.

Also, define the Proxmox provider variable like api_url, token ID, and token secret.
You can follow this documentation terraform for proxmox to generate the token ID and token secret.

terraform {
  required_providers {
    proxmox = {
      source  = "telmate/proxmox"
      version = "3.0.2-rc04"
    }
  }
}

provider "proxmox" {
  pm_api_url = "https://myproxmoxnode:8006/api2/json"
  pm_tls_insecure = true
  pm_log_enable = true
  pm_debug      = true
  pm_api_token_id = var.PM_API_TOKEN_ID
  pm_api_token_secret = var.PM_API_TOKEN_SECRET
  pm_log_levels = {
    _default    = "debug"
    _capturelog = ""
  }
}

variable "PM_API_TOKEN_ID" {}
variable "PM_API_TOKEN_SECRET" {}

define the LXC resource

resource "proxmox_lxc" "mongo-1" {
  target_node = "dev1"
  hostname    = "mongo1"
  ostemplate  = "local:vztmpl/ubuntu-24.04-standard_24.04-2_amd64.tar.zst"
  password    = var.LXC_PASSWORD

  unprivileged = true

  cores   = 1
  memory  = 512
  swap    = 512

  rootfs {
    storage = "local-lvm"
    size    = "50G"
  }

  network {
    name   = "eth0"
    bridge = "vmbr0"
    ip     = "10.99.90.2/16"
    gw     = "10.99.0.3"
  }

  ssh_public_keys = file("~/.ssh/id_ansible.pub")

  start = true
}

Run ini to initialize Terraform

terraform init

Run apply to provision the lxc resource

terraform apply

Run destroy to destroy everything

terraform destroy

In this setup, you need to save the local Terraform files to avoid recreating the resources. For production, the best approach is to keep Terraform state in an S3 bucket

In Conclusion

You don't need to start your MVP Startup using Terraform to provision everything in your Proxmox.
My recommendation is to keep improving automation as you and your team grow.
After you get the first Terraform working, the rest gets easier.

How are you using Terraform in your company?

If you want to work with us, we are hiring!

A Modern Node.js + TypeScript Setup for 2025 🚀

Sibelius Seraphini — Wed, 29 Jan 2025 11:06:32 +0000

With the latest features and tools in Node.js, setting up a modern TypeScript project has never been easier—or more exciting. This guide will show you how to leverage the newest Node.js capabilities to create a lightweight and efficient development workflow.

Why Choose This Setup?

This setup emphasizes simplicity, native features, and minimal dependencies by leveraging:

Native ESM (ECMAScript Modules) for cleaner, modern syntax.
Experimental TypeScript Stripping (--experimental-strip-types) for running TypeScript files natively.
Built-in File Watching without third-party tools like nodemon
Native Environment Variable Support with .env files

Explore the repo for this setup: esm-pure-experimental-strip-types.

Node.js ESM

ECMAScript Modules (ESM) bring modern syntax with import and export.

Benefits of ESM:

Performance: Static analysis of imports/exports improves optimization compared to CommonJS (CJS).
Simplified Module Resolution: Requires explicit file extensions, speeding up module resolution. For example, instead of:

const module = require('./module');

You now write:

import module from './module.js';

Experimental TypeScript stripping (--experimental-strip-types)

The --experimental-strip-types flag lets you run .ts files directly in Node.js, eliminating the need for transpilers like Babel or SWC. Here's how to use it:

node --experimental-strip-types index.ts

Requirements:

Use ESM syntax.
Include explicit file extensions (e.g., .ts) in imports.

Here’s a sample tsconfig.json to get you started:

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "Node",
    "strict": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true,
    "isolatedModules": true,
    "resolveJsonModule": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "noEmit": true,
    "types": ["node"],
    "allowImportingTsExtensions": true,
    "verbatimModuleSyntax": true,
    "incremental": true
  },
  "include": ["src/**/*.ts"],
  "exclude": ["node_modules", "dist"]
}

Key Configurations:

allowImportingTsExtensions: Ensures .ts extensions are required in imports.
verbatimModuleSyntax: This avoids altering your import/export syntax. By using --experimental-strip-types, you can bypass tools like Babel, SWC, Webpack, or TSX, streamlining your toolchain significantly.

Built-in File Watching (--watch)

Forget nodemon! Node.js now supports file watching natively. Use the --watch flag for live reloads:

node --watch index.ts

Benefits:

Faster and more efficient than nodemon.
Native support means fewer dependencies.

Native Environment Variable Support (--env-file)

You no longer need packages like dotenv or dotenv-safe to handle .env files. Simply use the --env-file flag:

node --env-file=.env index.ts

Advantages:

Seamless integration with .env files.
Fully native functionality, reducing dependency bloat.

Closing Thoughts

This modern Node.js + TypeScript setup eliminates unnecessary complexity by leveraging the latest features. With native ESM, experimental TypeScript stripping, built-in file watching, and .env support, you can:

Reduce dependencies.
Improve performance.
Simplify your workflow.

By embracing these tools, you’ll boost productivity and focus on building, not configuring.

What are your favorite Node.js + TypeScript features? Let me know in the comments!

Woovi is a fintech platform revolutionizing how businesses and developers handle payments in Brazil. Built with a developer-first mindset, Woovi simplifies integration with instant payment methods like Pix, enabling companies to receive payments seamlessly and automate financial workflows.

If you want to work with us, we are hiring!

"ngrok" from scratch

Sibelius Seraphini — Tue, 28 Jan 2025 11:19:07 +0000

Introduction

ngrok is a fantastic tool for exposing local servers to the internet with minimal effort. However, it’s not always an ideal choice due to cost, licensing, or privacy concerns. In this article, we’ll recreate ngrok-like functionality using open-source tools: NGINX, Kubernetes, Docker, and OpenSSH. By the end, you'll have a custom, self-hosted tunnel that forwards traffic from the internet to your local machine.

Here’s a high-level overview of the architecture:

Woovi’s Specific Needs for Tunneling

At Woovi, we developed a Shopify payment app that requires fixed URLs during development. Using ngrok presented a challenge because each developer generated a unique URL. Changing these URLs required re-submitting for Shopify’s review, even for development, causing significant delays.

To solve this problem, we created a solution that allows any developer to forward their local server to a consistent, custom domain, such as shopify.ourdomain.com. This eliminated the URL change issue, saving valuable time and improving the development workflow.

Setting Up OpenSSH + NGINX

The first step is to create a Docker image that includes both OpenSSH and NGINX. OpenSSH allows remote SSH connections, while NGINX will handle HTTP traffic forwarding.

Dockerfile

FROM alpine:latest

RUN apk add --no-cache \
    openssh \
    nginx \
    bash && \
    mkdir -p /run/nginx && \
    mkdir -p /root/.ssh

# Generate SSH host keys
RUN ssh-keygen -A

# Set the root password to '123456'
RUN echo "root:woovi" | chpasswd

RUN mkdir /var/run/sshd && \
    ssh-keygen -A && \
    echo "PermitRootLogin yes" >> /etc/ssh/sshd_config && \
    echo "PasswordAuthentication yes" >> /etc/ssh/sshd_config && \
    echo "GatewayPorts yes" >> /etc/ssh/sshd_config && \
    echo "AllowTcpForwarding yes" >> /etc/ssh/sshd_config && \
    echo "PermitOpen any" >> /etc/ssh/sshd_config && \
    echo "MaxAuthTries 6" >> /etc/ssh/sshd_config && \
    echo "UseDNS no" >> /etc/ssh/sshd_config && \
    echo "AllowUsers root" >> /etc/ssh/sshd_config && \
    echo "TCPKeepAlive yes" >> /etc/ssh/sshd_config && \
    echo "ClientAliveInterval 60" >> /etc/ssh/sshd_config && \
    echo "ClientAliveCountMax 3" >> /etc/ssh/sshd_config && \
    sed -i '/^AllowTcpForwarding no$/d' /etc/ssh/sshd_config


# Create SSH directory for root user and set permissions
RUN mkdir -p /root/.ssh && chmod 700 /root/.ssh

RUN touch /root/.ssh/authorized_keys

COPY authorized_keys /root/.ssh/authorized_keys
RUN chmod 600 /root/.ssh/authorized_keys

COPY nginx.conf /etc/nginx/nginx.conf

# Expose port 22 for SSH
EXPOSE 22 80

# Start the SSH service
CMD /usr/sbin/sshd && nginx -g "daemon off;"

This Dockerfile sets up an OpenSSH server alongside NGINX and exposes two ports:

Port 22: For SSH connections.
Port 80: For NGINX HTTP traffic.

nginx.conf

user nginx;
worker_processes auto;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;

    server {
        listen 80;
        set_real_ip_from 0.0.0.0/0;

        server_name woovi-ssh;

        location / {
            proxy_pass http://localhost:5001;
        }
    }
}

This configuration forwards all HTTP requests on port 80 to a local service running on port 5001. You’ll use this setup to forward traffic from your local machine to the remote server.

Forwarding Your Localhost to the Remote Server

Once the Docker container is deployed, you can forward your local server to the remote server using an SSH remote port forward. Run the following command:

ssh -R 5001:localhost:5001 root@myowndomain.com

This command forwards requests from the remote server’s 5001 port to your local machine’s 5001 port. For example, accessing http://myowndomain.com/anypath will route traffic to http://localhost:5001/anypath on your machine.

Summary

By combining NGINX, OpenSSH, and Docker, you’ve created a self-hosted alternative to ngrok. This solution gives you complete control over your traffic without relying on third-party services, making it ideal for privacy-conscious developers and teams with specific tunneling needs.

Have you tried this setup? Let us know how it worked for you or share any questions in the comments!

If you want to work with us, we are hiring!

How to self-host any open source service?

Sibelius Seraphini — Mon, 27 Jan 2025 11:23:45 +0000

Self-hosting an open-source service can provide greater control, privacy, and customization options than managed services. Kubernetes (K8s) is a powerful orchestration tool that simplifies deploying, scaling, and managing containerized applications.

This is a practical of getting an open-source self-hosted service and deploying to a k8s cluster. We recommend searching and trying in this respective order:

Helm Chart

Search for an existing Helm Chart for the service that you want to self-host. Search like: <service> helm chart
Helm Charts are like packages for k8s.
You just need to setup a values.yaml to customize to your own needs.

Imagine that I want to self-host n8n service.
I found the n8n helm chart

You create a folder inside deployment/n8n

and you create 2 files

Chart.yaml

apiVersion: v2
name: n8n
version: 1.0.0
dependencies:
  - name: n8n
    repository: oci://8gears.container-registry.com/library
    version: 0.25.2

and

values.yaml

config:
  database:
    type: postgresdb
    postgresdb:
      host: pg.n8n
      database: n8n
      user: n8n
      password: safepassword
image:
  tag: '1.73.1'

You can just run helm install to install your chart to a k8s cluster.

helm install n8n ./deployments/n8n -f ./deployments/n8n/values.yaml -n n8n

You could also use ArgoCD to sync it if you are using GitOps.
Check how to setup ArgoCD in this article: Bootstrapping ArgoCD with Helm and Helmfile

If this didn't work in the first try, check pods, check logs, modify values.yaml, read the yamls of the helm chart to understand what is breaking

Pure Kubernetes setup

If you didn't get luck to fine a good helm chart or any helm chart for the service you want to self host, try to search only by <service> kubernetes

If you file, just copy the yamls files and modify them to your use case. It probably gonna have at least one deployment and one service file.

Docker Compose

If there is no resource about self hosting the service using kubernetes, let's fallback to docker compose. Search like this: <service> docker compose.
If you find a docker-compose.yaml file, read it to understand all the services that are required to run the service you want to self host.
You can remove any optional service to simplify your setup, and add them back later on.
I recommend having some shared resources like databases in a different deployment so you can reuse ithem n different self-hosted services.
This makes self-hosting faster, easier, and cheaper.
Do not reuse resources/services if this is a critical production service.

You need to translate the docker-compose to k8s yamls, you can use chatgpt if you don't know how to translate, but it will be mostly some deployments and some services. Or try Kompose.io.

Here is an example of deployment of n8n based on a docker-compose.yaml

n8n-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: n8n
  name: n8n-server
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
  selector:
    matchLabels:
      app: n8n-server
  template:
    metadata:
      labels:
        app: n8n-server
    spec:
      containers:
        - name: n8n-server
          image: docker.n8n.io/n8nio/n8n:latest
          imagePullPolicy: Always
          resources:
            requests:
              cpu: 100m
          ports:
            - containerPort: 5678
          envFrom:
            - secretRef:
                name: n8n-secrets

n8n-service.yaml

apiVersion: v1
kind: Service
metadata:
  namespace: n8n
  name: n8n-server
spec:
  selector:
    app: n8n-server
  ports:
    - protocol: TCP
      port: 5678
      targetPort: 5678

apiVersion: v1
kind: Secret
metadata:
  name: n8n-secrets
  namespace: n8n
stringData:
   N8N_HOST: "n8n.dev.to"

The deployment will run a number of instances of n8n, and service will enable us to expose to a nginx/ingress or loadbalancer.
Keep all secrets in a secret config or use a vault solution.
You can also self-host a vault solution.

Docker

Follow the same steps as docker compose, and transform a single docker image in 1 deployment and 1 service like above changing the image to your service docker image.

None of the above

If your service does not even have a docker image, you can create a Dockerfile from scratch to create an image.
You can host this image in any docker registry.
You can also self-host the docker registry.

Conclusion

By following these steps, you can self-host any open-source service using Kubernetes, giving you full control and flexibility. While Kubernetes has a learning curve, the long-term benefits of scalability, reliability, and customization make it worth the effort

What services does not fit any of the above?

If you want to work with us, we are hiring!

Bootstrapping ArgoCD with Helm and Helmfile

Sibelius Seraphini — Fri, 24 Jan 2025 10:48:01 +0000

Bootstrapping ArgoCD with Helm and Helmfile

ArgoCD is a powerful tool for managing GitOps workflows in Kubernetes. Combining it with Helm and Helmfile streamlines the setup process, enabling version-controlled configurations and better automation.

In this article, we’ll walk through setting up ArgoCD using Helm and managing it with Helmfile for an efficient and maintainable deployment process.

Why Use Helm and Helmfile for ArgoCD?

Helm simplifies application packaging and deployment in Kubernetes.
Helmfile extends Helm by managing multiple Helm charts and their configurations declaratively.
Combining Helmfile and Helm for ArgoCD ensures consistent and reproducible setups, especially in environments with multiple clusters or teams.

Prerequisites

Before starting, ensure the following are in place:

A Kubernetes cluster.
Helm installed (helm version).
Helmfile installed (helmfile version).
A Git repository to store your Helmfile and values files.

Step 1: Add the ArgoCD Helm Repository

First, add the official ArgoCD Helm repository:

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

Step 2: Create a helmfile.yaml

Create a helmfile.yaml to manage the ArgoCD Helm chart. Here’s a basic example:

repositories:
  - name: argo
    url: https://argoproj.github.io/argo-helm

releases:
  - name: argocd
    namespace: argocd
    createNamespace: true
    chart: argo/argo-cd
    version: ~5.46.0  # Specify the desired version
    values:
      - values/argocd-values.yaml

Step 3: Define Values for ArgoCD

In the values/argocd-values.yaml file, customize the ArgoCD configuration. Example:

argo-cd:
  dex:
    enabled: false
  notifications:
    enabled: false
  applicationSet:
    enabled: false
  server:
    extraArgs:
      - --insecure

Adjust these values based on your environment, such as enabling ingress or setting up replicas for HA.

Step 4: Deploy ArgoCD with Helmfile

Run the following command to deploy ArgoCD:

helmfile apply

This will:

Create the argocd namespace (if not already existing).
Install or upgrade the ArgoCD Helm chart using the specified values.

Step 5: Verify the Installation

Check the status of the deployment:

kubectl get pods -n argocd

Access the ArgoCD UI (replace LoadBalancer or ingress domain accordingly):

kubectl port-forward svc/argocd-server -n argocd 8080:443

The default username is admin, and the password can be fetched using:

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

Step 6: Manage Configuration with GitOps

Now that ArgoCD is set up, you can manage your Kubernetes applications declaratively using Git repositories.

Advantages of Using Helmfile for ArgoCD

Centralized Configurations: All charts and values are in one file, making it easy to track changes.
Reproducibility: Deployments are consistent across environments.
Multi-environment Support: Define multiple environments (e.g., dev, staging, production) in a single Helmfile.

Final Thoughts

Bootstrapping ArgoCD with Helm and Helmfile is a powerful way to simplify and streamline GitOps workflows. With the declarative nature of Helmfile, you can easily manage and version-control your ArgoCD setup, ensuring smooth operations across your Kubernetes clusters.

Feel free to extend this setup further by incorporating secrets management tools, custom plugins, or CI/CD pipelines for automated deployments.

Did you find this guide helpful? Share your thoughts or tips for improving the ArgoCD setup using Helm and Helmfile in the comments!

If you want to work with us, we are hiring!

Sharing a Redis using a Prefix

Sibelius Seraphini — Thu, 23 Jan 2025 11:07:24 +0000

Using Bull Prefix to Isolate Jobs Between Developers

When developers share resources from staging to develop locally, issues can arise, particularly when using shared Redis instances and Bull for distributed jobs. For instance, one developer might unintentionally consume jobs created by another, leading to conflicts and confusion.

To learn more about the benefits of leveraging staging services in development, check out this detailed guide: Enhancing DX by Using Staging Services in Development.

One effective solution to this problem is using job prefixing. This strategy allows each developer to have their namespace or prefix for jobs, ensuring that jobs created by one developer are only processed by their workers. Here's how you can implement this:

Why Use Job Prefixes?

Prevent Job Conflicts: Multiple developers may add jobs to the same queue without realizing it, leading to a mix-up of jobs.
Isolation of Developer Work: Each developer can have a unique prefix that only their jobs can be consumed by their workers.
Scalability: As the project grows and more developers work with queues, job prefixes help keep things organized.
Cost-Effective: Eliminates the need to spin up a new Redis instance for every developer.

Using Bull Prefixing for Job Isolation

Bull, a popular queue system for Node.js, supports prefixes for queue and job names, allowing you to easily create isolated queues for each developer.

By leveraging this feature, you can ensure that developers working in parallel don’t interfere with one another. Here’s how you can implement this approach:

Enabling Prefixing with BULL_DEV_PREFIX

Using process.env as feature flags is a common practice for enabling or disabling experimental or development-only features. If you're unfamiliar with this approach, check out this guide: Using process.env as Feature Flags

To simplify the configuration for developers, you can introduce an environment variable (BULL_DEV_PREFIX) in their local .env file. This prefix ensures that all jobs created by a developer will only be consumed by their workers. If no prefix is set, jobs will remain accessible to others, including staging.

This setup is particularly useful when testing new job implementations without affecting shared queues.

Example Implementation:

const getDevPrefix = () => {
  if (process.env.BULL_DEV_PREFIX) {
    return {
      prefix: process.env.BULL_DEV_PREFIX,
    };
  }

  return {};
};

const myQueue =new Queue('MY_QUEUE', config.REDIS_HOST, {
    ...getDevPrefix(),    
})

In this example:

The BULL_DEV_PREFIX variable is read from the environment.
If set, the prefix is applied to the queue, ensuring isolation.
If not set, the queue behaves normally, allowing staging and other developers to interact with it.

Diagram with before and after the solution

Conclusion

Using Bull prefixes is a simple and effective way to improve collaboration in a multi-developer environment. It ensures:

Developers can work independently on shared queues.
Conflicts are avoided.
Staging resources are utilized efficiently.
This approach boosts workflow efficiency and scalability, allowing teams to focus on development without stepping on each other’s toes.

If you want to work with us, we are hiring!

Photo by cottonbro studio

Enhancing DX by Using Staging Services in Development

Sibelius Seraphini — Wed, 22 Jan 2025 11:20:39 +0000

Complexity as You Grow

When starting with the MVP (Minimal Viable Product) of your startup, your repository is small, typically with one backend and one frontend. Initially, you'll have limited code files, endpoints, pages, dependencies, and services. However, as your startup grows, so will everything—files, endpoints, pages, dependencies, and services. This growth can slow down your compilation, bundling, and feedback loop during development, and increase CPU and memory usage as external services accumulate.

Staging for Backend Services

A key optimization is to move all services to a staging environment and have all developers use the same services locally—like MongoDB, Elasticsearch, Redis, and others. This ensures consistency while reducing local overhead.

Isolating Work for Specific Endpoints

Rather than running the entire application, developers typically focus on specific endpoints or services. Why not let them work on just those parts without the need to run the whole project? Here's an example of how to achieve this:

export const getDevKoaApp = (router): Koa => { 
   const app = new Koa({
    proxy: true, // we are behind a proxy
    keys: [process.env.JWT_KEY], // used for cookies sign
  });

  // add koa middleware

  // use router that will be used to run local code
  app.use(router.routes()).use(router.allowedMethods());

  // proxy all the other requests to staging
  app
    .use(routerStagingProxy.routes())
    .use(routerStagingProxy.allowedMethods()); 
}

getDevKoaApp receives a router with only the endpoints the developer is working on.
routerStagingProxy forwards any requests not handled locally to the staging environment.

Here's the implementation of routerStagingProxy:

routerStagingProxy.all(
  '/(.*)',
  async (ctx, next) => {
    const url = `${staging}${ctx.request.path}`;

    // eslint-disable-next-line
    console.log('proxying to staging: ', url, ctx.request.method);

    if (ctx.request.body?.operationName) {
      // eslint-disable-next-line
      console.log(ctx.request.body?.operationName);
    }
    await next();
  },
  koaProxy2({
    host: staging,
    suppressRequestHeaders: forbiddenHeaders,
    logLevel: 'debug',
    secure: false,
    changeOrigin: true,
    onProxyReq(proxyReq, ctx) {
      for (const header of forbiddenHeaders) {
        proxyReq.removeHeader(header);
      }
    },
  }),
);

This setup forwards all endpoints that aren’t running locally to staging.

Staging for Frontend Services

For frontend services, you can just define the apiBaseUrl that will forward the request from local to staging

We are using Rspack for his.

devServer: {
  proxy: [
  {
    context: ['/console']
    secure: false,
    changeOrigin: true,
    cookieDomainRewrite: 'localhost',
    target: apiBaseUrl,
    onProxyReq: (proxyReq) => {
      // Browers may send Origin headers even with same-origin
      // requests. To prevent CORS issues, we have to change
      // the Origin to match the target URL.
      if (proxyReq.getHeader('origin')) {
        proxyReq.setHeader('origin', apiBaseUrl);
      }
    },
  }
 ] 
}

Why Forward Services to a Staging Environment?

Developing locally against a staging environment has several advantages:

Access to Real Data: You can test features with near-production data without replicating databases or APIs locally.
Consistent Environment: Avoid issues where "it works on my machine" but fails in staging due to environment differences.
Faster Iterations: Skip the setup time for heavy services locally, focusing instead on core application logic.

Summary

As your product scales, adding more services, endpoints, and frontends can overwhelm your developers. Forwarding services from local to staging provides a seamless developer experience—developers can work locally as if they’re running everything, without the overhead of managing all services.

How are you scaling your codebase as your product grows? Let me know!

If you want to work with us, we are hiring!

Photo by Nastya Dulhiier on Unsplash

Optimizing SSH Connections

Sibelius Seraphini — Tue, 21 Jan 2025 12:05:28 +0000

As we move to remote development, we need to optimize SSH connections.
SSH (Secure Shell) is an essential tool for securely managing remote systems. However, its performance and usability can be significantly improved with a few tweaks. Here's how:

Using an SSH Config File

The SSH config file (~/.ssh/config) allows you to simplify and optimize your SSH connections. Instead of repeatedly typing lengthy commands, you can define settings for each host.

Host myserver
  HostName 192.168.1.100
  User myuser
  Port 22
  IdentityFile ~/.ssh/id_rsa
  Compression yes
  ServerAliveInterval 60
  ServerAliveCountMax 3
  LogLevel QUIET

Benefits:
Ease of Use: Simplify commands with aliases (e.g., ssh myserver).
Performance: Enable compression for faster transfers, especially over slow connections.
Stability: Avoid disconnections with ServerAliveInterval and ServerAliveCountMax

SSH Multiplexing

Multiplexing reuses existing SSH connections for multiple sessions, reducing authentication overhead and improving speed for subsequent logins.

Host *
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m

Explanation:
ControlMaster auto: Enables multiplexing.
ControlPath: Defines a socket file for reusing connections.
ControlPersist 10m: Keeps the connection open for 10 minutes after the session ends.

Automating LocalForward and RemoteForward

Port forwarding is a powerful SSH feature for securely tunneling traffic. Automating it in the config file ensures consistency and saves time.

LocalForward:
Use LocalForward to forward a local port to a remote service:

Host myserver
  LocalForward 8080 127.0.0.1:80

Access a remote web server running on port 80 via localhost:8080.
RemoteForward:
Use RemoteForward to expose a local service to the remote host:

Host myserver
  RemoteForward 9090 127.0.0.1:3306

Expose a local MySQL instance running on port 3306 to the remote host's port 9090.

Using AutoSSH for Persistent Connections

AutoSSH is a utility that automatically restarts SSH sessions if they get disconnected, ensuring a persistent, fault-tolerant connection. It’s particularly useful for remote systems that require continuous monitoring or tunneling, like when you are maintaining a VPN-like setup using SSH tunnels or monitoring remote systems.

autossh -M 0 -f -N -T -L 8080:localhost:80 myserver

with SSH config

Host myserver
  HostName 192.168.1.100
  User myuser
  IdentityFile ~/.ssh/id_rsa
  LocalForward 8080 127.0.0.1:80
  RemoteForward 9090 127.0.0.1:3306
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m
  ProxyCommand autossh -M 0 -f -N -T -L 8080:localhost:80 %h

Conclusion

By leveraging SSH configuration files, enabling multiplexing, and automating forwarding options, you can significantly enhance your SSH workflow. These tweaks reduce repetitive tasks, improve connection speed, and make remote management seamless.

Optimize your setup today and enjoy faster, more efficient SSH connections!

If you want to work with us, we are hiring!