DEV Community: Tomás Alegre Sepúlveda

🤖 8 Agent Skills and my first MCP server published to npm

Tomás Alegre Sepúlveda — Sun, 06 Sep 2026 03:26:20 +0000

I spent months watching my agent re-solve the exact same problems, over and over, because I never sat down and wrote them up once so anyone else could reuse them. That's the kind of technical debt nobody ever puts on a roadmap. So I published alpha-skills: eight installable Agent Skills and my first MCP server on npm.

Where the published skills live

The installable catalog lives in skills/, split into three categories: external/ for third-party APIs, local/ for homelab and workflows, and general/ for cross-project utilities. All three are public: one skill in external/, one in local/, and six in general/. local/ describes the use case.

skills/
├── external/
│   └── nextdns-api/SKILL.md
├── local/
│   └── progressive-search/SKILL.md
└── general/
    ├── agent-context-generator/SKILL.md
    ├── nestjs-iam-patterns/SKILL.md
    ├── nestjs-advanced-patterns/SKILL.md
    ├── nestjs-graphql/SKILL.md
    ├── tuning-claude-code/SKILL.md
    └── obsidian-second-brain/SKILL.md

<DIAGRAM 02: 02-public-skills-structure-en.png>

The eight skills

Three categories: external/ for third-party services, local/ for homelab infrastructure and personal workflows, general/ for cross-cutting utilities that don't depend on any one service.

Skill	Category	Use it for
`nextdns-api`	`external`	NextDNS API
`progressive-search`	`local`	Code and documentation search
`agent-context-generator`	`general`	Project context
`nestjs-iam-patterns`	`general`	Authentication and permissions
`nestjs-advanced-patterns`	`general`	NestJS internals and architecture
`nestjs-graphql`	`general`	Code-first and schema-first GraphQL
`tuning-claude-code`	`general`	Claude Code configuration
`obsidian-second-brain`	`general`	Note organization and review

Each command installs one skill. Run the command for the one you need.

1. `nextdns-api`

A full reference for the NextDNS REST API: profiles, security/privacy/parental-control settings, denylist and allowlist management, analytics, query logs. This is the one the MCP server below is built directly against.

npx skills add Alpha018/alpha-skills -s nextdns-api

2. `progressive-search`

The discovery workflow I run constantly: code questions go to CodeGraph, doc questions go to QMD, and it falls back to grep/find when neither answers. It keeps an in-session graph of what's already been found so it never repeats a search.

npx skills add Alpha018/alpha-skills -s progressive-search

3. `agent-context-generator`

Generates, refreshes, or audits a project's CLAUDE.md/AGENTS.md, grounded in what the repo actually contains: real dependencies, real folder structure, real scripts. Not a generic template that assumes a stack you don't have.

npx skills add Alpha018/alpha-skills -s agent-context-generator

4. `nestjs-iam-patterns`

Auth and authz patterns for NestJS: JWT access/refresh, session auth with Passport and Redis, API keys, RBAC, granular permissions, ABAC, Google Sign-In, TOTP/2FA. Led by a decision guide for which pattern fits your actual situation, not a catalog of all of them.

npx skills add Alpha018/alpha-skills -s nestjs-iam-patterns

5. `nestjs-advanced-patterns`

Advanced NestJS internals: explicit and implicit DI tokens, dynamic modules, runtime discovery, durable providers, worker threads, circuit breaker, WebSocket gateways, and a decision table for picking a microservice transporter across TCP, Redis, MQTT, NATS, RabbitMQ, Kafka, gRPC.

npx skills add Alpha018/alpha-skills -s nestjs-advanced-patterns

6. `nestjs-graphql`

One skill covering both code-first and schema-first GraphQL in NestJS, with a decision table that routes every task to exactly one reference file so the agent never loads both halves at once. It covers subscriptions with PubSub/Redis, the N+1 problem solved with DataLoader, typed guards, query depth and cost limits, and a production-hardening section verified against Apollo Server's actual source, not against what I remembered.

npx skills add Alpha018/alpha-skills -s nestjs-graphql

7. `tuning-claude-code`

Designs the whole Claude Code configuration stack for a repo: CLAUDE.md treated as a token budget, path-scoped rules, custom subagents, deterministic hooks, a pruned MCP list, parallel worktrees, and headless CI.

npx skills add Alpha018/alpha-skills -s tuning-claude-code

8. `obsidian-second-brain`

A decision guide for running an Obsidian vault as a knowledge system that actually survives contact with real use. It steers away from productivity theater and plugin overload, picks one lead organizer (PARA folders for delivery work, Zettelkasten links for idea generation), and states plainly when Obsidian is the wrong tool.

npx skills add Alpha018/alpha-skills -s obsidian-second-brain

The style these skills share

None of the general/ skills started from a written style guide. But by the fourth one, the pattern was impossible to miss:

Decision guide, not feature list. The skill doesn't dump everything it knows. It opens with a table or a short procedure that picks the right option for your actual situation, and says plainly when the tool is the wrong choice.
Progressive disclosure. SKILL.md stays a lean procedure (under 500 lines). Deep material moves to references/*.md, and the body tells the agent exactly when to load each one.
Trigger-oriented descriptions, with evals. The description frontmatter field is the highest-leverage one: a vague one means the skill silently never fires. Every skill ships an evals/trigger-eval.json with should-trigger and should-not-trigger cases.
Plain ASCII, no AI tics. Every file that gets persisted goes through a de-AI pass before it lands.

The first MCP server

@alpha018/nextdns-mcp is a stdio MCP server, run through npx, that exposes the NextDNS API: reading and updating a profile's settings, managing list entries, pulling analytics, reading logs. It's built on the same reference doc that backs nextdns-api, so the two stay in sync on purpose.

Publishing to npm: the trusted publishing problem

This is the part that cost me more than ten CI commits to get right.

@semantic-release/npm doesn't support OIDC trusted publishing. Its verifyConditions step demands an NPM_TOKEN or a preconfigured .npmrc no matter what id-token: write is set to in the workflow. That permission only buys provenance signing through the plugin — not authentication.

What actually worked is two shared workflows, generalized across every package under mcp-servers/* instead of one file pair per package:

1. Validate packages on every PR

Workflow: pr-test-mcp-servers.yml

Detects which package directories changed and runs lint, typecheck, build and test for each package, across Node 22 and 24.

2. Version and publish from main

Workflow: build-publish-mcp-servers.yml

On every push to main, for each changed package, within a single job:

Run build and test.
Run npx semantic-release with npmPublish: false: update the version, changelog, tag and release, without requiring npm authentication.
Compare the freshly updated local version with npm view <pkg> version.
If they differ, run npm publish --provenance directly through the npm CLI.

The split that solved it: semantic-release handles versioning; the npm CLI handles publishing through OIDC.

Four gotchas that cost real time

The first publish is manual. A brand-new npm package can't bootstrap through OIDC under any circumstances. The first version has to be published by hand, with a real login, before the Trusted Publisher link can even be added on npmjs.com.
The bin path matters. npm publish silently drops any bin path starting with ./. "./dist/index.js" gets dropped with only a warning — write "dist/index.js" instead.
Owner casing matters. npm's provenance verification checks repository.url against the OIDC claim's owner case-sensitively. github.com/alpha018/... failed against the real owner casing, which is Alpha018.
The workflow filename must match. npm's Trusted Publisher config pins the exact workflow filename. Rename the file without updating that entry and npm signs the provenance fine, then rejects the publish PUT with an E404 that looks identical, in shape, to "Trusted Publisher not configured".

When this setup is not worth it

If you're publishing a single package and have no plan to add a second one, this whole scaffold is overengineering. A plain workflow with NPM_TOKEN in a secret solves the same problem in fifteen minutes, no OIDC required. The two shared workflows only pay for themselves once a second or third package shows up — before that, they're just time you're not spending on the skill that actually matters.

Adding a second MCP server now is trivial: it only needs its own package.json and its own .releaserc.json, and both shared workflows pick it up automatically. Solving this properly once pays off in every package that comes after.

If any of these eight skills fixes something you've been rewriting every week, the repo is github.com/Alpha018/alpha-skills. And if you want the deeper version of any single one, some already have their own extended write-up on Buy Me a Coffee.

Thanks for reading this far — if you try one out, tell me what broke, because something always does. Which of the eight would fix the most for your day-to-day?

💌 Special Acknowledgments

To a girl who, without knowing it, pushed me to keep creating and coding in my free time. To the one who was once my spark: for "YLP", with gratitude... and with scars that also teach.

🤖 8 Agent Skills y mi primer servidor MCP publicado en npm

Tomás Alegre Sepúlveda — Sun, 06 Sep 2026 03:26:02 +0000

🇺🇸 Read this post in English

Llevo meses haciendo que mi agente resuelva los mismos problemas una y otra vez porque nunca me tomé el tiempo de escribirlos una sola vez, bien, y dejar que otros los reusaran. Ese es exactamente el tipo de deuda técnica que nadie pone en un roadmap. Así que publiqué alpha-skills: ocho Agent Skills instalables y mi primer servidor MCP en npm.

Dónde están las skills publicadas

El catálogo instalable vive en skills/, separado en tres categorías: external/ para APIs de terceros, local/ para homelab y flujos de trabajo, y general/ para utilidades transversales. Las tres son públicas: una skill en external/, una en local/ y seis en general/. local/ describe su ámbito de uso.

skills/
├── external/
│   └── nextdns-api/SKILL.md
├── local/
│   └── progressive-search/SKILL.md
└── general/
    ├── agent-context-generator/SKILL.md
    ├── nestjs-iam-patterns/SKILL.md
    ├── nestjs-advanced-patterns/SKILL.md
    ├── nestjs-graphql/SKILL.md
    ├── tuning-claude-code/SKILL.md
    └── obsidian-second-brain/SKILL.md

Las ocho skills

Tres categorías: external/ para servicios de terceros, local/ para infraestructura de homelab y workflows propios, general/ para utilidades transversales que no dependen de ningún servicio en particular.

Skill	Categoría	Para qué sirve
`nextdns-api`	`external`	API de NextDNS
`progressive-search`	`local`	Búsqueda de código y documentación
`agent-context-generator`	`general`	Contexto de proyecto
`nestjs-iam-patterns`	`general`	Autenticación y permisos
`nestjs-advanced-patterns`	`general`	Internals y arquitectura de NestJS
`nestjs-graphql`	`general`	GraphQL code-first y schema-first
`tuning-claude-code`	`general`	Configuración de Claude Code
`obsidian-second-brain`	`general`	Organización y revisión de notas

Cada comando instala una skill. Ejecuta el de la que necesites.

1. `nextdns-api`

Referencia completa de la API REST de NextDNS: perfiles, seguridad/privacidad/control parental, listas de bloqueo y permitidas, analíticas, logs de consultas. Es la que respalda al MCP server que describo más abajo.

npx skills add Alpha018/alpha-skills -s nextdns-api

2. `progressive-search`

El workflow de descubrimiento que uso todo el tiempo: preguntas de código van a CodeGraph, preguntas de documentación van a QMD, y si ninguno responde cae a grep/find. Mantiene un grafo en sesión de lo ya encontrado para no repetir búsquedas.

npx skills add Alpha018/alpha-skills -s progressive-search

3. `agent-context-generator`

Genera, refresca o audita el CLAUDE.md/AGENTS.md de un proyecto basado en lo que el repo realmente tiene: dependencias reales, estructura real, scripts reales. No en una plantilla genérica que asume un stack que no existe.

npx skills add Alpha018/alpha-skills -s agent-context-generator

4. `nestjs-iam-patterns`

Patrones de auth/authz en NestJS: JWT access/refresh, sesiones con Passport y Redis, API keys, RBAC, permisos granulares, ABAC, Google Sign-In, TOTP/2FA. Liderada por una guía de decisión: qué patrón le corresponde a tu situación, no un catálogo de todos ellos.

npx skills add Alpha018/alpha-skills -s nestjs-iam-patterns

5. `nestjs-advanced-patterns`

Internals avanzados de NestJS: tokens de DI explícitos e implícitos, módulos dinámicos, discovery en runtime, providers durables, worker threads, circuit breaker, WebSocket gateways, y una tabla de decisión para elegir transporter en microservicios (TCP, Redis, MQTT, NATS, RabbitMQ, Kafka, gRPC).

npx skills add Alpha018/alpha-skills -s nestjs-advanced-patterns

6. `nestjs-graphql`

Una sola skill que cubre code-first y schema-first en NestJS, con una tabla de decisión que enruta cada tarea a exactamente un archivo de referencia para que el agente nunca cargue las dos mitades a la vez. Cubre subscriptions con PubSub/Redis, el problema N+1 resuelto con DataLoader, guards tipados, límites de profundidad y costo de queries, y una sección de hardening de producción verificada contra el código fuente real de Apollo Server, no contra lo que yo recordaba de memoria.

npx skills add Alpha018/alpha-skills -s nestjs-graphql

7. `tuning-claude-code`

Diseña todo el stack de configuración de Claude Code para un repo: CLAUDE.md tratado como presupuesto de tokens, reglas por path, subagentes personalizados, hooks determinísticos, una lista de MCP podada, worktrees paralelos y CI headless.

npx skills add Alpha018/alpha-skills -s tuning-claude-code

8. `obsidian-second-brain`

Guía de decisión para llevar un vault de Obsidian como sistema de conocimiento que efectivamente dura. Evita la teatralidad de productividad y la sobrecarga de plugins, elige un organizador líder (carpetas PARA para trabajo de entrega, enlaces Zettelkasten para generación de ideas) y dice explícitamente cuándo Obsidian no es la herramienta correcta.

npx skills add Alpha018/alpha-skills -s obsidian-second-brain

El estilo que comparten las skills

Ninguna de las skills de general/ se planificó con un manual de estilo desde el día uno. Pero después de la cuarta, el patrón ya era imposible de ignorar:

Guía de decisión, no lista de features. La skill no vuelca todo lo que sabe. Abre con una tabla o un procedimiento corto que elige la opción correcta para tu situación real, y dice sin rodeos cuándo la herramienta no es la indicada.
Progressive disclosure. El SKILL.md se mantiene como un procedimiento delgado (bajo 500 líneas). El detalle profundo va a references/*.md, y el cuerpo le dice al agente exactamente cuándo cargar cada uno.
Descripciones orientadas a trigger, con evals. El campo description del frontmatter es el de mayor apalancamiento: uno vago significa que la skill nunca se activa. Cada skill trae un evals/trigger-eval.json con casos de should-trigger y should-not-trigger.
ASCII plano, sin tics de IA. Todo archivo persistido pasa por una revisión anti-IA antes de quedar.

El primer servidor MCP

@alpha018/nextdns-mcp es un servidor MCP stdio, corrido vía npx, que expone la API de NextDNS: leer y actualizar la configuración de un perfil, gestionar entradas de listas, tirar analíticas, leer logs. Está construido sobre la misma referencia que respalda a nextdns-api, así que las dos piezas se mantienen sincronizadas a propósito.

Publicación en npm: el problema de trusted publishing

Acá está la parte que me costó más de diez commits de CI entender bien.

@semantic-release/npm no soporta OIDC trusted publishing. Su paso verifyConditions exige un NPM_TOKEN o un .npmrc preconfigurado sin importar qué tenga id-token: write en el workflow. Ese permiso solo compra firma de provenance a través del plugin, no autenticación.

La arquitectura que terminó funcionando son dos workflows compartidos, generalizados sobre cualquier paquete en mcp-servers/* en lugar de un par de archivos por paquete:

1. Validar los paquetes en cada PR

Workflow: pr-test-mcp-servers.yml

Detecta qué directorios cambiaron y ejecuta lint, typecheck, build y test para cada paquete, en Node 22 y 24.

2. Versionar y publicar desde main

Workflow: build-publish-mcp-servers.yml

En cada push a main, por paquete modificado y dentro de un solo job:

Ejecutar build y test.
Ejecutar npx semantic-release con npmPublish: false: actualizar versión, changelog, tag y release, sin necesitar autenticación de npm.
Comparar la versión local recién actualizada con npm view <pkg> version.
Si difieren, ejecutar npm publish --provenance directamente con el CLI de npm.

La separación que resolvió el problema: semantic-release se encarga del versionado; el CLI de npm realiza la publicación con OIDC.

Cuatro errores que me costaron tiempo real

La primera publicación es manual. Un paquete nuevo en npm no puede bootstrapearse vía OIDC bajo ninguna circunstancia. La primera versión hay que publicarla a mano, con login real, antes de que el Trusted Publisher se pueda siquiera vincular en npmjs.com.
La ruta de bin importa. npm publish descarta en silencio cualquier bin que empiece con ./. "./dist/index.js" se cae con solo un warning; hay que escribir "dist/index.js".
El owner distingue mayúsculas. La verificación de provenance de npm compara repository.url contra el owner del claim de OIDC de forma sensible a mayúsculas. github.com/alpha018/... falló contra el casing real del owner, que es Alpha018.
El nombre del workflow debe coincidir. El Trusted Publisher de npm fija el nombre exacto del archivo del workflow. Renombrarlo sin actualizar esa entrada hace que npm firme la provenance sin problema y después rechace el PUT del publish con un E404 que es idéntico, en forma, al de "Trusted Publisher no configurado".

Cuándo esta configuración no compensa

Si publicas un solo paquete y no piensas agregar más, este andamiaje es sobreingeniería. Un workflow simple con NPM_TOKEN en un secret resuelve lo mismo en quince minutos y sin OIDC. La complejidad de los dos workflows compartidos se paga sola recién cuando aparece un segundo o tercer paquete — antes de eso, es tiempo que le resta a escribir la skill que en realidad importa.

Agregar un segundo servidor MCP ahora es trivial: solo necesita su propio package.json y su propio .releaserc.json, los workflows compartidos lo levantan solos. El trabajo de resolver esto bien una vez se paga en cada paquete nuevo que llega después.

Si alguna de estas ocho skills te resuelve algo que venías reescribiendo cada semana, el repo es github.com/Alpha018/alpha-skills. Y si prefieres la versión con más detalle todavía sobre alguna en particular, algunas ya tienen su propio post extendido en Buy Me a Coffee.

Gracias por leer hasta acá — si pruebas alguna, cuéntame qué se rompió, porque seguro algo se rompe. ¿Cuál de las ocho te resuelve más el día a día?

💌 Agradecimientos Especiales

A una chica que, sin saberlo, me empujó a seguir creando y programando en mi tiempo libre. A quien alguna vez fue mi chispa: para “YLP”, con gratitud… y con cicatrices que también enseñan.

☠️ How to Connect Your Router Directly to Fiber Without Your ISP's Modem (SFP GPON Hack)

Tomás Alegre Sepúlveda — Sat, 25 Apr 2026 21:07:04 +0000

🇪🇸 Leer este post en Español

Entel Chile told me bridge mode wasn't available for business customers. A week later, my Ubiquiti router was plugged directly into fiber with no ISP hardware anywhere in the path.

This post covers how: a Ubiquiti UF-Instant SFP GPON transceiver, UART access, direct flash via U-Boot, and GPON spoofing to make Entel's OLT accept the stick as if it were the original Huawei ONT.

💡 Condensed version. This post covers the process without the failed attempts or dead ends. The extended version — kernel panic on the MC220L, three firmware attempts, TFTP recovery — is on Buy Me a Coffee.

⚠️ Legal disclaimer: This content is for educational purposes only. Modifying firmware on telecommunications devices may violate your ISP contract and local regulations. Check applicable laws before replicating this process.

The problem: ISP vendor lock-in

ISPs install their own ONT and refuse bridge mode, forcing you to use their router for PPPoE. If you want your own router, you're stuck with double NAT or bypassing ISP hardware entirely.

I wanted dual WAN on my Ubiquiti UniFi Gateway Fiber with a static IP from Entel. No double NAT. No Entel modem.

Hardware

Component	Description
Transceiver	Ubiquiti UFiber UF-Instant (RTL9601CI)
Router	Ubiquiti UniFi Gateway Fiber (Dual WAN, SFP+ slot)
ISP	Entel Chile (Huawei OLT)
Original ONT	Huawei OptiXstar (cloned for spoofing)
Console access	UART TTL adapter (3.3V — mandatory)
TFTP server	Mac with tftp-now or tftp-hpa
Rootfs prep	Docker (required on macOS)

Source: stich86/UF-Instant-Mod

UART access: the primary method

Every flash operation runs from here. The UF-Instant exposes UART pads on the PCB (TX, RX, GND). 3.3V adapter, 115200 8N1:

# macOS
screen /dev/tty.usbserial-XXXXX 115200

# Linux
screen /dev/ttyUSB0 115200

# With minicom
minicom -D /dev/ttyUSB0 -b 115200 -8 --noinit

Power on the stick with UART connected and you get the full U-Boot output. Press any key in the first few seconds to interrupt boot and land at the 9601C# prompt, where you can flash partitions directly.

MTD partition map

The UF-Instant uses a dual-image boot system. The relevant partitions:

mtd4  → kernel0 / k0 (3MB)   — Image 0 kernel (original Ubiquiti — fallback)
mtd5  → rootfs0 / r0 (6MB)   — Image 0 rootfs (original Ubiquiti firmware)
mtd6  → kernel1 / k1 (3MB)   — Image 1 kernel — cloned kernel goes here
mtd7  → rootfs1 / r1 (4.5MB) — Image 1 rootfs — stich86 MOD goes here
mtd8  → europa.data          — Laser calibration ⚠️ NEVER TOUCH

Boot control:

# Check active image
nv getenv sw_active sw_commit

# Switch to image 1
setenv sw_active 1 && setenv sw_commit 1 && saveenv && boot

# Fall back to image 0 (original Ubiquiti firmware)
setenv sw_active 0 && setenv sw_commit 0 && saveenv && boot

The process: straight to the point

On the host (before connecting UART): download the MOD rootfs and Ubiquiti v4.4.2 kernel directly from stich86/UF-Instant-Mod and place them in the TFTP server directory. stich86's squashfs binary flashes as-is — no reprocessing needed.

When do you need Docker? Only if you modify the rootfs (extract, change files, repack). On macOS, mksquashfs can't recreate device nodes without explicit parameters. For the standard flow with stich86's binary, skip Docker.

Via UART, in U-Boot (9601C#): initialize flash, clone the kernel from image 0 to image 1, and flash the MOD rootfs:

sf probe 0

# Clone Ubiquiti v4.4.2 kernel from image 0 → image 1
sf read  0x81000000 0x50000  0x300000   # read kernel0 into RAM
sf erase 0x4e0000 0x300000              # erase kernel1 (mtd6)
sf write 0x81000000 0x4e0000 0x300000   # write to mtd6

# Flash MOD rootfs (stich86) via TFTP
tftpboot 0x81000000 [HOST_IP]:[stich86_rootfs_filename]
sf erase 0x7e0000 0x480000              # erase rootfs1 (mtd7)
sf write 0x81000000 0x7e0000 ${filesize}

# Activate image 1 and boot
setenv sw_active 1
setenv sw_commit 1
saveenv
boot

Via UART, from Linux (after booting image 1, credentials admin/admin — some builds use ubnt/ubnt): configure GPON identity with the original Huawei ONT data and neutralize the bootlimit:

# GPON identity — use your actual Huawei ONT data
flash set GPON_SN HWTC[XXXXXXXX]          # ONT SN: HWTC + 8 hex chars
flash set PON_VENDOR_ID HWTC
flash set OMCI_OLT_MODE 1
flash set OMCI_FAKE_OK 1
flash set OMCI_SW_VER1 [ONT_SW_VERSION]   # ONT software version
flash set OMCI_SW_VER2 [ONT_SW_VERSION]
flash set HW_HWVER [ONT_HW_VERSION]       # ONT hardware version
flash set GPON_ONU_MODEL [ONT_MODEL]      # ONT model
flash set ELAN_MAC_ADDR [MAC_NO_COLONS]   # ONT MAC without colons

# Disable automatic factory reset (bootlimit=10 by default)
nv setenv bootcount 0
nv setenv bootlimit 0

reboot

Verify it works

# O5 = Operation State = OLT accepted the stick as a valid ONT
diag gpon get onu-state
# ONU state: Operation State(O5)

# Correct OLT vendor
omcicli mib get 131
# OltVendorId: 0x48575443  ← HWTC (Huawei/Entel Chile) ✓

# VLANs provisioned by Entel's OLT
omcicli mib get 84
# VLAN 3610 → Internet | 3620 → TV | 3630 → VoIP | 3680 → TR-069

With the stick at O5: configure the Ubiquiti SFP+ port with VLAN 3610 and PPPoE with Entel credentials (20011279169002 / D4310T — tested on 2026-04-23, subject to change).

🎥 The official Entel modem farewell ceremony

Trade-offs: when NOT to do this

No UART/U-Boot experience: The process requires bootloader commands. A wrong address in sf write can brick the stick (recoverable via TFTP if U-Boot still responds).
Using a media converter (TP-Link MC220L): The europa_drv kernel panics with that hardware as an intermediary. The UF-Instant must go directly into the router's SFP+ slot.
ISP uses authentication beyond PLOAM serial: Some ISPs also validate PLOAM password, OMCI details, or run clone detection.
Using Entel's TV or VoIP: Those run on separate VLANs (3620 and 3630). You'll need to configure them on the router too.

The failed attempts, kernel panic details, and the MC220L diagnosis are documented in full on ☕ Buy Me a Coffee

Glossary

Term	What it is
GPON	Gigabit Passive Optical Network. Fiber delivering up to 2.5 Gbps downstream shared among multiple users
ONT	Optical Network Terminal. The device at your location converting optical signal to ethernet
OLT	Optical Line Termination. ISP equipment managing all ONTs in an area
SFP / SFP+	Small Form-factor Pluggable. Standard connectivity module. SFP+ supports up to 10 Gbps
PLOAM	Physical Layer Operations, Administration and Maintenance. Authentication protocol between ONT and OLT
OMCI	ONT Management and Control Interface. Channel through which the OLT remotely manages the ONT
PPPoE	Point-to-Point Protocol over Ethernet. Authentication protocol ISPs use for internet connections
MTD	Memory Technology Device. Linux interface for embedded flash storage
U-Boot	Universal bootloader for embedded systems. Lets you flash partitions if the OS won't start
UART	Universal Asynchronous Receiver-Transmitter. Serial port for console access before Linux loads
TFTP	Trivial File Transfer Protocol. Minimal protocol for transferring firmware to embedded devices
Spoofing	Impersonating another device's identity to the OLT

Resources and credits

stich86/UF-Instant-Mod — Modified rootfs for UF-Instant
Anime4000/RTL960x — Firmware and RTL960x documentation
hack-gpon.org — Community GPON hack reference
MA5671A Config Guide (PLOAM) — PLOAM configuration guide

If you've done something similar with a different ISP or OLT vendor, let me know in the comments. I'd like to know which parameters change between carriers.

💌 Special Acknowledgments

To a girl who, without knowing it, pushed me to keep creating and coding in my free time. To the one who was once my spark: for "YLP", with gratitude... and with scars that also teach.

For those who also refused "it can't be done" as a final answer: this post exists because I was told I wouldn't get it working. And because fiber now reaches my router without passing through any hardware I didn't choose. Nobody decides that for me.

🖕 Fuck you, Entel. Your bargain-bin devs don't get to decide what I plug into my own network. And you, Movistar — don't get comfortable. I know you run ZTE and you're next on the list.

☠️ Cómo conectar tu router directo a la fibra de Entel Chile sin su módem (SFP GPON Hack)

Tomás Alegre Sepúlveda — Fri, 24 Apr 2026 05:54:04 +0000

🇺🇸 Read this post in English

Entel Chile me dijo que el bridge mode no existía para clientes empresa. Una semana después, mi router Ubiquiti estaba conectado directo a la fibra sin ningún equipo de Entel de por medio.

Este post explica cómo: un transceptor SFP GPON (Ubiquiti UF-Instant), acceso por UART, flash directo via U-Boot y configuración de spoofing GPON para que la OLT de Entel acepte el stick como si fuera el ONT Huawei original.

💡 Versión resumida. Este post cubre el proceso sin los intentos fallidos ni los callejones sin salida. La versión extendida — con el kernel panic del MC220L, los tres intentos de firmware y la recuperación por TFTP — está en Buy Me a Coffee.

⚠️ Disclaimer legal: Este contenido es exclusivamente educativo. Modificar firmware de dispositivos de telecomunicaciones puede vulnerar los términos de tu contrato con el ISP y potencialmente regulaciones locales. Consulta la normativa vigente en tu país antes de replicar este procedimiento.

El problema: vendor lock-in de ISP

Los ISP instalan su propio ONT y se niegan a configurarlo en bridge mode, forzándote a usar su router para PPPoE. Si quieres usar el tuyo, las opciones son doble NAT o bypassar completamente el hardware del ISP.

Quería dual WAN en mi Ubiquiti UniFi Gateway Fiber con IP estática de Entel. Sin doble NAT. Sin el módem de Entel.

El hardware

Componente	Descripción
Transceptor	Ubiquiti UFiber UF-Instant (RTL9601CI)
Router	Ubiquiti UniFi Gateway Fiber (Dual WAN, slot SFP+)
ISP	Entel Chile (OLT Huawei)
ONT original	Huawei OptiXstar (clonado para spoofing)
Acceso de consola	Adaptador UART TTL (3.3V obligatorio)
Servidor TFTP	Mac con tftp-now o tftp-hpa
Preparación del rootfs	Docker (necesario en macOS)

Fuente: stich86/UF-Instant-Mod

Acceso por UART: el método principal

Todo el proceso de flash se ejecuta desde aquí. El UF-Instant expone pads UART en la PCB (TX, RX, GND). Adaptador 3.3V, configuración 115200 8N1:

# macOS
screen /dev/tty.usbserial-XXXXX 115200

# Linux
screen /dev/ttyUSB0 115200

# Con minicom
minicom -D /dev/ttyUSB0 -b 115200 -8 --noinit

Al encender el stick con UART conectado, tienes el output completo de U-Boot. Presiona cualquier tecla en los primeros segundos para interrumpir el boot y quedar en el prompt 9601C#, desde donde puedes flashear particiones directamente.

Mapa de particiones MTD

El UF-Instant usa un sistema de arranque dual. Las particiones relevantes:

mtd4  → kernel0 / k0 (3MB)   — Kernel imagen 0 (Ubiquiti original — respaldo)
mtd5  → rootfs0 / r0 (6MB)   — Rootfs imagen 0 (firmware Ubiquiti original)
mtd6  → kernel1 / k1 (3MB)   — Kernel imagen 1 — aquí va el clon
mtd7  → rootfs1 / r1 (4.5MB) — Rootfs imagen 1 — aquí va el MOD stich86
mtd8  → europa.data          — Calibración del láser ⚠️ JAMÁS TOCAR

Control de arranque:

# Imagen activa
nv getenv sw_active sw_commit

# Cambiar a imagen 1
setenv sw_active 1 && setenv sw_commit 1 && saveenv && boot

# Volver a imagen 0 (firmware original Ubiquiti)
setenv sw_active 0 && setenv sw_commit 0 && saveenv && boot

El proceso: directo al grano

En el host (antes de conectar UART): descargar el rootfs MOD y el kernel de Ubiquiti v4.4.2 directamente del repo stich86/UF-Instant-Mod y ponerlos en el directorio del servidor TFTP. El binario squashfs de stich86 se flashea tal como viene — no requiere reprocesado.

¿Cuándo se necesita Docker? Solo si modificas el rootfs (extraer, cambiar archivos y reempaquetar). En macOS, mksquashfs no puede recrear device nodes sin parámetros explícitos. Para el flujo estándar con el binario de stich86, no hace falta.

Via UART, en U-Boot (9601C#): inicializar flash, clonar el kernel de imagen 0 a imagen 1, y flashear el rootfs MOD:

sf probe 0

# Clonar kernel Ubiquiti v4.4.2 de imagen 0 → imagen 1
sf read  0x81000000 0x50000  0x300000   # leer kernel0 a RAM
sf erase 0x4e0000 0x300000              # borrar kernel1 (mtd6)
sf write 0x81000000 0x4e0000 0x300000  # escribir en mtd6

# Flashear rootfs MOD (stich86) via TFTP
tftpboot 0x81000000 [IP_HOST]:[nombre_rootfs_stich86]
sf erase 0x7e0000 0x480000              # borrar rootfs1 (mtd7)
sf write 0x81000000 0x7e0000 ${filesize}

# Activar imagen 1 y arrancar
setenv sw_active 1
setenv sw_commit 1
saveenv
boot

Via UART, desde Linux (tras arrancar imagen 1, credenciales admin/admin — algunos builds usan ubnt/ubnt): configurar la identidad GPON con los datos del ONT Huawei original y neutralizar el bootlimit:

# Identidad GPON — datos del ONT Huawei de tu instalación
flash set GPON_SN HWTC[XXXXXXXX]          # SN del ONT: HWTC + 8 hex chars
flash set PON_VENDOR_ID HWTC
flash set OMCI_OLT_MODE 1
flash set OMCI_FAKE_OK 1
flash set OMCI_SW_VER1 [VERSION_SW_ONT]   # Versión software del ONT
flash set OMCI_SW_VER2 [VERSION_SW_ONT]
flash set HW_HWVER [VERSION_HW_ONT]       # Versión hardware del ONT
flash set GPON_ONU_MODEL [MODELO_ONT]     # Modelo del ONT
flash set ELAN_MAC_ADDR [MAC_SIN_PUNTOS]  # MAC del ONT sin dos puntos

# Desactivar factory reset automático (bootlimit=10 por defecto)
nv setenv bootcount 0
nv setenv bootlimit 0

reboot

Verificar que funciona

# O5 = Operation State = la OLT aceptó el stick como ONT válido
diag gpon get onu-state
# ONU state: Operation State(O5)

# Vendor OLT correcto
omcicli mib get 131
# OltVendorId: 0x48575443  ← HWTC (Huawei/Entel Chile) ✓

# VLANs provisionadas por la OLT de Entel
omcicli mib get 84
# VLAN 3610 → Internet | 3620 → TV | 3630 → VoIP | 3680 → TR-069

Con el stick en O5: en el router Ubiquiti configurar el puerto SFP+ con VLAN 3610 y PPPoE con las credenciales de Entel (20011279169002 / D4310T — probadas el 2026-04-23, pueden cambiar).

🎥 La despedida oficial del módem de Entel

Trade-offs: cuándo NO hacer esto

Sin experiencia con UART/U-Boot: El proceso requiere comandos en el bootloader. Un error de dirección en sf write puede brick el stick (recuperable via TFTP si U-Boot sigue respondiendo).
Con un media converter (TP-Link MC220L): El driver europa_drv hace kernel panic con ese hardware como intermediario. El UF-Instant debe ir directamente al slot SFP+ del router.
Si tu ISP valida más que el serial GPON: Algunos ISPs verifican también el PLOAM password, detalles OMCI, o tienen detección de clones activa.
Si usas TV o VoIP de Entel: Funcionan en VLANs separadas (3620 y 3630). Deberás configurarlas también en el router.

Los intentos fallidos, los errores de kernel panic y el diagnóstico del MC220L están documentados en detalle en ☕ Buy Me a Coffee

Glosario

Término	Qué es
GPON	Gigabit Passive Optical Network. Fibra óptica que entrega hasta 2.5 Gbps downstream compartidos entre múltiples usuarios
ONT	Optical Network Terminal. El dispositivo en tu casa que convierte la señal óptica a ethernet
OLT	Optical Line Termination. El equipo del ISP que gestiona todos los ONT del área
SFP / SFP+	Small Form-factor Pluggable. Módulo estándar de conectividad. SFP+ soporta hasta 10 Gbps
PLOAM	Physical Layer Operations, Administration and Maintenance. El protocolo de autenticación entre ONT y OLT
OMCI	ONT Management and Control Interface. Canal por donde la OLT gestiona remotamente el ONT
PPPoE	Point-to-Point Protocol over Ethernet. Protocolo de autenticación de los ISPs para las conexiones de internet
MTD	Memory Technology Device. Interfaz de Linux para la flash interna del dispositivo
U-Boot	Bootloader universal para sistemas embebidos. Permite flashear particiones si el SO no arranca
UART	Universal Asynchronous Receiver-Transmitter. Puerto serie para acceder a la consola antes de que Linux cargue
TFTP	Trivial File Transfer Protocol. Protocolo minimalista para transferir firmware a dispositivos embebidos
Spoofing	Suplantar la identidad de otro dispositivo ante la OLT

💌 Agradecimientos Especiales

A una chica que, sin saberlo, me empujó a seguir creando y programando en mi tiempo libre. A quien alguna vez fue mi chispa: para “YLP”, con gratitud… y con cicatrices que también enseñan.

Recursos y créditos

stich86/UF-Instant-Mod — MOD rootfs para UF-Instant
Anime4000/RTL960x — Firmware y documentación RTL960x
hack-gpon.org — Referencia comunitaria de hacks GPON
MA5671A Config Guide (PLOAM) — Guía de configuración PLOAM

Si tienes preguntas o tu ISP usa una OLT diferente, déjalas en los comentarios. Y si ya lo has hecho con otro proveedor, cuéntame qué parámetros cambiaron.

Para quien tampoco aceptó el "no se puede" como respuesta final: este post existe porque me dijeron que no lo lograría. Y porque la fibra llega al router sin pasar por ningún equipo que no sea el mío. Nadie decide eso por mí.

🖕 Fuck you, Entel. Tus devs de pacotilla no me dicen qué conectar en mi propia red. Y tú, Movistar — estate quieta. Sé que usas ZTE y lo tengo en el radar.

🔬 NestJS vs Go: Performance Benchmark (Do you really need to migrate?)

Tomás Alegre Sepúlveda — Tue, 10 Mar 2026 02:00:34 +0000

🇪🇸 Lee este post en Español

Hello everyone. I recently conducted an exhaustive benchmark to answer a classic question in backend teams: does it make sense to migrate to Go, or is NestJS enough?

There is no magic answer, but data helps decide. Here is a summary of the most important findings.

🏗️ The Scenario

I compared two typical architectures running in Docker on the same machine (M4 Pro):

NestJS (Node 22) + Prisma v6 (Productivity approach)
Go (1.24) + GORM (Performance approach)

Both connected to PostgreSQL 15 and subjected to stress tests (gRPC and HTTP) simulating a real environment.

🧪 Methodology: What did we measure?

To truly understand the differences, I divided the tests into two key scenarios:

Small Data (1x1 Insert):
Simulates typical transactional traffic of a REST/gRPC API. We receive an object, validate it, and save it. Here we measure the framework's base latency.
Large Data (Batch Insert of 1000 elements):
Simulates bulk load processes, ETLs, or event ingestion. We send arrays of 1000 objects that must be deserialized, validated, and saved in a single transaction. This is where CPU and Garbage Collector suffer the most.

📊 The Results

1. Small Data: The Surprise

In low load or unit insert scenarios, the difference was minimal. Go obtained a latency improvement of just ~10% over NestJS.

Conclusion: For standard CRUD operations, NestJS is incredibly efficient, and the performance difference rarely justifies losing TypeScript's productivity.

2. Large Data: The Breaking Point

The story changes drastically when processing massive batches (arrays of 1000 elements) under high concurrency.

Scenario: 100 RPS constant (Bulk Inserts)

Service	Real Throughput	P95 Latency	Success Rate
Go gRPC	85 RPS	71.88 ms	100%
NestJS gRPC	78 RPS	98.44 ms	~85%

What happened here?

Serialization: Node.js (V8) has a higher cost when serializing/deserializing large volumes of JSON compared to Go Structs and Protobuf.
Connection Pool: Under extreme pressure, the Prisma connection pool started to saturate (P2024 errors), causing NestJS to lose ~15% of requests.
Stability: Go maintained 100% success and more predictable latencies, thanks to its goroutine management and a more efficient GC for this type of load.

⚖️ Conclusion: When to use which?

Based on the data, here is my pragmatic recommendation:

✅ Stay with NestJS if:

You are building an MVP or validating a product.
Your team already knows TypeScript and you value development speed.
The load is moderate (< 300 RPS) and standard CRUD operations (Small Data).
BFF (Backend for Frontend): If you only need to orchestrate calls to a few services and the serialization load is low.

🚀 Migrate to Go if:

Complex BFF: If your BFF needs to call many microservices, add heavy logic, serialize large volumes of data, and perform massive fan-out, Go will handle concurrency much better.
Your system constantly performs massive Bulk Operations / ETL (Large Data).
You need to handle thousands of concurrent connections (e.g., Gateways, massive Websockets).
You have very strict latency SLAs where Node's Garbage Collector spikes are unacceptable.
Infrastructure is expensive and you need to squeeze every CPU cycle.

📖 Read the full analysis

This post is a summary. The detailed analysis (with all tables, charts, hardware configuration, and error analysis) is public and free.

👉 Read the full article on Buy Me a Coffee

💻 View code on GitHub

💌 Special Acknowledgments

To a girl who, without knowing it, pushed me to keep creating and programming in my free time. To the one who was once my spark: for "YLP", with gratitude... and with scars that also teach.

If you find this analysis useful, any feedback is welcome!

🔬 NestJS vs Go: Benchmark de Rendimiento (¿Realmente necesitas migrar?)

Tomás Alegre Sepúlveda — Mon, 09 Mar 2026 00:17:36 +0000

🇺🇸 Read this post in English

Hola a todos. Recientemente realicé un benchmark exhaustivo para responder una pregunta clásica en equipos de backend: ¿tiene sentido migrar a Go, o alcanza con NestJS?

No hay respuesta mágica, pero los datos ayudan a decidir. Aquí les dejo un resumen de los hallazgos más importantes.

🏗️ El Escenario

Comparé dos arquitecturas típicas corriendo en Docker sobre la misma máquina (M4 Pro):

NestJS (Node 22) + Prisma v6 (Enfoque productividad)
Go (1.24) + GORM (Enfoque rendimiento)

Ambos conectados a PostgreSQL 15 y sometidos a pruebas de estrés (gRPC y HTTP) simulando un entorno real.

🧪 Metodología: ¿Qué medimos?

Para entender realmente las diferencias, dividí las pruebas en dos escenarios clave:

Small Data (1x1 Insert):
Simula el tráfico transaccional típico de una API REST/gRPC. Recibimos un objeto, lo validamos y lo guardamos. Aquí medimos la latencia base del framework.
Large Data (Batch Insert de 1000 elementos):
Simula procesos de carga masiva, ETLs o ingestión de eventos. Enviamos arrays de 1000 objetos que deben ser deserializados, validados y guardados en una sola transacción. Aquí es donde la CPU y el Garbage Collector sufren más.

📊 Los Resultados

1. Small Data: La sorpresa

En escenarios de baja carga o inserciones unitarias, la diferencia fue mínima. Go obtuvo una mejora de latencia de apenas un ~10% sobre NestJS.

Conclusión: Para operaciones CRUD estándar, NestJS es increíblemente eficiente y la diferencia de rendimiento rara vez justifica perder la productividad de TypeScript.

2. Large Data: El punto de quiebre

La historia cambia drásticamente cuando procesamos lotes masivos (arrays de 1000 elementos) bajo alta concurrencia.

Escenario: 100 RPS constantes (Bulk Inserts)

Servicio	Throughput Real	P95 Latency	Success Rate
Go gRPC	85 RPS	71.88 ms	100%
NestJS gRPC	78 RPS	98.44 ms	~85%

¿Qué pasó aquí?

Serialización: Node.js (V8) tiene un costo mayor al serializar/deserializar grandes volúmenes de JSON comparado con los Structs de Go y Protobuf.
Connection Pool: Bajo presión extrema, el pool de conexiones de Prisma comenzó a saturarse (errores P2024), provocando que NestJS perdiera el ~15% de los requests.
Estabilidad: Go mantuvo el 100% de éxito y latencias más predecibles, gracias a su manejo de goroutines y un GC más eficiente para este tipo de carga.

⚖️ Conclusión: ¿Cuándo usar cuál?

Basado en los datos, aquí está mi recomendación pragmática:

✅ Quédate con NestJS si:

Estás construyendo un MVP o validando producto.
Tu equipo ya conoce TypeScript y valoras la velocidad de desarrollo.
La carga es moderada (< 300 RPS) y operaciones CRUD estándar (Small Data).
BFF (Backend for Frontend): Si solo necesitas orquestar llamadas a pocos servicios y la carga de serialización es baja.

🚀 Migra a Go si:

BFF Complejo: Si tu BFF necesita llamar a muchos microservicios, agregar lógica pesada, serializar grandes volúmenes de datos y hacer fan-out masivo, Go manejará la concurrencia mucho mejor.
Tu sistema realiza Bulk Operations / ETL masivos constantemente (Large Data).
Necesitas manejar miles de conexiones concurrentes (ej. Gateways, Websockets masivos).
Tienes SLAs de latencia muy estrictos donde los picos del Garbage Collector de Node son inaceptables.

📖 Lee el análisis completo

Este post es un resumen. El análisis detallado (con todas las tablas, gráficos, configuración de hardware y análisis de errores) es público y gratuito.

👉 Leer el artículo completo en Buy Me a Coffee

💻 Ver el código en GitHub

💌 Agradecimientos Especiales

A una chica que, sin saberlo, me empujó a seguir creando y programando en mi tiempo libre. A quien alguna vez fue mi chispa: para “YLP”, con gratitud… y con cicatrices que también enseñan.

Si te sirve este tipo de análisis, ¡cualquier feedback es bienvenido!

🐳 Minecraft + Docker: My personal config to stop suffering with Java

Tomás Alegre Sepúlveda — Thu, 05 Feb 2026 04:19:41 +0000

🇪🇸 Lee este post en Español

I'm no Java guru, and I'll be honest: managing Minecraft servers has always felt like a weird puzzle to me. Even though Minecraft might look like a "random" game about placing blocks, the technical management behind a server (threads, memory, garbage collection) is a fascinating optimization challenge.

Back in the day, I tried creating plugins (with... "interesting" results), but I learned the hard way that the real battle is almost always the configuration.

Has this happened to you? You want to play Survival with friends, you search for "best paper 1.21 config", and you end up with 20 open tabs and three wikis that contradict each other.

The Initiative: Enough Chaos

Tired of copying and pasting the same configuration lines over and over again, I decided to build Paper Config Optimized.

I didn't want to make "just another guide". I wanted a place to truly centralize the community's best practices into ready-to-use files. In fact, I've become such a fan of this "infrastructure as code" approach that I recently made my first contribution to the official Docker image repository we use (PR #3076 in itzg/docker-minecraft-server) and plan to keep contributing to improve the ecosystem.

"The Recipe" (Configuration)

Here is the configuration I always use. It's basically my "copy, paste, and forget" template.

The important thing here is that we are telling Docker two key things:

"Use Aikar's Flags": So Java doesn't get picky with memory.
"Download configs from the repo": So the game runs smoothly without having to touch anything.

services:
  mc:
    image: itzg/minecraft-server
    container_name: paper-lite
    restart: unless-stopped
    ports:
      - "25565:25565"

    # Interactive console (never hurts to see what's happening)
    stdin_open: true
    tty: true

    environment:
      # Mojang bureaucracy and software choice (Paper flies)
      EULA: "TRUE"
      TYPE: "PAPER"

      # Always the latest. Living on the edge.
      VERSION: "LATEST"

      # We activate Aikar's flags.
      # Trust me, you don't want to manage the Garbage Collector manually.
      USE_AIKAR_FLAGS: "true"

      # Timezone (change to yours so logs make sense)
      TZ: "America/Santiago"

      # ✨ THE MAGIC:
      # Automatically injects optimized configs from the repo at startup.
      PAPER_CONFIG_REPO: "https://raw.githubusercontent.com/Alpha018/paper-config-optimized/main"

    volumes:
      - ./minecraft-data:/data

How to run this?

It's as simple as putting that into a docker-compose.yml file, opening a terminal in the folder, and throwing in a:

docker compose up -d

⚖️ Balance: Pros and Cons

As with everything in engineering, there are no silver bullets. This configuration is my favorite, but we have to be transparent:

✅ The Good (Pros)

Speed: Go from "zero" to "optimized server" in 2 minutes.
Maintenance: By using PAPER_CONFIG_REPO, if performance improvements come out tomorrow, you just have to restart the container to apply them.
Stability: Using Aikar's Flags eliminates 90% of lag spikes caused by Java.

❌ The Bad (Cons)

Black Box: If you like manually adjusting every millimeter of view-distance, you might feel like you're losing some control (although you can always overwrite the files).
Dependency: You depend on my repository (or your own fork) being online to download the configs at startup.

🚀 For Advanced Users

This configuration is ideal for what I call "Lite Technical Survival". But if you are planning to set up a massive public community (50+ players) or want to understand why 12GB of RAM is my magic number for large servers, I wrote a much deeper technical guide.

☕ Check out the Advanced Technical Guide on Buy Me a Coffee

💌 Special Acknowledgments

To a girl who, without knowing it, pushed me to keep creating and coding in my free time. To the one who was once my spark: for "YLP", with gratitude... and with scars that also teach.

🐳 Minecraft + Docker: Mi configuración personal para no sufrir con Java

Tomás Alegre Sepúlveda — Thu, 05 Feb 2026 04:18:11 +0000

🇺🇸 Read this post in English

No soy ningún gurú de Java, y seré honesto: gestionar servidores de Minecraft siempre me pareció un rompecabezas extraño. A pesar de que Minecraft pueda parecer un juego "random" de poner cubitos, la gestión técnica detrás de un servidor (hilos, memoria, recolección de basura) es un reto de optimización fascinante.

En su momento intenté crear plugins (con resultados... "interesantes"), pero aprendí a la mala que la verdadera batalla casi siempre es la configuración.

¿Te ha pasado? Quieres jugar un Survival con amigos, buscas "mejor configuración paper 1.21" y terminas con 20 pestañas abiertas y tres wikis que se contradicen.

La Iniciativa: Basta de Caos

Cansado de copiar y pegar las mismas líneas de configuración una y otra vez, se me ocurrió armar Paper Config Optimized.

No quería hacer "otra guía más". Quería un lugar donde centralizar de verdad las mejores prácticas de la comunidad en archivos listos para usar. De hecho, me he vuelto tan fan de esta "infraestructura como código" que hace poco hice mi primera contribución al repositorio oficial de la imagen de Docker que usamos (PR #3076 en itzg/docker-minecraft-server) y planeo seguir aportando para mejorar el ecosistema.

"La Receta" (Configuración)

Te dejo por aquí la configuración que uso siempre. Es básicamente mi plantilla de "copiar, pegar y olvidarse".

Lo importante aquí es que le estamos diciendo a Docker dos cosas clave:

"Usa Aikar's Flags": Para que Java no se ponga caprichoso con la memoria.
"Descargar las configs del repositorio": Para que el juego corra fluido sin tener que tocar nada.

services:
  mc:
    image: itzg/minecraft-server
    container_name: paper-lite
    restart: unless-stopped
    ports:
      - "25565:25565"

    # Consola interactiva (nunca está de más para ver qué pasa)
    stdin_open: true
    tty: true

    environment:
      # Papeleo burocrático de Mojang y elección del software (Paper vuela)
      EULA: "TRUE"
      TYPE: "PAPER"

      # Siempre a la última. Vivir al límite.
      VERSION: "LATEST"

      # Activamos las flags de Aikar.
      # Créeme, no quieres gestionar el Garbage Collector manualmente.
      USE_AIKAR_FLAGS: "true"

      # Zona horaria (cámbiala a la tuya para no volverte loco con los logs)
      TZ: "America/Santiago"

      # ✨ LA MAGIA:
      # Inyecta las configs optimizadas del repositorio automáticamente al iniciar.
      PAPER_CONFIG_REPO: "https://raw.githubusercontent.com/Alpha018/paper-config-optimized/main"

    volumes:
      - ./minecraft-data:/data

¿Cómo correr esto?

Es tan simple como meter eso en un archivo docker-compose.yml, abrir una terminal en la carpeta y tirar un:

docker compose up -d

⚖️ Balance: Pros y Contras

Como en todo en ingeniería, no hay balas de plata. Esta configuración es mi favorita, pero hay que ser transparentes:

✅ Lo Bueno (Pros)

Velocidad: Pasas de "cero" a "servidor optimizado" en 2 minutos.
Mantenimiento: Al usar PAPER_CONFIG_REPO, si mañana salen nuevas mejoras de rendimiento, solo tienes que reiniciar el contenedor para aplicarlas.
Estabilidad: Usar las Aikar's Flags elimina el 90% de los tirones de lag por culpa de Java.

❌ Lo Malo (Contras)

Caja Negra: Si te gusta ajustar cada milímetro de la view-distance a mano, sentirás que pierdes algo de control (aunque siempre puedes sobrescribir los archivos).
Dependencia: Dependes de que mi repositorio (o el fork que te hagas) esté en línea para descargar las configs al inicio.

🚀 Para Usuarios Avanzados

Esta configuración es ideal para lo que llamo "Survival Técnico Lite". Pero si estás planeando montar una comunidad pública masiva (50+ jugadores) o quieres entender por qué 12GB de RAM es mi número mágico para servidores grandes, escribí una guía técnica mucho más profunda.

☕ Échale un ojo a la Guía Técnica Avanzada en Buy Me a Coffee

💌 Agradecimientos Especiales

A una chica que, sin saberlo, me empujó a seguir creando y programando en mi tiempo libre. A quien alguna vez fue mi chispa: para “YLP”, con gratitud… y con cicatrices que también enseñan.

🚀 Supercarga la Autenticación en NestJS con Firebase

Tomás Alegre Sepúlveda — Sun, 04 Jan 2026 09:13:33 +0000

🇺🇸 Read this post in English

Si vienes del mundo de NestJS, te encantan los decoradores, la inyección de dependencias y el tipado fuerte. Pero cuando se trata de integrar Firebase Authentication, a menudo se siente como una tarea pesada: guards repetitivos, verificación manual de tokens y manejo de roles desordenado que ensucia nuestros controladores.

Hoy quiero reintroducir nestjs-firebase-auth, una librería diseñada para cerrar esa brecha y tratar la autenticación de Firebase con el respeto que merece en una arquitectura moderna de NestJS.

🤔 ¿Por qué creé esto?

Firebase Authentication es robusto, pero el SDK Admin oficial es solo eso: un SDK. No sabe nada sobre Guards, Decoradores o Inyección de Dependencias de NestJS.

No deberías tener que escribir middleware personalizado para decodificar tokens o verificar claims manualmente en cada controlador. nestjs-firebase-auth cierra esta brecha, dándote una API simplificada y declarativa para asegurar tu aplicación.

Con el último lanzamiento v1.9.0, he pulido la experiencia aún más con decoradores más limpios y una mejor integración con otros servicios de Firebase como Firestore.

Instalación

npm install @alpha018/nestjs-firebase-auth firebase-admin

🛠️ Profundizando en el Código

Veamos ejemplos más realistas de lo que puedes lograr.

1. Autenticación Declarativa `(@Auth)`

Olvídate de importar y vincular manualmente los guards con @UseGuards(FirebaseGuard). Ahora tienes un decorador @Auth() limpio que hace clara tu intención.

import { Auth } from '@alpha018/nestjs-firebase-auth';

@Auth() // 🛡️ Protege todo este controlador
@Controller('users')
export class UsersController {

  @Get('profile')
  getProfile() {
    return "Estos datos son seguros.";
  }
}

2. Control de Acceso Basado en Roles (RBAC)

Manejar roles no debería ser complicado. Utilizo los Custom Claims de Firebase para almacenar los roles del usuario, y el decorador @Roles para hacerlos cumplir sin escribir una sola línea de lógica de validación.

import { Auth, Roles } from '@alpha018/nestjs-firebase-auth';

@Controller('admin')
export class AdminController {

  @Auth()
  @Roles('ADMIN', 'SUPERUSER') // ⛔ Solo permite usuarios con estos roles
  @Get('dashboard')
  getDashboard() {
    return "Datos de administración ultra secretos";
  }
}

Nota: El decorador @Roles activa automáticamente la lógica de validación de roles subyacente cuando se usa con @Auth.

3. Integrando con otros servicios de Firebase

¿Necesitas hablar con Firestore o enviar un mensaje FCM específico? Siempre ha sido posible, pero quiero destacar lo fácil que es acceder a la instancia inicializada de admin.app.App directamente desde mi provider.

import { FirebaseProvider } from '@alpha018/nestjs-firebase-auth';
import { getFirestore } from 'firebase-admin/firestore';

@Injectable()
export class UserDataService {
  constructor(private readonly firebaseProvider: FirebaseProvider) {}

  async saveUserData(uid: string, data: any) {
    // 🔥 Usa la instancia de app del módulo de auth para Firestore
    const firestore = getFirestore(this.firebaseProvider.app);
    return firestore.collection('users').doc(uid).set(data);
  }
}

🎯 Mejores Casos de Uso

Aplicaciones SaaS: Donde necesitas autenticación robusta y segura con configuración mínima.
Microservicios: Compartir lógica de autenticación a través de múltiples servicios NestJS fácilmente usando un enfoque de librería compartida.
Sistemas RBAC: Apps que requieren control granular sobre quién puede hacer qué (Admins vs. Usuarios).

⚠️ Trade-offs (Honestidad Ante Todo)

Validación Remota: Por defecto, verifico los roles obteniendo el registro de usuario desde Firebase. Esto asegura que los roles estén siempre actualizados (sin tokens obsoletos), pero incurre en una pequeña latencia de red.
Validación Local: Puedes optar por useLocalRoles: true para validar contra los claims del token ID directamente (cero latencia), pero debes aceptar que los cambios de roles efectivamente se actualizan solo cuando el usuario refresca su token.

💌 Agradecimientos Especiales

Este proyecto ha sido construido con muchas horas de dedicación y amor por el código.

Para una chica que siempre me inspira en silencio, y su sola existencia me incentiva a seguir programando en mis tiempos libres, gracias "YLP".

☕ Apoya el Proyecto

Si encontraste este proyecto útil o interesante, por favor considera apoyarlo:

⭐️ Estrella en GitHub: Es gratis y ayuda a otros a encontrar la librería.
☕ Cómprame un Café: Si quieres ir un paso más allá, puedes hacerlo en buymeacoffee.com/alpha018.

🔗 Pruébalo y Contribuye

Repo: github.com/Alpha018/nestjs-firebase-auth
Autor: dev.to/alpha018

¿Qué piensas? ¿Estás listo para simplificar tu flujo de autenticación? 👇

🚀 NestJS + RedisOM: Elevando el manejo de Estado a otro nivel

Tomás Alegre Sepúlveda — Sat, 03 Jan 2026 21:19:40 +0000

🇺🇸 Read this post in English

Si vienes del mundo de NestJS, amas los decoradores, la inyección de dependencias y el tipado fuerte. Pero cuando toca integrar Redis, a menudo sentimos que retrocedemos 10 años: magic strings, parsers manuales de JSON y comandos low-level que ensucian nuestra lógica de negocio.

Hoy quiero presentarles nestjs-redisom, una librería open-source diseñada para cerrar esa brecha y tratar a Redis con el respeto que se merece en una arquitectura empresarial moderna.

🤔 ¿Por qué creé esto?

Redis ha evolucionado. Ya no es solo un caché key-value. Con Redis Stack (RedisJSON + RediSearch), se ha convertido en una base de datos de documentos en tiempo real increíblemente potente.

Sin embargo, usar estas features desde Node.js suele ser verboso. Redis OM (la librería oficial) ayuda, pero integrarla en NestJS requería mucho boilerplate. nestjs-redisom elimina esa fricción, dándote una experiencia nativa.

Instalación

npm install nestjs-redisom redis-om redis

🛠️ Profundizando en el Código

Veamos ejemplos más realistas de lo que puedes lograr.

1. Modelado de Datos Complejos (Anidados)

No estamos limitados a strings planos. Podemos modelar objetos complejos con validación implícita.

// 1. Definimos una clase anidada
export class Address {
  @Prop({ indexed: true })
  city: string; // Indexado para buscar "Usuarios en Madrid"

  @Prop()
  zipCode: string;
}

// 2. Definimos la Entidad Principal
@Schema()
export class UserProfile extends BaseEntity {
  @Prop({ textSearch: true })
  bio: string;

  @Prop({ type: () => Address }) // Mapeo anidado
  address: Address;

  @Prop()
  roles: string[]; // Arrays de strings
}

2. Búsquedas Avanzadas (Fluent API)

Aquí es donde nestjs-redisom brilla. Olvídate de aprender la sintaxis de comandos de RediSearch (FT.SEARCH index "@field:value ..."). Usa esta API fluida y tipada.

"Encuentra usuarios que vivan en 'New York', tengan el rol 'admin' y cuya bio mencione 'typescript'"

const users = await userRepo.search()
  .where('address_city').equals('New York') // Busca en objeto anidado
  .and('roles').contain('admin')            // Busca en Array
  .and('bio').matches('typescript')         // Full-Text Search
  .return.page(0, 10);                      // Paginación nativa

3. Expiración de Documentos (TTL)

Manejar sesiones o caché temporal es trivial. No necesitas scripts de Lua ni nada por el estilo.

// Crea una sesión y haz que expire en 1 hora
async createSession(user: User) {
  const session = await this.sessionRepo.save(user);
  await this.sessionRepo.expire(session[this.sessionRepo.schema.idField], 3600);
  return session;
}

🎯 Mejores Casos de Uso

High-Speed Objects: Carritos de compra, Perfiles de Jugador, Sesiones. Datos que lees/escribes 1000 veces por segundo.
Caché con "Poderes": A veces necesitas invalidar caché por criterio ("borrar caché de todos los productos de la categoría X"). Con Redis normal es imposible (o lento con KEYS *). Con RedisOM es una query de O(1) o O(N log N).
Geo-Spatial Features: "Encuentra conductores cerca de mi", usando la potencia nativa de Redis para geo-hashing.

⚠️ Trade-offs (Honestidad ante todo)

RAM es Dinero: Redis guarda todo en memoria. No uses esto para guardar logs de auditoría de 5 años.
Eventual Consistency: Los índices de búsqueda se actualizan asíncronamente (milisegundos). No es ACID estricto para búsquedas inmediatas post-escritura.

💌 Agradecimientos Especiales

Este proyecto ha sido construido con muchas horas de dedicación y amor por el código.

Para una chica que siempre me inspira en silencio, y su sola existencia me incentiva a seguir programando en mis tiempos libres, gracias "YLP".

☕ Apoya el Proyecto

Si este proyecto te ha sido útil o te parece interesante, considera apoyarlo:

⭐️ Star en GitHub: Es gratis y ayuda a que más gente lo encuentre.
☕ Invítame un Café: Si quieres ir un paso más allá, puedes hacerlo en buymeacoffee.com/alpha018.

🔗 Pruébalo y Contribuye

Repo: github.com/Alpha018/nestjs-redisom
Autor: dev.to/alpha018

¿Qué opinan? ¿Le darán una oportunidad a Redis como base de datos de documentos? 👇

🚀 NestJS + RedisOM: Taking State Management to the Next Level

Tomás Alegre Sepúlveda — Fri, 02 Jan 2026 01:39:59 +0000

🇪🇸 Lee este post en Español

If you come from the NestJS world, you love decorators, dependency injection, and strong typing. But when it comes to integrating Redis, it often feels like we're stepping back 10 years: magic strings, manual JSON parsers, and low-level commands that clutter our business logic.

Today I want to introduce nestjs-redisom, an open-source library designed to bridge that gap and treat Redis with the respect it deserves in a modern enterprise architecture.

🤔 Why did I create this?

Redis has evolved. It is no longer just a key-value cache. With Redis Stack (RedisJSON + RediSearch), it has become an incredibly powerful real-time document database.

However, using these features from Node.js is often verbose. Redis OM (the official library) helps, but integrating it into NestJS required a lot of boilerplate. nestjs-redisom removes that friction, giving you a native experience.

Installation

npm install nestjs-redisom redis-om redis

🛠️ Deep Dive into the Code

Let's look at more realistic examples of what you can achieve.

1. Complex Data Modeling (Nested)

We aren't limited to flat strings. We can model complex objects with implicit validation.

// 1. Define a Nested Class
export class Address {
  @Prop({ indexed: true })
  city: string; // Indexed to search "Users in Madrid"

  @Prop()
  zipCode: string;
}

// 2. Define the Main Entity
@Schema()
export class UserProfile extends BaseEntity {
  @Prop({ textSearch: true })
  bio: string;

  @Prop({ type: () => Address }) // Nested mapping
  address: Address;

  @Prop()
  roles: string[]; // Array of strings
}

2. Advanced Searching (Fluent API)

This is where nestjs-redisom shines. Forget about learning RediSearch command syntax (FT.SEARCH index "@field:value ..."). Use this fluent, typed API.

"Find users living in 'New York', having the role 'admin', and whose bio mentions 'typescript'"

const users = await userRepo.search()
  .where('address_city').equals('New York') // Search in nested object
  .and('roles').contain('admin')            // Search in Array
  .and('bio').matches('typescript')         // Full-Text Search
  .return.page(0, 10);                      // Native pagination

3. Document Expiration (TTL)

Handling sessions or temporary cache is trivial. You don't need Lua scripts or anything like that.

// Create a session and make it expire in 1 hour
async createSession(user: User) {
  const session = await this.sessionRepo.save(user);
  await this.sessionRepo.expire(session[this.sessionRepo.schema.idField], 3600);
  return session;
}

🎯 Best Use Cases

High-Speed Objects: Shopping Carts, Player Profiles, Sessions. Data you read/write 1000 times per second.
Powered-Up Cache: Sometimes you need to invalidate cache by criteria ("clear cache for all products in category X"). With standard Redis, this is impossible (or slow with KEYS *). With RedisOM, it's an O(1) or O(N log N) query.
Geo-Spatial Features: "Find drivers near me", using Redis native power for geo-hashing.

⚠️ Trade-offs (Honesty First)

RAM is Money: Redis stores everything in memory. Don't use this to store 5 years of audit logs.
Eventual Consistency: Search indexes update asynchronously (milliseconds). It is not strict ACID for immediate post-write searches.

💌 Special Acknowledgments

This project has been built with many hours of dedication and love for code.

To a girl who always inspires me in silence, and whose mere existence incentivizes me to keep programming in my free time, thank you "YLP".

☕ Support the Project

If you found this project useful or interesting, please consider supporting it:

⭐️ Star on GitHub: It's free and helps others find the library.
☕ Buy me a Coffee: If you want to go the extra mile, you can do so at buymeacoffee.com/alpha018.

🔗 Try it and Contribute

Repo: github.com/Alpha018/nestjs-redisom
Author: dev.to/alpha018

What do you think? Will you give Redis a chance as a document database? 👇

🚀 Supercharge NestJS Authentication with Firebase

Tomás Alegre Sepúlveda — Tue, 10 Sep 2024 22:56:14 +0000

🇪🇸 Lee este post en Español

If you're building a modern application with NestJS, you probably love its modularity, decorators, and type safety. But when it comes to authentication, integrating external providers often feels like a chore—boilerplate guards, manual token verification, and messy role handling.

Today, I want to re-introduce nestjs-firebase-auth, a library designed to make Firebase Authentication feel native to the NestJS ecosystem.

🤔 Why this library?

Firebase Authentication is robust, but the official Admin SDK is just that—an SDK. It doesn't know about NestJS Guards, Decorators, or Dependency Injection.

You shouldn't have to write custom middleware to decode tokens or manually check claims in every controller. nestjs-firebase-auth bridges this gap, giving you a simplified, declarative API for securing your application.

With the latest v1.9.0 release, I've polished the experience even further with cleaner decorators and better integration with other Firebase services like Firestore.

Installation

npm install @alpha018/nestjs-firebase-auth firebase-admin

🛠️ Deep Dive into the Code

Let's look at how this changes your daily workflow.

1. Declarative Authentication (`@Auth`)

Forget about manually importing and binding guards with @UseGuards(FirebaseGuard). You now have a clean @Auth() decorator that makes your intention clear.

import { Auth } from '@alpha018/nestjs-firebase-auth';

@Auth() // 🛡️ Protects this entire controller
@Controller('users')
export class UsersController {

  @Get('profile')
  getProfile() {
    return "This data is secure.";
  }
}

2. Role-Based Access Control (RBAC)

Managing roles shouldn't be complicated. I use Firebase Custom Claims to store user roles, and the @Roles decorator to enforce them without writing a single line of validation logic.

import { Auth, Roles } from '@alpha018/nestjs-firebase-auth';

@Controller('admin')
export class AdminController {

  @Auth()
  @Roles('ADMIN', 'SUPERUSER') // ⛔ Only allows users with these roles
  @Get('dashboard')
  getDashboard() {
    return "Top secret admin data";
  }
}

Note: The @Roles decorator automatically triggers the underlying role validation logic when used with @Auth.

3. Type-Safe User Access

Accessing the current user's data is straightforward and type-safe using @FirebaseUser.

@Get('me')
getProfile(@FirebaseUser() user: DecodedIdToken) {
  // `user` is the standard Firebase DecodedIdToken
  console.log(user.uid, user.email);
}

4. Integrating with other Firebase Services

Need to talk to Firestore or send a clear-cut FCM message? It has always been possible, but I want to highlight how easy it is to access the initialized admin.app.App instance directly from my provider.

import { FirebaseProvider } from '@alpha018/nestjs-firebase-auth';
import { getFirestore } from 'firebase-admin/firestore';

@Injectable()
export class UserDataService {
  constructor(private readonly firebaseProvider: FirebaseProvider) {}

  async saveUserData(uid: string, data: any) {
    // 🔥 Use the auth module's app instance for Firestore
    const firestore = getFirestore(this.firebaseProvider.app);
    return firestore.collection('users').doc(uid).set(data);
  }
}

🎯 Best Use Cases

SaaS Applications: Where you need robust, secure authentication with minimal setup.
Microservices: Sharing authentication logic across multiple NestJS services easily using a shared library approach.
RBAC Systems: Apps that require granular control over who can do what (Admins vs. Users).

⚠️ Trade-offs (Honesty First)

Remote Validation: By default, I verify roles by fetching the user record from Firebase. This ensures roles are always up to date (no stale tokens), but it incurs a small network latency.
Local Validation: You can opt-in to useLocalRoles: true to validate against the ID token's claims directly (zero latency), but you must accept that role changes effectively update only when the user refreshes their token.

💌 Special Acknowledgments

This project has been built with many hours of dedication and love for code.

To a girl who always inspires me in silence, and whose mere existence incentivizes me to keep programming in my free time, thank you "YLP".

☕ Support the Project

If you found this project useful or interesting, please consider supporting it:

⭐️ Star on GitHub: It's free and helps others find the library.
☕ Buy me a Coffee: If you want to go the extra mile, you can do so at buymeacoffee.com/alpha018.

🔗 Try it and Contribute

Repo: github.com/Alpha018/nestjs-firebase-auth
Author: dev.to/alpha018

What do you think? Are you ready to simplify your authentication flow? 👇

DEV Community: Tomás Alegre Sepúlveda

🤖 8 Agent Skills and my first MCP server published to npm

Where the published skills live

The eight skills

1. nextdns-api

2. progressive-search

3. agent-context-generator

4. nestjs-iam-patterns

5. nestjs-advanced-patterns

6. nestjs-graphql

7. tuning-claude-code

8. obsidian-second-brain

The style these skills share

The first MCP server

Publishing to npm: the trusted publishing problem

1. Validate packages on every PR

2. Version and publish from main

Four gotchas that cost real time

When this setup is not worth it

🤖 8 Agent Skills y mi primer servidor MCP publicado en npm

Dónde están las skills publicadas

Las ocho skills

1. nextdns-api

2. progressive-search

3. agent-context-generator

4. nestjs-iam-patterns

5. nestjs-advanced-patterns

6. nestjs-graphql

7. tuning-claude-code

8. obsidian-second-brain

El estilo que comparten las skills

El primer servidor MCP

Publicación en npm: el problema de trusted publishing

1. Validar los paquetes en cada PR

2. Versionar y publicar desde main

Cuatro errores que me costaron tiempo real

Cuándo esta configuración no compensa

☠️ How to Connect Your Router Directly to Fiber Without Your ISP's Modem (SFP GPON Hack)

The problem: ISP vendor lock-in

Hardware

UART access: the primary method

MTD partition map

The process: straight to the point

Verify it works

Trade-offs: when NOT to do this

Glossary

Resources and credits

💌 Special Acknowledgments

☠️ Cómo conectar tu router directo a la fibra de Entel Chile sin su módem (SFP GPON Hack)

El problema: vendor lock-in de ISP

El hardware

Acceso por UART: el método principal

Mapa de particiones MTD

El proceso: directo al grano

Verificar que funciona

Trade-offs: cuándo NO hacer esto

Glosario

💌 Agradecimientos Especiales

Recursos y créditos

🔬 NestJS vs Go: Performance Benchmark (Do you really need to migrate?)

🏗️ The Scenario

🧪 Methodology: What did we measure?

📊 The Results

1. Small Data: The Surprise

2. Large Data: The Breaking Point

⚖️ Conclusion: When to use which?

✅ Stay with NestJS if:

🚀 Migrate to Go if:

📖 Read the full analysis

🔬 NestJS vs Go: Benchmark de Rendimiento (¿Realmente necesitas migrar?)

🏗️ El Escenario

🧪 Metodología: ¿Qué medimos?

📊 Los Resultados

1. Small Data: La sorpresa

2. Large Data: El punto de quiebre

⚖️ Conclusión: ¿Cuándo usar cuál?

✅ Quédate con NestJS si:

🚀 Migra a Go si:

📖 Lee el análisis completo

💌 Agradecimientos Especiales

1. `nextdns-api`

2. `progressive-search`

3. `agent-context-generator`

4. `nestjs-iam-patterns`

5. `nestjs-advanced-patterns`

6. `nestjs-graphql`

7. `tuning-claude-code`

8. `obsidian-second-brain`

1. `nextdns-api`

2. `progressive-search`

3. `agent-context-generator`

4. `nestjs-iam-patterns`

5. `nestjs-advanced-patterns`

6. `nestjs-graphql`

7. `tuning-claude-code`

8. `obsidian-second-brain`

1. Autenticación Declarativa `(@Auth)`

1. Declarative Authentication (`@Auth`)