Self-hosted (run your own)

El nodo autoalojado es la respuesta estructural que vuelve obsoleto el resto del directorio de nodos — ejecuta tu propio `monerod` y toda la pregunta de "¿en qué operador de nodo remoto debería confiar?" desaparece. Listado en Grado A · elección del editor porque la propiedad de privacidad que un nodo remoto puede darte es "confía en que el operador no registre + correlacione"; la propiedad de privacidad que un nodo autoalojado te da es "no hay operador." Cinco minutos de configuración en cualquier VPS razonable o servidor doméstico, ~24 horas de sincronización inicial de la cadena (o 30 minutos con bootstrap), y estás operando Monero con cero suposiciones de confianza en el operador del nodo.

Contexto. `monerod` es el demonio Monero de referencia, mantenido como parte del código oficial del proyecto Monero en github.com/monero-project/monero. El mismo software que alimenta cada nodo público — los nodos de Cake, los nodos de Feather, los nodos comunitarios listados en monero.fail — es el software que ejecutas en tu propio hardware. No hay una "edición autoalojada" vs "edición pública"; son binarios idénticos a nivel de bits. La documentación reside en docs.getmonero.org/running-node/, con extensas guías comunitarias que cubren configuraciones de Raspberry Pi, despliegues de VPS, configuraciones de servicios ocultos Tor/I2P y decisiones de nodo podado vs archivístico.

En qué confías. Confías en tu propia infraestructura — el hardware en el que ejecutas, la red a través de la que te conectas, el operador que tú mismo eres. En qué no confías: ningún operador de nodo público ve las consultas de tu monedero, ninguna infraestructura remota observa qué direcciones te importan, ningún servicio de "modo fácil" de terceros puede ser obligado a divulgar tu actividad. El círculo de confianza se reduce a: el código de monerod (código abierto, revisable, con historial de múltiples auditorías de seguridad a nivel del protocolo Monero), tu hardware (tu responsabilidad), tu cliente de monedero (tu elección — Feather, Monerujo, Cake Wallet, el Monero GUI oficial). Para los usuarios que quieren la postura de máxima minimización de confianza en el ecosistema Monero, esta es la respuesta.

Especificaciones operativas. Mínimo de hardware: 4 GB RAM, 100-150 GB de disco para nodo podado (~mitad del archivo de la cadena), ~500 GB para nodo archivístico completo. Cualquier VPS modesto, Raspberry Pi 4/5, mini-PC o NUC es suficiente. Sincronización inicial: ~24 horas desde génesis en hardware de consumo sobre una conexión a internet razonable; bootstrap (sincronización rápida desde una fuente de confianza) reduce esto a ~30 minutos si aceptas una suposición inicial de confianza más alta (verifica la integridad de la cadena post-bootstrap para recuperar esa confianza). Red: clearnet, servicio oculto Tor o I2P — `monerod` admite los tres transportes de forma nativa. La configuración del servicio oculto Tor está documentada y es sencilla. Configuración: un `monerod.conf` de 10 líneas cubre la configuración típica; las configuraciones avanzadas para RPC restringido, compartición pública, ajuste de ancho de banda P2P están documentadas pero son opcionales. Emparejamiento de monedero: cualquier monedero Monero que acepte una URL de nodo remoto puede apuntarse a tu instancia autoalojada a través de túnel SSH (`ssh -L 18081:localhost:18081 your-server`) o directamente si el nodo está expuesto en un servicio oculto Tor.

Filosofía. El diferenciador editorial del autoalojamiento es la arquitectura de "sin operador en el círculo de confianza". Cada otra entrada en la sección de nodos de este directorio es estructuralmente `[monedero] → [nodo de algún operador] → [red Monero]` — el operador es un tercero real con observabilidad real de las consultas del monedero (tiempo, IP de origen a menos que se enrute por Tor, qué direcciones le importan al monedero). El autoalojamiento colapsa eso a `[monedero] → [tu monerod] → [red Monero]` — el único "operador" eres tú. El compromiso: la responsabilidad operativa se traslada a ti. Las sincronizaciones de la cadena necesitan completarse; el demonio necesita mantenerse en funcionamiento; el hardware necesita ser funcional; la seguridad de la máquina anfitriona importa porque ahora contiene el punto final RPC de tu monedero. El clásico encuadre de la comunidad Monero es correcto: "si no estás ejecutando tu propio nodo, estás ejecutando el nodo de otra persona" — y esa otra persona tiene visibilidad que puedes negarte a conceder ejecutando el tuyo propio.

Justificación de la calificación. El Grado A y la elección del editor reflejan: eliminación estructural de la confianza en el operador del nodo (la única respuesta creíble a "¿cuál es la postura de privacidad más fuerte para el uso de nodos remotos?"); software de referencia del proyecto Monero (sin bifurcación de terceros, sin código base separado); requisitos de hardware modestos (VPS comercial o Raspberry Pi es suficiente); soporte nativo de transporte Tor + I2P; ruta de servicio oculto Tor documentada; flexibilidad de emparejamiento con cualquier monedero Monero (Feather, Monerujo, Cake, Monero GUI); código fuente abierto con múltiples auditorías de seguridad a nivel de protocolo; recomendación consistente en todas las guías de privacidad + infraestructura Monero. Última verificación: 2026-05-13.

Útil cuando. Estás usando Monero para cualquier cosa más allá de cantidades casuales y el modelo de amenaza incluye "observabilidad del operador de las consultas de direcciones". Eres periodista / abogado / investigador / comerciante cuya actividad de monedero no debería ser visible para un operador de nodo de terceros. Ya estás ejecutando un homelab y añadir `monerod` es un pequeño compromiso marginal. Quieres *contribuir* al ecosistema de nodos distribuidos de la red Monero ejecutando un nodo público que otros puedan usar (opcional — tu nodo puede ser solo privado). Quieres verificar que la infraestructura Monero pública en la que anteriormente confiabas te estaba diciendo la verdad (ejecuta tu propio nodo, compara su vista de la cadena con lo que devolvían los nodos remotos). Estás operando desde una región donde el acceso a nodos remotos podría no ser fiable y quieres control soberano sobre la conectividad de tu monedero.

Advertencias. La sincronización inicial toma horas-a-un-día — para usuarios que necesitan un monedero Monero *ahora mismo*, comienza con un nodo remoto y migra a autoalojado en segundo plano. El ancho de banda + almacenamiento son compromisos continuos — 500 GB de disco para archivístico es almacenamiento permanente; ~5-50 GB/día de tráfico de red dependiendo de la configuración de compartición P2P. Podar a ~150 GB de disco + RPC restringido reduce la huella pero sigue siendo significativo para un VPS pequeño. La seguridad de la máquina anfitriona importa — tu instancia de `monerod` está expuesta a través de RPC en (típicamente) el puerto 18081; si el anfitrión es comprometido, la vista de la cadena del monedero puede ser manipulada. Acceso solo por túnel SSH + cortafuegos para todo lo demás es el endurecimiento estándar. Sin magia de sincronización en segundo plano — si apagas tu nodo durante dos semanas, necesitará ponerse al día con esas dos semanas de bloques antes de que tu monedero pueda realizar transacciones. El servicio oculto Tor requiere una configuración correcta — ejecutar `monerod` sobre Tor + I2P está documentado pero no es trivial; una mala configuración puede filtrar tu IP real. Sigue las guías canónicas en docs.getmonero.org. Te conviertes en el operador — para algunos usuarios esto es empoderador, para otros es un impuesto operativo no deseado. No hay vergüenza en usar un nodo remoto verificado de monero.fail si el autoalojamiento genuinamente no encaja en tu vida; la respuesta correcta depende del modelo de amenaza + capacidad operativa, no de la ideología.