DEV Community: Woovi

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!

Understanding IMAP and SMTP Mail Protocols

Lucas Aguiar — Sat, 26 Jul 2025 01:48:38 +0000

During a recent implementation of a customer service platform, I encountered several configuration challenges related to email communication protocols. This experience prompted me to conduct thorough research into SMTP and IMAP protocols, their interactions, and best implementation practices. The knowledge gained proved invaluable for resolving our technical issues, and I'm sharing these insights to benefit others facing similar challenges in their systems architecture.

📮 Introduction

In the digital world, sending and receiving emails are fundamental communication processes. During my recent experience, I realized that understanding how these protocols work behind the scenes can make all the difference, especially when configuring or troubleshooting customer service systems.

🌐 Overview of Email Protocols

Emails travel between computers using standardized protocols. The most common ones are:

SMTP (Simple Mail Transfer Protocol): Used for sending messages
IMAP (Internet Message Access Protocol): Used for accessing and managing messages stored on the server

While POP3 also exists, this article focuses on SMTP and IMAP, which offer advantages for synchronization and email management across multiple devices.

📤 SMTP - Simple Mail Transfer Protocol

SMTP is the "engine" that sends emails. Here's a summary of what I learned:

Primary Function: SMTP is responsible for sending messages from the sender to the server, and between servers, ensuring the email reaches its recipient.
How It Works:
- The process begins with the email client sending the message to the SMTP server
- Commands like EHLO/HELO, MAIL FROM, RCPT TO, and DATA structure this communication
Ports and Security:
- Common ports include 25 (traditional) and 587 (for authenticated sending)
- Using TLS or SSL encryption is highly recommended to protect data during transmission

📥 IMAP - Internet Message Access Protocol

While SMTP handles sending, IMAP is the "manager" of received emails:

Primary Function: IMAP allows you to access and manage emails directly on the server. This means that regardless of which device you use—smartphone, tablet, or computer—your messages remain synchronized.
Advantages over POP3:
- Messages remain stored on the server, allowing viewing and organization from any device
- You can create, move, and delete folders directly on the server without downloading emails
How It Works:
- IMAP synchronizes message status (e.g., read/unread) and organizes emails into folders
Ports and Security:
- Port 143 is used for unencrypted connections, while port 993 is for secure connections via SSL/TLS

⚖️ Comparison Between SMTP and IMAP

Although both protocols are part of email communication, they have distinct, complementary roles:

SMTP:
- Responsible for sending emails
- Functions as the "digital mail carrier" distributing messages between servers
IMAP:
- Responsible for accessing and managing stored messages
- Allows you to track your emails in a synchronized manner across multiple devices

⚙️ Technical Aspects and Implementation

During my experience, I found that visualizing the email flow helps better understand how these protocols interact:

Sending and Receiving Flow:
- The email leaves the client and goes to the SMTP server
- From there, it may be forwarded to other servers until it reaches the recipient's server
- Finally, the email client uses IMAP to access and manage this message on the server
Configuration and Authentication:
- Correctly configuring ports and authentication methods (such as TLS/SSL) is essential to ensure everything works smoothly
- In many situations, the challenge lies precisely in aligning these configurations for efficient and secure customer service operation

🔒 Security and Best Practices

To avoid headaches (like the one I faced), it's important to pay attention to these points:

Common Threats:
- Without proper security, data can be intercepted during transmission
- Configuration errors can create vulnerabilities for spam or even more serious attacks
Security Measures:
- Always use encryption (SSL/TLS) in communications
- Regularly verify and update server authentication configurations
- Follow recommended best practices for both administrators and end users

✅ Conclusion

Understanding SMTP and IMAP protocols was essential to solving the problem I encountered when configuring the customer service system. With SMTP handling sending and IMAP enabling access and message management, both complement each other to make email communication fluid and secure.

I hope this article, written simply and based on my experience, helps you better understand how these protocols work. After all, sharing knowledge is a way to grow and make life easier for those who also need to deal with these configurations daily.

If you have questions or want to explore any topic in greater depth, feel free to comment. We're all learning together!

My second week on Woovi: Getting into the swing of things (or almost there)

Adam Neves — Tue, 15 Jul 2025 23:36:37 +0000

A False Sense of Comfort

My second week at Woovi felt calmer. I started delivering more and understood the codebase better, although honestly, I probably understand only 1 percent of what I need.

What’s interesting is that even as things started to fall into place, I realized how much context and depth are still missing. Each day exposes new gaps, unexpected architectural decisions, and subtle product nuances that force you to slow down and truly think.

Growth Beyond Code

A clear pattern emerged: every day, someone taught me something, whether technical or related to soft skills.

At Woovi, everyone seems to have a superpower. Some are masters of communication, others have exceptional technical depth, and some have sharp product instincts that guide big decisions. You start to see how each strength blends into the culture and how these traits build an environment where questioning and debating ideas is not just allowed but expected.

One of the most interesting cultural lessons this week was about how learning is shared. For example, today I learned about eventual consistency, a fundamental concept in distributed systems. It means that while data updates might not be immediately visible everywhere, the system will eventually reach a consistent state. In practice, this forces you to think differently about user experience, error handling, and how to communicate system states clearly to users.

These small technical insights are passed around naturally, in PR comments, quick chats, or even casual messages. They aren't pushed in forced "knowledge sharing" sessions; they emerge as part of daily work.

This also reinforces a crucial point: growth here depends on you actively engaging. If you stay passive, you risk missing valuable lessons hidden in daily interactions.

Workflow Maturity

I noticed a significant evolution in our workflow. In the first few days, things felt a bit chaotic, with processes and responsibilities less defined. By the second week, communication aligned, priorities became clearer, and deliveries started to feel more predictable.

This transition from initial chaos to controlled speed shows that Woovi is constantly iterating. There is no static mindset of “we’ve solved everything.” The culture is shaped around continuous improvement, even in internal processes. Everyone is expected to contribute to refining how we work, not just what we build.

Motivation and Expectation

Watching the team operate at this level is energizing. It pushes you to deliver more, keep improving, and constantly challenge your own limits.

Are we moving toward excellence? For me, the answer is yes. But it’s not the kind of excellence that comes from rigid structure or strict guidelines. It’s an evolving, living excellence that requires self-drive, curiosity, and a willingness to get uncomfortable.

Key Takeaways

Progress can feel fast, but there is always deeper context to uncover.
Learning here is organic and requires proactive behavior.
Process improvements are constant and collective, not accidental.
The culture values questioning and sees discomfort as a growth catalyst.
Technical lessons like eventual consistency show how deep the rabbit hole goes, even in seemingly "simple" features.

Conclusion

The second week was not about settling in. It was about realizing how much there still is to learn, both technically and personally.

The main lesson? Onboarding never truly ends here, and that might be exactly the point.

My First 7 Days at Woovi: Learnings, Surprises, and Open Questions

Adam Neves — Wed, 09 Jul 2025 01:54:54 +0000

Starting at a new company is often romanticized: welcome coffees, a nicely packaged onboarding plan, and a slow ramp-up. My first week at Woovi turned out to be quite the opposite: a fast-paced, pragmatic environment where questioning is not only allowed but expected.

First Impressions

On day one, I realized the culture is heavily biased towards fast delivery and technical autonomy. Instead of following step-by-step tutorials, I was encouraged to explore real repositories, understand actual deployment flows, and challenge architectural decisions.

This breaks the common assumption that onboarding must be 100% guided and “hand-holding.” Here, you’re treated as someone who should contribute from day one, not just passively consume information.

The Fear of Not Being Enough

A hidden part of this experience was the fear of not being enough for the role. I came in wondering if I could really match the expectations, whether I would deliver fast enough, and whether I would truly add value.

Very quickly, I realized there was no way to simply "meet expectations" here. Woovi feels more like a high-level engineering school than a typical company. You could be the most senior engineer out there, and you would still get overwhelmed by the codebase. It’s the result of years of creation, iteration, and continuous learning.

This realization actually eased my anxiety. Instead of obsessing over "being enough," I shifted focus to learning fast and contributing incrementally. The expectation is not perfection on day one. The expectation is to keep moving, questioning, improving, and growing as part of the team.

The codebase will push you out of your comfort zone. But in return, it turns you into a better engineer, faster than any comfortable environment ever could.

Technical Challenges

During the week, I dived into the main stack, Node.js, Koa, TypeScript, GraphQL, Relay and integrations with financial systems like Pix and payment gateways. One surprise was how modular yet unopinionated the architecture is: there’s more room for customization, and fewer rigid patterns.

This requires critical thinking: you can’t just “do it like Google.” You have to weigh real trade-offs, performance vs readability, coupling vs delivery speed.

Team Integration

Most interactions happened asynchronously. Far fewer meetings than I expected. This forces you to write better, whether it’s commits, pull requests, or internal docs, and not rely on endless live clarifications.

Interestingly, this exposed a personal flaw: I underestimated how much poor written communication can slow down a project. If you don’t document well, everyone stops to answer your basic questions.

What I Still Question

Does a loose, self-guided onboarding work for everyone?
How much does full autonomy from day one increase the risk of mistakes or rework?
Does async culture, while efficient, alienate those who prefer real-time discussions?

These questions stuck with me all week. I don’t have final answers yet, but I’m watching closely how this affects long-term alignment and productivity.

Key Takeaways

Writing good documentation is as critical as writing good code.
Questioning architecture is not just tolerated, it’s actively encouraged.
Onboarding doesn’t need to be paternalistic to be effective.
Organizational performance is deeply tied to clear written communication.

My First 2 Days: Building a Centralized Onboarding Flow

During my first two days, I noticed something that might sound paradoxical: everything was documented, yet no one knew exactly how to navigate it.

The documentation was thorough, covering internal APIs, deployment workflows, local setup, and architectural decisions. But each piece was isolated, like having a pile of puzzle pieces with no reference picture.

New engineers often found themselves constantly asking, "In what order should I read these docs?" or "What’s the first thing I should run locally before touching feature X?"

Instead of just consuming the scattered docs and pinging people repeatedly, I decided to start drafting a centralized onboarding flow. The goal was to connect all these pieces into a clear sequence:

What to clone first.
Which scripts to run and in which order.
What services need to be up before running the app.
Where to look for environment configuration and secrets.
Key architectural diagrams to understand before jumping into PRs.

This initiative not only helped me get up to speed faster but also turned into a reusable asset for future newcomers.

It challenged the assumption that "more docs = better onboarding." In reality, structured narrative beats raw volume every time.

By proactively organizing this flow, I ended up learning the system more deeply and reduced the dependency on constant Slack or chat questions. And perhaps more importantly, I started contributing real value on day two instead of just passively absorbing information.

Special Thanks to the Woovi Engineering Team

One thing that stood out immediately and deserves a special mention is the quality of the people here. It genuinely feels like every developer was handpicked, and after experiencing it firsthand, I now understand why the selection process is so demanding and sometimes lengthy.

Everyone I've interacted with acted with an impressive sense of honor and strength, always pushing to help each other, no matter how busy they were. They deeply remember what it felt like to be new in the company, and they step up to assist with patience, without sarcasm or condescension.

I won’t mention names, but to all of you who joined calls with me during this first week, consider this a public tribute. You turned what could have been a chaotic start into an empowering, fast-learning experience.

This reinforced for me that a strong engineering culture isn't just about code quality or architecture; it's built on people who genuinely want each other to succeed.

Conclusion

My first week at Woovi was less about a “cute onboarding” and more about a pragmatic deep dive. I realized that in a team focused on speed and autonomy, the worst mistake is waiting passively for instructions.

If you’re about to join a fast-moving team, here’s a provocation:

Are you ready to swim without a float? Or are you still sitting on the edge, waiting for the manual?

Your Turn

Have you gone through an ultra-fast or hyper-structured onboarding before? What worked best for you? Share your thoughts in the comments.

How MDX can accelerates document creation in websites

Hállex da Silva Costa — Mon, 05 May 2025 14:39:54 +0000

Overview

See how MDX solves the problem of writing extremely long pages or articles.

In this article, we will show you how MDX can be a powerful solution to speed up the documentation creation process.

Introduction

Have you ever seen a very common problem in many companies, such as outdated documents? Well, in a world where maintaining documents such as policies and privacy, terms and security is crucial.

At the same time, having to deal with the fact that you will have to spend precious time writing N pages that have already been written in a document like Word or PDF to an HTML, JSX or TSX page does not seem very pleasant or very smart.

Finding efficient ways to create and maintain documents becomes essential.

The Problem with Articles/Documentation

One of the biggest challenges in creating documentation is the time spent retyping content. Often, we need to:

Rewrite texts that already exist in other formats
Maintain consistency between different versions of the same document
Update multiple formats when changes occur

This process not only consumes time but also increases the chance of errors and inconsistencies.

The Solution: MDX

MDX (Markdown + JSX) emerges as an elegant solution to these problems. It combines the simplicity of Markdown with the power of JSX, allowing the creation of interactive and dynamic documents.

Easy Conversion from DOCX to MD/MDX

One of the biggest advantages of using MDX is the ease with which you can convert an existing document from docx to markdown and from markdown to MDX

Why Follow This Approach?

1. Productivity

Less time spent on formatting
Component reuse
Faster updates

2. Maintenance

Code and documentation together
Simpler versioning
Less content duplication

3. Interactivity

Interactive components
Executable code examples
Better reader experience

4. Flexibility

Easy integration with modern tools
Support for different output formats
Compatibility with popular documentation systems

Examples

Here's an example of a DocumentPage.tsx created using the tsx syntax for another page using the DocumentPage.mdx syntax

DocumentPage.tsx

import React from 'react';

const DocumentPage: React.FC = () => {
  return (
    <div className="document-page max-w-4xl mx-auto py-8 px-4">
      <h1 className="text-3xl font-bold mb-8 text-center">Terms of Service and Privacy Policy</h1>

      <section className="mb-8">
        <h2 className="text-2xl font-semibold mb-4">1. Introduction</h2>
        <p className="mb-4">
          Welcome to our Terms of Service and Privacy Policy. 
          This document establishes the rules and guidelines for using our services.
        </p>
        <p className="mb-4">
          By accessing and using our platform, you agree to the terms set forth herein.
          We recommend reading this document carefully before proceeding.
        </p>
      </section>

      <section className="mb-8">
        <h2 className="text-2xl font-semibold mb-4">2. Definitions</h2>
        <p className="mb-4">For the purposes of this document, the following terms shall have the meanings below:</p>
        <ol className="list-decimal pl-6 space-y-2">
          <li>
            <strong>Platform:</strong> Refers to the set of services and features provided
            through our website and applications.
          </li>
          <li>
            <strong>User:</strong> Any person who accesses or uses the Platform.
          </li>
          <li>
            <strong>Content:</strong> Information, data, text, images, and other materials provided
            through the Platform.
          </li>
        </ol>
      </section>

      <section className="mb-8">
        <h2 className="text-2xl font-semibold mb-4">3. Platform Usage</h2>
        <p className="mb-4">By using our Platform, you agree to:</p>
        <ul className="list-disc pl-6 space-y-2">
          <li>Provide accurate and up-to-date information</li>
          <li>Maintain the confidentiality of your account</li>
          <li>Not use the Platform for illegal purposes</li>
          <li>Respect intellectual property rights</li>
        </ul>
      </section>

      <section className="mb-8">
        <h2 className="text-2xl font-semibold mb-4">4. Privacy and Data Protection</h2>
        <p className="mb-4">
          Our privacy policy describes how we collect, use, and protect your personal information.
          For more details, please refer to our{' '}
          <a href="/privacy" className="text-blue-600 hover:underline">
            complete Privacy Policy
          </a>.
        </p>
        <div className="bg-gray-50 p-4 rounded-lg">
          <h3 className="text-lg font-semibold mb-2">Collected Data</h3>
          <ul className="list-disc pl-6 space-y-1">
            <li>Registration information</li>
            <li>Platform usage data</li>
            <li>Device information</li>
            <li>Cookies and similar technologies</li>
          </ul>
        </div>
      </section>

      <section className="mb-8">
        <h2 className="text-2xl font-semibold mb-4">5. Responsibilities</h2>
        <p className="mb-4">Our responsibilities include:</p>
        <ol className="list-decimal pl-6 space-y-2">
          <li>
            Maintaining the Platform available and functioning properly
          </li>
          <li>
            Protecting user data in accordance with data protection laws
          </li>
          <li>
            Providing technical support when needed
          </li>
        </ol>
      </section>

      <section className="mb-8">
        <h2 className="text-2xl font-semibold mb-4">6. Contact</h2>
        <p className="mb-4">
          For questions regarding these terms, please contact us via email at{' '}
          <a href="mailto:legal@company.com" className="text-blue-600 hover:underline">
            legal@company.com
          </a>
          {' '}or by phone at (555) 123-4567.
        </p>
      </section>

      <footer className="text-sm text-gray-600 mt-8 pt-4 border-t">
        <p>Last updated: {new Date().toLocaleDateString('en-US')}</p>
      </footer>
    </div>
  );
};

export default DocumentPage;

DocumentPage.mdx

---
title: "Terms of Service and Privacy Policy"
description: "Terms and conditions for using the platform and privacy policy"
creationAt: "2025-05-04"
lastUpdated: "2025-05-04"
---

export const meta = {
  title: "Terms of Service and Privacy Policy",
  creationAt: "2025-05-04",
  lastUpdated: "2025-05-04"
};

# {meta.title}

{frontmatter.description}

## 1. Introduction

Welcome to our Terms of Service and Privacy Policy. 
This document establishes the rules and guidelines for using our services.

By accessing and using our platform, you agree to the terms set forth herein.
We recommend reading this document carefully before proceeding.

## 2. Definitions

For the purposes of this document, the following terms shall have the meanings below:

1. **Platform:** Refers to the set of services and features provided
   through our website and applications.

2. **User:** Any person who accesses or uses the Platform.

3. **Content:** Information, data, text, images, and other materials provided
   through the Platform.

## 3. Platform Usage

By using our Platform, you agree to:

* Provide accurate and up-to-date information
* Maintain the confidentiality of your account
* Not use the Platform for illegal purposes
* Respect intellectual property rights

## 4. Privacy and Data Protection

Our privacy policy describes how we collect, use, and protect your personal information.
For more details, please refer to our [complete Privacy Policy](/privacy).

<InfoBox type="info">
  ### Collected Data

  * Registration information
  * Platform usage data
  * Device information
  * Cookies and similar technologies
</InfoBox>

## 5. Responsibilities

Our responsibilities include:

1. Maintaining the Platform available and functioning properly
2. Protecting user data in accordance with data protection laws
3. Providing technical support when needed

## 6. Contact

For questions regarding these terms, please contact us via email at [legal@company.com](mailto:legal@company.com)
or by phone at (555) 123-4567.

<LegalNotice>
  This document was last updated on {meta.lastUpdated}.
  We recommend checking periodically for updates.
</LegalNotice>

{/* Custom components for legal elements */}
<LegalSection>
  <h2>Final Provisions</h2>
  <p>
    These terms are governed by the laws of the United States and any dispute shall be
    submitted to the jurisdiction of the courts of New York, NY.
  </p>
</LegalSection>

<TableOfContents>
  <h2>Table of Contents</h2>
  <ol>
    <li><a href="#introduction">Introduction</a></li>
    <li><a href="#definitions">Definitions</a></li>
    <li><a href="#usage">Platform Usage</a></li>
    <li><a href="#privacy">Privacy and Data Protection</a></li>
    <li><a href="#responsibilities">Responsibilities</a></li>
    <li><a href="#contact">Contact</a></li>
  </ol>
</TableOfContents>

> Documente created at {meta.creationAt}

This MDX example demonstrates how we can create complex legal documents in a more structured and interactive way. Notice how:

The frontmatter organizes the document metadata. Use it or export a new meta variable to use in your markdown and communicate with external layer like the MDXProvider
Markdown syntax keeps the content readable and well-formatted
Custom components (<InfoBox>, <LegalNotice>, <LegalSection>, <TableOfContents>) add specific functionality
Custom styles for common elements as h1, h2, h3, h4, h5, p, a, li, ol, etc... Allows you to dynamically style markdown syntax elements such as #, ##, ###, -
JavaScript code can be embedded for dynamic features (like the update date)
The document structure is clear and well-organized

This approach makes it much easier to maintain and update extensive legal documents, while also significantly improving the end-user experience.

You can visit a repository with a simple example comparing TSX and MDX here and visit here to play a little with mdx playground

Conclusion

MDX is an excellent tool for saving time, maintaining code consistency, and improving efficiency. By combining the simplicity of Markdown with the power of JSX, it offers a robust solution to modern documentation challenges.

The approach of converting existing documents to MDX not only speeds up the creation process but also improves the quality and maintainability of documentation. In a world where documentation is crucial, MDX presents itself as an essential tool for teams seeking efficiency, quality and save time.

Prometheus + Redis: Simple Guide to Monitor Redis Instances

Lucas Aguiar — Mon, 21 Apr 2025 22:26:33 +0000

Redis is often a critical part of modern infrastructure — whether used as a cache, message broker, or ephemeral store. Monitoring it properly helps you detect issues early and ensure system stability.

In this guide, you’ll learn how to build a Redis monitoring dashboard with Prometheus and Grafana to quickly identify issues and improve system reliability.

⚙️ Installing Prometheus (Quick Setup)

We’ll start by deploying Prometheus using Helm:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace prometheus --create-namespace

This will install Prometheus, Grafana, and some built-in exporters.
To access Grafana:

kubectl port-forward svc/kube-prometheus-grafana -n prometheus 3000:80

You can access here -> http://localhost:3000/login

Default login: admin / prom-operator

🧱 Installing Redis

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

helm install redis bitnami/redis \
  --namespace app-stg \
  --set architecture=standalone \
  --set auth.enabled=false \
  --create-namespace

This installs a standalone Redis with no password, perfect for testing.
After this, you can point the Redis Exporter and your application to the correct Redis service. The hostname will be:

redis-master.app-stg.svc.cluster.local:6379

📦 Installing Redis Exporter

Now let’s deploy the Redis Exporter:

helm install redis-exporter prometheus-community/prometheus-redis-exporter \
  --namespace prometheus \
  --set serviceMonitor.enabled=true \
  --set serviceMonitor.namespace=prometheus \
  --set serviceMonitor.interval=15s \
  --set serviceMonitor.labels.release=kube-prometheus \
  --set redisAddress=redis://redis-master.app-stg.svc.cluster.local:6379 \
  --create-namespace

The Redis Exporter exposes metrics at a Prometheus-compatible /metrics endpoint.

kubectl port-forward svc/redis-exporter-prometheus-redis-exporter -n prometheus 9121:9121

Then open: http://localhost:9121/metrics
You should see a long list of metrics like this:

✅ redis_up 1 means the exporter is connected to a Redis instance and it’s healthy.
🚫 redis_up 0 means the exporter failed to connect — check the Redis address or service availability.

If everything is working, you’ll also see metrics like:

redis_connected_clients
redis_memory_used_bytes
redis_total_commands_processed

🔍 Checking in Prometheus

To validate that Prometheus is collecting Redis metrics:

kubectl port-forward svc/kube-prometheus-kube-prome-prometheus -n prometheus 9090

Open http://localhost:9090, go to Status > Targets, and check that Redis Exporter is listed and UP.

Everything is working right!

📊 Importing the Redis Dashboard on Grafana

To visualize your Redis metrics in a clean and ready-to-use panel, you can import a community-maintained dashboard from Grafana Labs.

https://grafana.com/grafana/dashboards/14091-redis-dashboard-for-prometheus-redis-exporter-1-x/

🧭 How to Import

Access Grafana by establishing port forwarding and navigating to http://localhost:3000 in your browser
Navigate to the "+" icon in the left sidebar and select "Import"
Enter the dashboard ID or URL in the provided field and click "Load"
Click "Import" to finalize the installation

Allow a few moments for the system to process your request as the metrics populate on your dashboard

Thats it!
⎈Happy Helming!⎈

Resilient Node.js servers without using docker

Hállex da Silva Costa — Tue, 04 Mar 2025 01:55:09 +0000

Overview

Now you will learn how we create resilient services without interrupting the main SSH connection or without the need to create N SSH connections with N open terminals while developing our services in our remote development environment.

Summary

Requirements
What is PM2?
Installing PM2
Persisting Processes
Check Processes
In Conclusion

Requirements

Node.js
NPM

What is PM2?

PM2 is a daemon process manager that will help you manage and keep your application online 24/7

The services running through it become resilient. A similar analogy is comparing PM2 with NGINX

Installing PM2

npm i -g pm2

Persisting Processes

# Explanation: pm2 start <package-manager> --name <app-name> -- <script-name>
pm2 start pnpm --name woovi-front -- woovi

Your server is launched in daemon mode, meaning it runs as a detached background process.

Under the hood, PM2 spawns a new process for your service that is independent of the initial terminal session.

This decoupling ensures that the server continues to run even if you close the terminal, while PM2 monitors, logs, and automatically restarts the process if it encounters any issues.

Check Processes

pm2 ls

You can view the daemon processes that PM2 spawns for your services, and check the following information

If the status is "online", your service already be up, then you can test using the command curl

I already know that my service may be running on port 3000, you must change the port to your application's port

# use this for test in your VPS
curl http://localhost:3000

# or this, if want to test in the machine host
curl http://yourmachineip:3000

PM2 is powerful when it comes to process management it has many other commands like pm2 delete to delete an unused daemon process, pm2 restart to restart a process, and pm2 stop to end a process execution

In Conclusion

Integrating PM2 into remote development environments is an effective strategy to ensure that your services or applications remain running continuously and stably so that you can move freely without worrying about tying up the main process of your SSH connection and ending up interrupting the service at some point.

Woovi monorepos best practices

Hállex da Silva Costa — Mon, 24 Feb 2025 15:04:11 +0000

Summary

Look the conflict between dependencies version
Always update the packages remember of updates your codependencies
Clear the cache
Change error also is progress

Look at the conflict between the dependencies version

This detail implies if any dependencies can be resolved correctly and if not have a version conflict.
As the example we have the styled-components lib, it can have a problem with type Symbol reference where the library doesn´t find your properties of themes because, in your internal code, it uses the symbolObject which is a unique object that refers your set configs.

This rule is valid for any type of dependency like react-relay, relay-compiler, style-components, react and so on.
If you use pnpm you can run the command pnpm list <package-name> --recursive to help you find duplicate packages with different versions.

Always update a package remember to update your codependencies

Here I will use relay-compiler as an example, if you update the project's relay version, ensure that the react-relay, babel, swc, or in the general context, all relay plugins and your codependency this updates can prevent conflict of compatibility and unexpected bugs.
Also remember to delete any artifact that may have been generated by an old version of some library you are using, such as the __generated__ folder of relay-compiler.

Clear the cache

If some error is thrown on the screens and the value is undefined it should have some value and probably have a persistence of cache from older executions.

Change the error also is a progress

Sometimes you may get stuck on an error or bug, just following these other steps above may not solve the problem 100%, but it will probably change the error and this can be considered progress.

In Conclusion

Synchronizing codependencies and using tools like pnpm list <package-name> --recursive helps identify incompatible versions while updating related packages ensures compatibility. Clearing caches, and removing old artifacts of relay-compiler can help get closer to the goal, and errors should be treated as progress steps toward resolution.