DEV Community: Woovi

MED 2.0 for devs: entities, fields and the implementation flow

Lucas Aguiar — Mon, 24 Aug 2026 19:23:08 +0000

If you work with Pix at a fintech, one thing is certain: sooner or later you'll have to deal with fraud. And the bar the Central Bank sets for that just went up. In August 2025 the MED 2.0 rules came out (starting with Resolution BCB nº 493), the new version of Pix's Special Refund Mechanism — optional to adopt from Nov 23, 2025 and with a mandatory rollout scheduled for 2026.

In this article I want to explain, in a simple and technical way, what the MED entities are, the fields that matter in each one and how the flow works end to end — with a focus on whoever is going to write the code.

🧩 First: what MED is (and why it exists)

MED (Mecanismo Especial de Devolução — Special Refund Mechanism) is a regulatory obligation from the Central Bank for every Pix participant — banks, payment institutions, fintechs, anyone who does Pix.

The idea is simple: when fraud or an operational failure happens, there must be a standardized and auditable path to return the victim's money. Without MED, each institution would solve it its own way (or not at all).

Important: MED is not for commercial disputes, buyer's remorse, or "I sent a Pix to the wrong person because I wasn't paying attention." It's for:

Scam / fraud (phishing, social engineering, coercion)
Account takeover
Fraudulent access to channels
Institution's operational error (duplicate Pix, wrong amount from a system failure)

💡 Rule of thumb: MED = proven fraud or an error by the institution. It's not a "cancel my Pix" channel.

🚀 What changes in MED 2.0

MED 1.0 had an Achilles' heel: it only blocked and refunded at the first receiving account of the fraudulent Pix. So the scammer pulled the classic move — received the money and scattered it in a cascade across many accounts in seconds. By the time the block arrived, the money had already evaporated. According to the BCB, in 2025 only 9.3% of the disputed amount was recovered on average.

MED 2.0 tackles exactly that: it now traces the money's path beyond the first account. The big highlights:

Multi-layer tracing. DICT follows the money through the transaction graph and picks the transactions most likely to be on the drain path.
Targeted blocking. The amount is blocked at each node of the path — only what matters, not the whole account (more on this below).
Refund in its own name. The receiver's institution debits the mule account and refunds the victim directly, appearing as the payer on the statement.
Digital self-service. The harmed customer triggers the process from the app.
Standardized deadlines and UX (Timing Manual and Minimum UX Requirements).

🧱 The MED entities (and how they connect)

Before diving in, the most important thing is to understand the end-to-end flow. It's what gives meaning to each entity:

The harmed customer contacts their PSP, which opens a Funds Recovery (FundsRecovery). This is the starting point.
DICT traces the transactions from the root transaction and sends Infraction Reports (InfractionReport) to the PSPs of the accounts along the money's path.
Each receiving PSP blocks the balance (only the indicated amount) and analyzes the Infraction Report.
Once the infractions are analyzed, the paying PSP triggers the start of the Refund Requests — and the money goes back to the victim, layer by layer.
Along the way, fraud markers are recorded in DICT, feeding prevention.

So there are four entities. Understand these four and you understand MED:

Entity	Base endpoint	Role in the flow
Funds Recovery	`/funds-recoveries/`	Opens the case. The harmed customer starts it; it traces and orchestrates everything (the 2.0 highlight).
Infraction Report	`/infraction-reports/`	What each PSP in the chain receives. Triggers the block and the analysis.
Refund Request	`/refunds/`	Executes the refund of the money to the victim, layer by layer.
Fraud Marker	(automatic on agreement)	Flags receivers as fraudsters in DICT, feeding prevention.

Let's go through them one by one, in the order they appear in the flow.

🕸️ Funds Recovery (`FundsRecovery`)

This is the big novelty of MED 2.0 — and where everything begins. When the customer is a fraud victim, the paying PSP opens a Funds Recovery (POST /funds-recoveries/). From there, DICT traces the money and orchestrates blocks and refunds.

The stages (this is where the "several statuses" live)

Funds Recovery isn't a single step — it moves through stages with their own statuses, and your backend needs to react to each transition. Today the flow is fully automated: DICT does the tracing, prioritization and dispatch of the Infraction Reports with no manual step from the PSP.

Status	Stage
`CREATED`	Funds Recovery created over the root transaction
`TRACKED`	Transaction tracking graph created
`AWAITING_ANALYSIS`	Infraction Reports generated; receiving PSPs analyzing (up to 7 days)
`ANALYSED`	Infraction Reports analyzed and closed; the paying PSP can trigger the refund

After ANALYSED comes the refund (requests run sequentially) and, at the end, DICT signals completion through the FUNDS_RECOVERY_COMPLETED event.

Tracking graph parameters

Parameters that bound the graph tracing (applied by DICT's algorithm):

Parameter	What it controls
`MinTransactionAmount`	Minimum amount of each transaction considered
`MaxTransactions`	Maximum number of transactions in the graph
`HopWindow`	Time window between money entering and leaving an account
`MaxHops`	Maximum graph depth (how many layers to go down)

Main endpoints

Method + route	What it does
`POST /funds-recoveries/`	Create a Funds Recovery
`GET /funds-recoveries/{id}`	Query a Funds Recovery
`POST /funds-recoveries/{id}/tracking-graph`	Create a tracking graph
`GET /funds-recoveries/{id}/tracking-graph`	Query the graph
`POST /funds-recoveries/{id}/block`	Request the transaction blocks
`GET /funds-recoveries/{id}/infraction-reports`	List the Infraction Reports of the recovery
`POST /funds-recoveries/{id}/refund`	Request a refund within the recovery
`GET /funds-recoveries/{id}/refunds`	List the refunds of the recovery
`POST /funds-recoveries/{id}/cancel`	Cancel the recovery

🔔 Don't sit there polling. DICT has an events endpoint (GET /event-notifications) with two key signals for the recovery:

FUNDS_RECOVERY_ANALYSED → the Infraction Reports were analyzed; you evaluate the result and trigger (or not) the start of the refund.

FUNDS_RECOVERY_COMPLETED → the refund phase is over; anyone still holding blocked funds can release them (if there's no other basis to keep the block).

📢 Infraction Report (`InfractionReport`) — the block

If Funds Recovery is the customer pulling the trigger, the Infraction Report is what lands on the PSPs of the accounts along the money's path. Each prioritized transaction generates an Infraction Report for the PSP of that node, which then blocks the balance and analyzes the case.

Main fields

Field	What it is
`TransactionId`	EndToEndId of the suspicious transaction (e.g., `E999990101234...`)
`InfractionType`	Type: `FRAUD`, `REFUND_REQUEST`, `REFUND_CANCELLED`
`FundsRecoveryId`	(MED 2.0) links the report to the Funds Recovery
`InfractionAmount`	(MED 2.0) the amount that must be blocked from that transaction
`InfractionData.DebitedParticipant` / `CreditedParticipant`	ISPBs of the payer and the receiver
`InfractionData.ReportedBy`	`DEBITED_PARTICIPANT` or `CREDITED_PARTICIPANT`
`InfractionData.TransactionDate`	Transaction date-time
`InfractionData.InfractingAccountData`	Branch + account involved at the node
`TransactionDepth`	(latest) position of the transaction in the money-movement chain — how far it is from the initial fraud (DICT Manual v8.5)
`Status`	`OPEN`, `ACKNOWLEDGED`, `CLOSED`, `CANCELLED`
`AnalysisResult`	`AGREED` or `DISAGREED`

The block: only the `InfractionAmount`, not the whole account

This is the part that causes the most bugs if you're not careful. What you block is not the account's entire balance, nor the full amount of the original transaction — it's exactly the InfractionAmount: the amount that node received and that needs to be held on that specific transaction.

Why? Because the money spreads out. A mule account may have received R$ 800 from one branch and R$ 200 from another; each Infraction Report carries the right amount to block on each transaction. Blocking too much holds the customer's legitimate money; blocking too little lets funds slip away. Block the InfractionAmount, no more, no less.

⏱️ The receiving PSP has up to 7 days to analyze and close the report (.../acknowledge on receipt, .../close with AGREED/DISAGREED). Every agreement generates a fraud marker for that receiver — even if they never end up receiving a refund request.

💸 Refund Request (`Refund`) — bringing the money back

Once the Infraction Reports are analyzed (FUNDS_RECOVERY_ANALYSED event), the paying PSP triggers the start of the refund. From there DICT fires the Refund Requests sequentially, without you having to orchestrate them one by one.

The key point: each refund goes to the harmed customer, only for the missing amount

Here lies the biggest mindset shift of 2.0. Every refund request is destined to the harmed customer (the user of the paying PSP who opened the recovery), and the goal is to return the money wherever it is in the chain. Rules that show up on the test:

The 1st request always goes to the receiver of the root transaction.
The subsequent ones follow the priority defined in the blocking stage.
Each PSP debits the mule account and refunds directly to the harmed customer, appearing as the payer on the statement.
Only the missing amount is requested to complete the total — never the full initial amount again. BCB's own example: even with R$ 800 blocked at a node, if R$ 250 was already recovered, the refund is requested for the remaining R$ 750 only. The amounts are updated automatically with each new refund.

In other words: the system keeps "scraping" whatever it can from each account until the total is met, never refunding more than owed.

Main fields

Field	What it is
`TransactionId`	Transaction being refunded
`RefundReason`	`FRAUD`, `OPERATIONAL_FLAW`, `REFUND_CANCELLED`
`RefundAmount`	Requested amount — the remainder, not the full value
`FundsRecoveryId`	(MED 2.0) links the refund to the recovery
`RefundAccount`	(MED 2.0) destination account for the payment (the harmed customer's)
`MonitorAccount`	(MED 2.0) whether the account should be monitored for future blocks
`EffectiveRefundedAmount`	(MED 2.0) on closure, the amount actually refunded
`Status`	`OPEN`, `CLOSED`, `CANCELLED`
`AnalysisResult`	`TOTALLY_ACCEPTED`, `PARTIALLY_ACCEPTED`, `REJECTED`
`RefundRejectionReason`	`NO_BALANCE`, `ACCOUNT_CLOSURE`, `CANNOT_REFUND`, `OTHER`

💡 Partial refund + monitoring is the nastiest real-world case. If the account doesn't have the full balance at the moment (PARTIALLY_ACCEPTED / NO_BALANCE), you accept what you can, report the EffectiveRefundedAmount and, with MonitorAccount on, monitor the account to keep blocking and refunding in parts as money comes in. Model this from the start — it's not an exception, it's routine.

🚩 Fraud Marker (prevention)

MED isn't only about putting out fires — it feeds prevention.

When an Infraction Report is agreed (AGREED), the receiver is flagged as a fraudster in DICT, automatically. And there's an important 2.0 detail: all receivers of transactions with an agreed report get flagged — even the ones that never receive a refund request (e.g., a node that fell outside the continuous path of the graph).

These markers feed DICT's anti-fraud data (counters of settlements, reported frauds and confirmed frauds, by key, by owner and by account).

🎯 Where this becomes gold: query that anti-fraud data for the destination key/account before releasing a cash-out. A recent fraud signal? You hold, ask for a double-check or add friction. Preventing is far cheaper than running the whole recovery flow.

📅 The deadlines you CAN'T miss

A blown deadline in MED = money lost or a regulatory fine. Nail these into your scheduler (the definitive source is the Pix Timing Manual):

Rule	Deadline
Maximum transaction age to open a case	80 days after the Pix
Infraction Report analysis by the receiving PSP	up to 7 days
Start the refund after the reports are analyzed	up to 72 hours

Strong recommendation: model each deadline as a scheduled job with alerts. Don't rely on someone watching a spreadsheet. A due SLA is a system event.

✅ When to use (and NOT use) MED

You can use it for:

Proven scam/fraud
Account takeover / coercion / fraudulent access
The institution's own operational error

You can't use it for:

Commercial disputes ("the product never arrived")
Buyer's remorse
A Pix sent to the wrong person by the payer's own mistake
Disputes between good-faith third parties

🏁 Wrapping up

MED 2.0 changes the game of fraud recovery on Pix: gone is the focus on a single account, in comes tracing the money's path, with targeted blocking and layer-by-layer refunds. For your fintech, the summary is:

🧭 The flow starts with the customer: they open the Funds Recovery, which traces and fires the Infraction Reports.
🔒 Block the InfractionAmount, not the whole account — that's the detail that bites the most.
💸 Each refund goes to the harmed customer and only for the missing amount — the goal is to bring the money back wherever it is.
🔔 Use events, not polling (FUNDS_RECOVERY_ANALYSED, FUNDS_RECOVERY_COMPLETED).
📚 The source of truth is always the DICT API spec and the BCB rules — check the current version before coding.

Official sources (BCB)

Pix rules — Central Bank of Brazil and Resolution BCB nº 493/2025
Circuito Pix — MED 2.0, Day 1 and Day 2
Refund procedures implementation guide (MED)
DICT API — official repository bacen/pix-dict-api

That's it! If you're implementing MED 2.0 at your fintech and hit a wall, drop a comment and let's talk it through. 🚀

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.

DEV Community: Woovi

MED 2.0 for devs: entities, fields and the implementation flow

🧩 First: what MED is (and why it exists)

🚀 What changes in MED 2.0

🧱 The MED entities (and how they connect)

🕸️ Funds Recovery (FundsRecovery)

The stages (this is where the "several statuses" live)

Tracking graph parameters

Main endpoints

📢 Infraction Report (InfractionReport) — the block

Main fields

The block: only the InfractionAmount, not the whole account

💸 Refund Request (Refund) — bringing the money back

The key point: each refund goes to the harmed customer, only for the missing amount

Main fields

🚩 Fraud Marker (prevention)

📅 The deadlines you CAN'T miss

✅ When to use (and NOT use) MED

🏁 Wrapping up

Official sources (BCB)

Creating a Certificate X.509 expiration Dashboard using Grafana

Current state of certificate expiration tools

x509-certificate-exporter + Grafana Dashboard

In Conclusion

Saving Terraform State in S3

Storing Terraform State in an S3 bucket

How to migrate existing local state?

In Resume

Creating a S3 bucket using Terraform

S3 using Terraform

In Conclusion

Copy and Paste on Proxmox VM

Using a Script

In Summary

Using Terraform to create LXC in Proxmox

Proxmox Infrastructure

VMs vs LXC

Provisioning using Terraform

In Conclusion

Understanding IMAP and SMTP Mail Protocols

📮 Introduction

🌐 Overview of Email Protocols

📤 SMTP - Simple Mail Transfer Protocol

📥 IMAP - Internet Message Access Protocol

⚖️ Comparison Between SMTP and IMAP

⚙️ Technical Aspects and Implementation

🔒 Security and Best Practices

✅ Conclusion

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

A False Sense of Comfort

Growth Beyond Code

Workflow Maturity

Motivation and Expectation

Key Takeaways

Conclusion

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

First Impressions

The Fear of Not Being Enough

Technical Challenges

Team Integration

What I Still Question

Key Takeaways

My First 2 Days: Building a Centralized Onboarding Flow

Special Thanks to the Woovi Engineering Team

Conclusion

Your Turn

How MDX can accelerates document creation in websites

Overview

Introduction

The Problem with Articles/Documentation

The Solution: MDX

Easy Conversion from DOCX to MD/MDX

Why Follow This Approach?

1. Productivity

2. Maintenance

3. Interactivity

4. Flexibility

Examples

DocumentPage.tsx

DocumentPage.mdx

🕸️ Funds Recovery (`FundsRecovery`)

📢 Infraction Report (`InfractionReport`) — the block

The block: only the `InfractionAmount`, not the whole account

💸 Refund Request (`Refund`) — bringing the money back